Google ve GitHub, yazılım tedarik zincirini güvence altına alma çabalarının bir parçası olarak kaynak kodu imzalamak için sahteciliğe karşı dayanıklı bir yöntem üzerinde işbirliği yapıyor.
Yazılım tedarik zinciri güvenliği, geliştiricilerin ve kuruluşların, yapıtların (kullanılan yazılım bileşenleri, çerçeveler ve yapı araçları) orijinal olduğunu ve üzerinde değişiklik yapılmadığını algılayabilmesine bağlıdır. arkasındaki düşünce budur Yazılım Eserleri için Tedarik Zinciri Düzeyleri (SLSA), bir yazılım tedarik zincirinin uçtan uca bütünlüğünü korumaya yönelik bir çerçeve.
SLSA’nın amacı, eserlerin nerede, ne zaman ve nasıl üretildiğini açıklayan bilgileri oluşturmak ve geliştiricilere ve kuruluşlara, eserlerin orijinalden nerede ayrıldığını belirlemeleri için bir yol sağlamaktır. Başlangıçta Google tarafından, Ulusal Standartlar ve Teknoloji Enstitüsü’nün (NIST) yanıt olarak geçen Haziran ayında inşa edildi. yazılım geliştirme çerçevesitarafından yönetilmektedir Açık Kaynak Güvenlik Vakfı.
Bir projenin SLSA düzeyini bilmek, geliştiricilere ve kuruluşlara projenin güvenlik durumu hakkında bazı bilgiler sağlayabilir.
Yapı Araçlarına Bakmak
Google ve GitHub’ın son işbirliği, kaynak inşa etmekveya yayın süreçlerinin arkasındaki varlığın gerçekliğini ve yapı yapılarının kurcalamaya karşı korunup korunmadığını doğrulama. SolarWinds ve Codecov’a yönelik saldırının gösterdiği gibi, tehdit aktörleri kötü amaçlı bileşenleri yaymak için yapı araçlarını ele geçirebilir.
“[These] Google Açık Kaynak Güvenlik Ekibi’nden Asra Ali ve Laurent Simon, teslim edilen eserlerin yazılımın beklenen kaynağından saptığını tespit etmenin bir yolu olsaydı saldırılar önlenebilirdi” diye yazıyor.
Google ve GitHub, Go programlama dilinde yazılmış bir prototip aracı duyurdu. GitHub Eylemleri iş akışları ve Sigstore‘nin imza araçları, “yapının kurcalanmayan kanıtını oluşturmak ve tüketici doğrulamasına izin vermek”.
Bu iş akışlarını ve araçları kullanmak, “kullanıcıların yalnızca aldıkları yazılımın orijinal olduğunu doğrulamalarına değil, aynı zamanda nerede ve hangi yazılımla oluşturulduğunu da doğrulamalarına” olanak tanır. Jose PalafoxGitHub’ın iş geliştirme direktörü.
Herhangi bir GitHub deposundaki Eylemler sekmesinde bulunan yeni iş akışı, her iş için koşucular veya yeni sanal makine örnekleri oluşturur. Farklı sanal makineler projeyi derler ve SLSA kaynağını oluşturup imzalar. GitHub tarafından barındırılan koşucuları kullanan projeler, kodun değiştirilmediği garantisine sahiptir.
Ali ve Simon, “Bir işin (örneğin oluşturma adımı) başka bir iş tarafından kullanılan diğer eserlerle (kaynak adımı) kurcalama olasılığına karşı koruma sağlamak için bu yaklaşım, verilerin bütünlüğünü korumak için güvenilir bir kanal kullanır,” diye yazıyor Ali ve Simon.
Benzersiz bir belirteç, arayan deposu, kesinleştirme karması, tetikleyici ve geçerli iş akışı yolu ve referansı gibi iş akışı hakkında doğrulanabilir bilgiler içerir. Kullanıcılar, kaynağı doğrulamak için imza sertifikalarına güvenebilir ve geliştiricinin imzalama için şifreleme anahtarlarını yönetmesi veya dağıtması gerekmez.
Güvenlikte GitOps
ESG’de kıdemli bir analist olan Melinda Marks, bulutta yerel geliştirme ile geliştiricilerin Git depolarını kullanarak CI/CD ardışık düzenleriyle mümkün olduğunca hızlı ve verimli bir şekilde çalıştığını söylüyor. Güvenlik, modern yazılım geliştirme hızıyla eşleşecekse, hatalı kod dağıtma riskini azaltmak için güvenlik araçlarının geliştirici iş akışına entegre edilmesi gerekir. Google ve GitHub’ın işbirliği “GitOps’un güvenlik için ne kadar iyi olduğunu gösteriyor” diyor Marks.
Marks, otomatik olarak yapı kaynağı oluşturmak için GitHub Eylemleri iş akışlarının kullanılmasının ve kodu izlemek için Sigstore bilgilerinin kullanılmasının, geliştiricilere yeniden kullanılabilir güvenilir iş akışları, kurcalamayı önleyecek mekanizmalar ve kod değiştirildiğinde kayıtlar oluşturmanın yollarını sağladığını söylüyor.
“Bu GitHub özellikleri ve çerçeveleri, kodun nereden geldiğini, kimin erişimi olduğunu, hangi değişikliklerin yapıldığını vb. izler, böylece sorun varsa güvenlik araçlarını, test araçlarını, yapılandırma/duruş yönetimi araçlarını vb. kullanabilirler. ., ve kod kaynağı, herhangi bir değişiklik, erişim vb. hakkında verilere sahip oldukları için sorunları verimli bir şekilde düzeltmek için depolardaki meta verileri kullanın” diyor.
Dereceli Bir Yaklaşım
Son zamanlardaki yüksek profilli ihlaller, yazılım tedarik zincirinin nasıl savunmasız olduğunu ve ne tür hasar saldırılarının neden olabileceğini vurgulamaktadır. Gartner tahminleri “2025’e kadar kuruluşların %45’i yazılım tedarik zincirlerine saldırı yaşayacak, bu 2021’e göre üç kat artış olacak.”
SLSA çerçevesi, yazılım derlemeleri için tedarik zinciri güvenliğini benimsemenin hızlı bir süreç olmadığını ve artımlı yaklaşım gerekli. Çerçeve, oluşturma süreci, üst düzey kaynak ve bağımlılıklar dahil olmak üzere bir yapıtın nasıl oluşturulduğuna ilişkin meta verilerin nasıl üretildiğini ve doğrulandığını dikkate alır. Dört seviye vardır:
- Düzey Bir: Oluşturma süreci tam olarak yazılmalı ve/veya otomatikleştirilmeli ve kaynak oluşturmalıdır. Bu seviye, kurcalamayı engellemez, ancak güvenlik açığı yönetiminde kullanılabilecek bilgiler sunar.
- İkinci Düzey: Kuruluş, sürüm denetimi ve kimliği doğrulanmış kaynak oluşturan barındırılan bir yapı hizmeti kullanıyor olmalıdır. Bu düzey, yapı hizmetinin güvenilir olduğu ölçüde kurcalamayı önler.
- Üçüncü Seviye: Kaynak ve yapı platformları, kaynağın denetlenebilirliğini ve kaynağın bütünlüğünü garanti etmek için belirli standartları karşılar.
- Dördüncü Düzey: Kuruluş, tüm değişikliklerin iki kişilik bir incelemesini ve hermetik, tekrarlanabilir bir oluşturma sürecini gerektirir. Hermetik yapılar, kaynağın bağımlılık listesinin eksiksiz olduğunu garanti eder.
Ali ve Simon, yeni inşa kaynağı prototip aracının kuruluşları SLSA kapsamında Üçüncü Seviyeye getireceğini söylüyor. GitHub koşucularını kullanan projeler, özgün eserlere sahip olarak algılanacaktır. Seviye Üç, bu prototipin sağladığı kaynağı tekrar tekrar doğrulamak için bir yol gerektirir.
“Bu yaklaşımı kullanarak GitHub koşucuları üzerine inşa edilen projeler, SLSA 3 (dört aşamalı SLSA seviyesinin üçüncüsü), bu da tüketicilere yapıtlarınızın gerçek ve güvenilir olduğunu onaylıyor” diye yazıyor Ali ve Simon.