SolarWinds’in sistem yönetim aracının tavizi, yazılımları için bir CI/CD (sürekli entegrasyon ve sürekli teslimat) oluşturma süreci kullanan herkes için birçok ilginç sorunu gündeme getirdi. Kullanıcılarımıza dağıttığımız yazılımın kurmayı düşündüğümüz yazılım olduğundan nasıl emin olabiliriz? Kodumuzun tüm bağımlılıkları, sahip olmayı amaçladığımız şeyler mi? Üçüncü taraf modülleri kullanıyorsak, hala beklediğimiz gibiler mi?
Tüm kodumuzun altına yerleştirdiğimiz katmanlı ve iç içe bağımlılıklar temeli tarafından daha karmaşık hale getirilen karmaşık bir sorundur. Modern geliştirme, dünyanın her yerindeki depolardan alınan ve asla karşılaşmayacağımız sayısız ekip ve kişi tarafından geliştirilen kodlara dayanır. Öyle olsa bile, kodlarının söylediği gibi olduğuna güveniyoruz – kullanıcılarımıza aktardığımız bir güven.
Ted Nelson’ın da dediği gibi, her şey derinden iç içe geçmiş durumda. Bir yazılım geliştirme ağı, masalarımızın ve depolarımızın çok ötesine geçer. Kodumuza güveni sağlamak için ne yapıyoruz?
Neden bir yazılım malzeme listesi ve neden şimdi?
ABD yönetimi, SolarWinds uzlaşmasına bir “Ülkenin Siber Güvenliğinin Artırılmasına Yönelik İcra Emri” Bu, Ulusal Standartlar ve Teknoloji Enstitüsü’nün, kodumuzu oluşturmak için bir araya gelen yazılım tedarik zincirlerinin, modül ağlarının ve bileşenlerin güvenliğini artırmak için yönergeler geliştirmesini ve yayınlamasını gerektirir. Bu yönergeler artık kullanılabilir. Yazılımın, kodunuzla birlikte gelen bileşenlerin ayrıntılarını veren bir yazılım malzeme listesi (SBOM) ile birlikte gönderilmesi gerekir.
SBOM’lar yeni değil. Microsoft’un da dahil olduğu birçok şirket, bunları kullanıcılarına özel bildirimler kullanarak sağlar. Standardizasyon olmadan, biçimler değişir ve genellikle makine tarafından okunamaz. Microsoft, SBOM şeması için bir standart geliştirmek üzere Araçlar Arası SBOM çalışma grubunda Bilgi ve Yazılım Kalitesi Konsorsiyumu ile birlikte çalışıyordu. ABD yürütme emri, bu sürece aciliyet ekledi ve çalışma grubu, çalışmalarını Linux Vakfı’nın daha olgun olanlarıyla birleştirmek için harekete geçti. Yazılım Paketi Veri Değişimi (SPDX) formatı.
Microsoft, kendi rapor formatlarıyla yazılımı için bileşen bildirimleri oluşturmak için kendi aracını kullanıyor. SPDX standartları sürecine katılması sonucunda, Microsoft’un dahili aracı bu alternatif biçimi kullanacak şekilde güncellendikendi geliştirmesi boyunca yayıyor ve boru hatları inşa ediyor.
Bunun gibi araçların yaygın olarak erişilebilir olması, kullanımı kolay olması ve kodunuz için kullanabileceğiniz tüm platformlarda çalışması gerekir. Kod hakkındaki bilgilerin geliştirildiği ve derlendiği yerde yakalanmasını sağlamak için ortak geliştirme araçlarına veya CI/CD ardışık düzenlerine bağlanmaları gerekir.
Bir SBOM’yi iki kez oluşturmak aşırıya kaçmış gibi görünebilir, ancak CI/CD ardışık düzeninizin güvenliği ihlal edilmişse, bir birleştirmedeki SBOM ile bir derlemedeki SBOM’un karşılaştırılması, kod gönderilmeden önce olası sorunların belirlenmesine yardımcı olabilir. İyi tasarlanmış bir SBOM aracı, yalnızca güvenliğin ihlal edilip edilmediğini değil, bu güvenliğin nerede ve ne zaman gerçekleştiğini belirlemeye yardımcı olmak için bir oluşturma sürecine ek kimlik doğrulama eklemek için gereken dijital imzaları ve karmaları sağlar.
Microsoft’un aracını kendi derlemelerinizde kullanın
Microsoft’un dahili SBOM aracı artık açık kaynakile birlikte GitHub’da bulunan ikili dosyalar ve kaynak kodu. Proje hızla ilerliyor ve kodun nereden geldiğini ve kod tabanınıza hangi bağımlılıkları getirdiğini belirlemeye yardımcı olmak için yeni algılayıcılar ekliyor. Bu son nokta anahtardır. NuGet veya npm’den ne yüklediğinizi biliyor olabilirsiniz, ancak bağlı olduğu kod hakkında çok daha az bilgiye sahipsiniz. Masum bir şey gönderdiğinizi düşünebilirsiniz, ancak küçük bir bağımlılığın müşterilerinizin donanımında bir kripto madenciliği çalıştırdığını ve dünyanın diğer tarafındaki suçlulara kripto para gönderdiğini keşfedebilirsiniz. Birdenbire müşterileriniz yalnızca güvenli olmayan, riskli kodlar çalıştırmakla kalmaz, aynı zamanda bu riskten ve ortaya çıkan sorunlardan artık siz sorumlusunuz.
Microsoft’un SBOM aracını yüklemek yeterince basittir. GitHub benioku dosyası, indirilen komut dosyalarına sahiptir. en son ikili dosyalar PowerShell kullanan Windows ve curl kullanan Linux ve macOS için. Bir NuGet paketi, .NET projelerine ekleyebileceğiniz SBOM aracı API’si ile çalışır. Bu, GitHub’ın kendi paket deposunu kullanır, proje dosyanızın PackageReference’ını eklemeniz gerekir. Kodunuzun .csproj dosyasını güncelledikten sonra çalıştırın dotnet restore projeniz için paketi yüklemek için.
Microsoft SBOM aracının geçerli sürümü bir komut satırı uygulamasıdır. İndirip kurduktan sonra kullanıma hazırdır. Uygulamanın çalışması için bazı dosyalar oluşturmanız gerekecektir. En önemlisi, SBOM’unuza eklenmesi gereken dosyaların bir listesidir. Bu, uygulama kaynak dizinlerinizin bir dizin listesinden ve kodunuz tarafından çağrılan modüllerden oluşturulabilir. Hatta kodunuzun ve oluşturma işleminizin dışındaki kapsayıcı düzeyindeki bağımlılıkların bir listesini oluşturmak için taranacak Docker görüntülerinin bir listesini bile verebilirsiniz.
Kaputun altında, SBOM aracındaki temel bileşenlerden biri, Bileşen Algılama, tek başına veya Visual Studio içinde çalıştırılabilen bir araç. En yaygın yazılım ekosistemlerini destekler, modüller için kod tarar ve mümkünse hangi modüllerin kurulduğunu ve nereden kurulduğunu gösterebilen bir bağımlılık grafiği oluşturur. Yine, bu açık kaynaklı bir araçtır ve kullandığınız bir ekosistem desteklenmiyorsa, kendi taramalarınızı eklemek için uzantı desteğini kullanma seçeneği vardır.
CI/CD için komut dosyası SBOM taramaları
Bir CLI aracı olduğu için, Microsoft’un SBOM aracı komut dosyasıyla yazılabilir; CI/CD ardışık düzeninize yerleştirebilir, bir yapının parçası olarak bir SBOM oluşturabilir ve kaynak dosyalarınızı bağımlılıklar ve bileşenler için tarayabilirsiniz. Ortaya çıkan SBOM, bir SPDX JSON belgesidir. İnsan tarafından okunabilir olmasına rağmen, verileri ayrıştırmak ve bir tarayıcıda görüntülemek için basit bir JavaScript uygulaması yazmayı veya hatta sürümler arasındaki farkları bildirmek için bir güvenlik bilgisi ve olay yönetimi veya benzeri güvenlik aracına besleme olarak kullanmayı tercih edebilirsiniz. bir uygulamanın. En basit haliyle, araştırılması gerekebilecek yeni bileşenleri ve bağımlılıkları belirleyebilir. Daha karmaşık uygulamalarda, bir güvenlik ekibi tarafından ek araştırma gerektiren olası riskli bileşenlerin bir listesini oluşturabilirsiniz.
Kullanışlı bir özellik, modüler bir uygulamanın farklı bileşenlerinden SBOM’ları saran katmanlı yapılar için destektir. Burada her bileşenin yapısı, kendi bağımlılık ağacından kendi SBOM’sini oluşturur. Uygulama, son derleme aşamasında paketlendiğinde, araç, tüm uygulama için müşterilerle paylaşmaya hazır birleşik bir SBOM oluşturur. Son bildirimde bireysel SBOM’lara başvurulur ve istenmeyen yazılımların kodunuzla birlikte paketlenmediğinden emin olmak için son derlemenin SBOM’una karşı kontrol edilmelerine olanak tanır.
SBOM’lar, modern yazılım geliştirme için önemli bir araçtır ve mevcut güvenlik ortamında, temel olarak düşünülmeleri gerekir. Bağımlılık zincirinin derinliği geliştiricilerin anlaması neredeyse imkansız olabileceğinden, SBOM’ların yapımını otomatikleştirmek önemlidir. Modülleri ve bileşenleri tanımlamaya ve kapsayıcıları taramaya yönelik araçlar dahil ederek, Microsoft’un ücretsiz SBOM aracı, her kurulumun bir parçası olarak proaktif olarak bir SBOM ve bileşen bildirimi sunarak müşteri taleplerinin önüne geçmenizi sağlarken yasal gereksinimleri karşılamada uzun bir yol kat eder.
Telif Hakkı © 2022 IDG Communications, Inc.
Kaynak : https://www.infoworld.com/article/3668035/build-sboms-with-microsofts-internal-tool.html#tk.rss_all