Geliştiriciler, verimlilik ve zaman tasarrufu amacıyla uygulamalarını oluşturmak için rutin olarak üçüncü taraf kodlarını kullanmaktadır. Ancak, harici bileşenlere, özellikle de açık kaynaklı yazılımlara (OSS) olan bu bağımlılık, güvenlik açıkları ve lisanslama sorunları gibi önemli riskleri de beraberinde getirmektedir. 2023 GitHub anketine göre, geliştiricilerin %31'i güvenlik açıklarını bulmayı ve düzeltmeyi, kod yazmanın hemen ardından (%32) ikinci en önemli görevleri olarak görüyor.
Sonuç olarak, bilgisayar korsanları tarafından sıklıkla hedef alındığı için birçok kuruluş OSS'ye olan güvenleri konusunda endişe duymaktadır. Kuruluşlar, yazılım tedarik zincirinde artan güvenlik açığı ve son zamanlardaki yüksek profilli saldırıların ardından riskin nasıl etkili bir şekilde azaltılacağını anlama konusunda zorluklarla karşılaşmaktadır.
ESG tarafından hazırlanan bir araştırma raporu, kuruluşların %91'inin son 12 ay içinde bir yazılım tedarik zinciri olayı yaşadığını ortaya koyuyor. En yaygın olaylar şunlardır:
Log4J, Curl, Apache Struts ve OpenSSL gibi öne çıkan güvenlik açıklarının tümü çok sayıda operasyonel hasara yol açmıştır. Bunlar, yazılım tedarik zincirindeki tek bir zayıflığın istismar edilmesinin kuruluşlar üzerinde yarattığı ciddi etkiyi vurgulamaktadır. Bu artan risklere karşılık olarak, dünyanın dört bir yanındaki düzenleyici kurumlar yazılım şeffaflığı ve güvenliğine vurgu yapmaktadır. Bir "İş Sağlığı ve Güvenliği Software Bill of Materials (SBOM)yazılım tedarik zinciri risklerini yönetmek için önemli bir strateji haline gelmektedir.
SBOM Yönetmelikleri İvme Kazanıyor
SBOM düzenlemeleri giderek yaygınlaşmaktadır. Birçok hükümet SBOM uygulamasına ilişkin tavsiyeler yayınlamıştır. ABD'de SBOM tavsiyeleri, aşağıdakiler de dahil olmak üzere çeşitli hükümet kılavuzlarında yer almaktadır:
Avrupa'da AB Siber Güvenlik Ajansı (ENISA), kuruluşlara siber güvenliği iyileştirme ve yazılımla ilgili tedarik zinciri risklerini yönetme konusunda değerli bilgiler sunan "Nesnelerin İnterneti için Supply Chain Güvenliğini Sağlama Kılavuzu "nu yayınladı.
Diğer ülkeler de benzer kılavuzlar yayınlamıştır:
Kurumlara, kullandıkları yazılım bileşenleriyle ilişkili riskleri değerlendirmek ve bu bileşenlerdeki güvenlik açıklarını tespit edip ele almak için SBOM'ları kullanmalarını tavsiye eder.
"Bilgi Güvenliği El Kitabı: ACSC, siber tedarik zinciri şeffaflığını artırmak ve uygulamalarda kullanılan münferit Software bileşenleriyle bağlantılı güvenlik risklerinin tanımlanmasını ve yönetilmesini kolaylaştırmak için SBOM'ların kullanılmasını tavsiye etmektedir.
PCI DSS SBOM Oluşturulmasını Nasıl Gerektiriyor?
Ödeme kartı verilerine yönelik artan risklerin farkına varan Ödeme Kartı Endüstrisi Veri Güvenliği Standardı (PCI DSS), SBOM'un benimsenmesi için itici bir güç haline gelmiştir. En son sürüm olan PCI DSS 4.0, SBOM'ların kullanımını zorunlu kılmakta ve hassas bilgilerin korunmasındaki kritik rollerinin altını çizmektedir. SBOM 'lar, yazılım bileşenlerinin ayrıntılı bir envanterini sunarak kuruluşların güvenlik açıklarını proaktif bir şekilde belirleyip ele almalarını sağlar ve maliyetli veri ihlalleri ve mali kayıp riskini azaltır.
2004 yılında oluşturulan PCI DSS, kredi kartı bilgilerini korumak için tasarlanmış kapsamlı bir güvenlik standardıdır. Kredi kartı işlemlerini gerçekleştiren işletmeler için, her yıl işlenen işlem hacmine göre uyarlanmış bir dizi sıkı gerekliliğin ana hatlarını çizer. PCI DSS v4.0'ın 2022 sürümü, gelişen tehditleri ele almak için SBOM yetkisi de dahil olmak üzere önemli değişiklikler getirmiştir. PCI DSS v4.0 ile uyumluluk Nisan 2024'e kadar zorunludur ve belirli gereklilikler 31 Mart 2025'e kadar aşamalı olarak uygulanacaktır.
Kaynak: Bir Bakışta PCI DSS V4.0
PCI DSS, SBOM'ları zorunlu kılarak kuruluşların yazılım ekosistemlerini kapsamlı bir şekilde anlamalarını sağlayarak güvenlik açıklarını proaktif olarak belirlemelerine ve ele almalarına olanak tanır. Bu yaklaşım, maliyetli veri ihlalleri ve mali kayıp riskini önemli ölçüde azaltır.
PCI DSS'nin daha yeni bir sürümü olan 4.0.1 sürümü 2024 yılının ortalarında yayınlanmıştır. Bu, önceki sürüm olan 4.0'ın 31 Aralık 2024'ten sonra artık geçerli olmayacağı anlamına gelmektedir. Bununla birlikte, yeni sürüm herhangi bir kural eklememekte veya kaldırmamakta ve son tarihleri değiştirmemektedir. Bu nedenle, bu blogda SBOM gereklilikleri hakkında verilen bilgiler hem 4.0 hem de 4.0.1 sürümleri için geçerlidir.
PCI DSS Gereksinimi 6.3.2 ile Uyumluluk
PCI DSS v4.0'daki SBOM gereksinimi, PCI DSS'nin en son yinelemesinde yapılan daha geniş kapsamlı geliştirmelerin bir parçasıdır. Sürüm 4.0'da eklenen 64 yeni gereksinimin bir parçası olarak sunulan SBOM gereksinimi, özellikle ısmarlama ve özel yazılımlara odaklanarak kuruluşların yazılım bileşenlerinin envanterini tutma ihtiyacını ele almaktadır.
Bu gereklilik, güçlü güvenlik önlemlerinin uygulanması ve güvenlik açığı değerlendirmelerinin ve güncellemelerinin düzenli olarak gerçekleştirilmesi yoluyla güvenli sistemlerin ve uygulamaların oluşturulmasını ve sürdürülmesini zorunlu kılan PCI DSS Gereksinim 6 altında kategorize edilir. Bu gereklilik, yazılım açıklarından kaynaklanan riskleri azaltmak ve kart sahibi verilerini korumak için gereklidir. Bölüm 6 beş temel alanı kapsamaktadır:
- 6.1 Güvenli sistemler ve yazılımlar geliştirmek ve sürdürmek için süreçler ve mekanizmalar tanımlanır ve anlaşılır.
- 6.2 Ismarlama ve özel yazılımlar güvenli bir şekilde geliştirilir.
- 6.3 Güvenlik açıkları tespit edilir ve ele alınır.
- 6.4 Halka açık web uygulamaları saldırılara karşı korunur.
- 6.5 Tüm sistem bileşenlerinde yapılan değişiklikler güvenli bir şekilde yönetilir.
Daha spesifik olarak, gereklilik 6.3.2, üçüncü taraf bileşenlerindeki güvenlik açıklarının veya üçüncü taraf bileşen sağlayıcılarının ihlallerinin kart sahibi verilerinin tehlikeye atılmasına yol açtığı birkaç ihlalden kaynaklanan önemli bir güncellemedir. Gereklilik aşağıdaki gibidir:
6.3.2.b Üçüncü taraf yazılım bileşenlerini entegre eden ısmarlama ve özel yazılımlar da dahil olmak üzere yazılım belgelerini inceleyin ve envanterin ısmarlama ve özel yazılımları ve üçüncü taraf yazılım bileşenlerini içerdiğini doğrulamak için envanterle karşılaştırın.
Kuruluşlar, uygulamalarında kullanılan belirli bileşenleri ve hizmetleri kapsamlı bir şekilde belgelemeli ve yönetmelidir. Bu bilgilerin bir kısmı veri akış diyagramlarında kapsanmış olsa da, yeni gereksinimler çok daha ayrıntılı dokümantasyon gerektirmektedir. Bileşenler güncellendikçe ve değiştirildikçe bu ayrıntıları takip etmek zor olabilir. Bu bilgileri yakalamak için standart bir şablon kullanılması tavsiye edilir. Ayrıca, GIT gibi bazı kaynak kodu depoları, kullanılan bileşenlerin bir listesini dışa aktarmak için araçlar sunabilir. En azından envanteriniz şunları içermelidir:
- Uygulama Bileşenleri (tipik olarak depo projeleri)
- Üçüncü taraf bileşenlerin listesi
- Uygulama bağımlılıklarının listesi (örn. Tomcat, Jboss, .NET, Middleware)
- Yetkili Ödeme Sayfası Komut Dosyaları Listesi
OPSWAT SBOM PCI DSS Gerekliliklerini Karşılamaya Nasıl Yardımcı Olabilir?
Düzenlemeler, yazılım tedarik zinciri güvenliğini sağlamak için SBOM'ları giderek daha fazla talep etmektedir. Ancak kuruluşlar, yazılım kodu bileşimlerinin doğru envanterlerini oluşturmakta zorlanmaktadır.
Kaynak EGS Raporu 2024
Bununla birlikte, doğru ve kapsamlı SBOM'ların oluşturulması kuruluşlar için önemli bir zorluk teşkil etmektedir. Bu belgeler, yazılım bileşenlerinin titizlikle envanterinin çıkarılmasını gerektirmekte ve bunların kökenleri, sürümleri ve karşılıklı bağımlılıkları hakkında ayrıntılı bilgi verilmesini zorunlu kılmaktadır. Kesin SBOM'lar olmadan kuruluşlar yazılım tedarik zincirlerindeki riskleri etkin bir şekilde tespit etmekte, değerlendirmekte ve azaltmakta zorlanırlar.
SBOM Oluşturma Kılavuzları
OPSWAT SBOM, hem kod hem de konteynerler için SBOM'ların oluşturulmasını otomatikleştirerek güvenliği artırır ve yazılım tedarik zincirinde uyumluluğa yardımcı olur.
- Tüm Bileşenleri ve Bağımlılıkları Tanımlayın
Açık kaynak ve üçüncü taraf kütüphaneleri de dahil olmak üzere tüm yazılım bileşenlerini sürümleri ve bağımlılıkları ile birlikte doğru bir şekilde tanımlayın. Bu, sağlam bir SBOM için temel oluşturur. - OSS Risklerini Değerlendirin
OSS bileşenleriyle ilişkili potansiyel riskleri değerlendirin. Lisans uyumluluğu, güvenlik açıkları ve bakım durumu gibi faktörleri göz önünde bulundurun. Bileşenleri yazılım için kritikliklerine göre önceliklendirin. - OSS Güvenlik Açıklarını Tarama
OSS bileşenleri içindeki bilinen güvenlik açıklarını belirlemek için güvenlik açığı tarama ve SBOM oluşturma araçlarını kullanın. Güvenlik açıklarını önem derecelerine ve yazılım üzerindeki potansiyel etkilerine göre önceliklendirin.
OPSWAT SBOM'u kullanma
OPSWAT SBOM, hem kod hem de konteynerler için SBOM'ların oluşturulmasını otomatikleştirerek güvenliği artırır ve yazılım tedarik zincirinde uyumluluğa yardımcı olur.
SBOM'ları etkili bir şekilde oluşturmak için OPSWAT SBOM'u nasıl kullanabileceğinizi aşağıda bulabilirsiniz:
Bir uygulamada kullanılan tüm açık kaynaklı kütüphanelerin ve bileşenlerin bir envanterini sağlayan OPSWAT SBOM, yazılım tedarik zincirindeki bağımlılık güvenlik açıklarının yönetilmesine yardımcı olarak kullanıcıların uygulamalardaki güvenlik açıklarını verimli bir şekilde tespit etmelerini ve düzeltmelerini sağlar.
Güvenlik açıklarını tespit etmenin yanı sıra, OPSWAT SBOM her bir yazılım bileşeniyle ilişkili lisansları doğrular. Bu, lisanslama koşullarına uygunluğu sağlar ve olası yasal tuzakları önler. OSS'de lisans tespitinin önemli rolü hakkında daha fazla bilgi edinin.
OPSWAT SBOM, Java, JavaScript, Go, PHP ve Python dahil olmak üzere 10'dan fazla programlama dilini destekler. Bu geniş destek, çeşitli yazılım geliştirme ekosistemlerinde kapsamlı vulnerability detection sağlar.
Uyumsuzluk için Cezalar
SBOM gerekliliği de dahil olmak üzere PCI DSS standartlarına uymayan kuruluşlar, aylık 5.000 ila 100.000 $ arasında değişen mali cezalara maruz kalabilir. Uyum sorunları çözülmeden kalırsa bu cezalar zaman içinde artabilir.
Mali cezalara ek olarak, PCI DSS ile uyumsuzluk önemli yasal ve operasyonel zorluklara yol açabilir. Hukuki sonuçlar arasında davalar, savunma masrafları ve önemli uzlaşmalar yer alabilir. Ayrıca, uyumsuzluk Federal Ticaret Komisyonu (FTC) gibi kurumlar tarafından federal denetimleri tetikleyebilir ve bu da ek cezalara yol açabilir.
PCI DSS 4.0 Uyumluluğu için Sonraki Adımlar
SBOM'un PCI DSS 4.0 çerçevesine entegrasyonu, daha güvenli bir yazılım tedarik zincirine doğru önemli bir değişimi ifade etmektedir. Kuruluşlar, OPSWAT SBOM gibi gelişmiş araçlardan yararlanarak açık kaynak risklerini etkin bir şekilde yönetebilir, uyumluluğu artırabilir ve maliyetli veri ihlallerine karşı koruma sağlayabilir.
SBOM'ları kullanmak artık bir seçenek değil, bir zorunluluktur. Kuruluşlar, yazılım bağımlılıklarını anlamak ve ele almak için proaktif adımlar atarak operasyonlarını koruyan ve müşteri güveni oluşturan sağlam bir güvenlik temeli oluşturabilirler.
Güvenliğinizi Geliştirin
ile Duruş OPSWAT
Açık kaynak
bağımlılıklarını yönetmeye hemen başlayın.
