Geçtiğimiz birkaç ay içinde ABD hükümeti, devlet kurumlarına yazılım satan kuruluşları etkileyen birkaç yeni gereksinim getirdi. Bu yeni gereksinimler karmaşık olduğu için birçok lider, kuruluşlarının nasıl etkileneceğinden henüz emin değil. Bu makalede, devlet işlerinizi koruyabilmeniz ve yasalara uygunluğu sürdürebilmeniz için anlamanız gereken en önemli kavramlardan bazılarını paylaşacağım.
Yeni Yazılım Güvenliği Gereksinimleri: Ne Değişti?
Geçtiğimiz birkaç yılda, SolarWinds’i ve açık kaynak paketi Log4j’yi etkileyenler gibi yüksek profilli güvenlik olayları, hükümetin yazılım güvenliğine olan ilgisini artırdı. Mayıs 2021’de ülkenin siber güvenliğini geliştirmeye yönelik Beyaz Saray İdari Kararnamesi 14028 ile başlayarak, son iki yılda alınan bir dizi eylem, tüm devlet yazılım tedarikçilerini etkileyen bir dizi net gereksinime yol açtı.
İleride, ABD hükümetine yazılım satan herhangi bir kuruluşun, hükümet tarafından NIST Güvenli Yazılım Geliştirme Çerçevesinde belirtilen güvenli yazılım geliştirme uygulamalarına uyduğunu kendi kendine kanıtlaması istenecektir.
Anlaşılması gereken en önemli şeylerden biri, kuruluşların sadece yazdıkları yazılım kodu için bu uygulamaları kendilerinin takip ettiğini değil, aynı zamanda uygulamalarına çektikleri açık kaynak bileşenlerinin de bu uygulamaları takip ettiğini kanıtlamaları gerektiğidir.
Haziran başında hükümet, OMB mutabakatı M-23-16’da (PDF) bu gereklilikleri yeniden teyit etti ve uyumluluk için hızla yaklaşan son tarihler belirledi – muhtemelen bu yılın dördüncü çeyreğinde (kritik yazılımlar için) ve ilk çeyrekte gelecek. gelecek yılın çeyreği (diğer tüm yazılımlar için).
Bu, önümüzdeki birkaç ay içinde kuruluşların bu yeni tasdik gerekliliklerini anlamak ve kuruluşlarının hem kendi yazdıkları kod hem de yazılım ürünlerine kattıkları açık kaynak bileşenleri açısından nasıl uyum sağlayacağını belirlemek için mücadele edecekleri anlamına geliyor.
M-23-16’ya göre, uyumsuzluğun cezası ağırdır:
” [federal] ajans gerekir yazılımı kullanmayı bırakma ajans, yazılım üreticisinin belgelerini tatmin edici bulmazsa veya ajans, üreticinin onaylayamayacağı uygulamaları belirlediğini doğrulayamazsa…”
Özellikle Zorlu Açık Kaynak Örneği
Pek çok kuruluş tasdik gerekliliklerine daha derinlemesine daldıkça, özellikle sıkı son teslim tarihlerine karşı uyumluluğun zorlayıcı olabileceğini keşfediyorlar. NIST SSDF, güvenlik için karmaşık bir çerçevedir ve kuruluşların yalnızca bu uygulamalara uyduklarından emin olmaları değil, aynı zamanda uygulamalarını ayrıntılı olarak belgelemeleri de zaman alacaktır.
Ancak daha da göz korkutucu olan şey, hükümetin tedarikçilerden, bu yazılımdaki açık kaynak bileşenlerini içeren tüm yazılım ürünlerinin güvenlik uygulamalarını doğrulamalarını istemesidir. Bugün, modern yazılımlar genellikle büyük ölçüde bazı özel yazılımlarla birlikte bir araya getirilmiş açık kaynaklı bileşenlerden oluşuyor. Araştırmamızda, uygulamaların %90’ından fazlasının açık kaynak bileşenleri içerdiğini ve çoğu durumda açık kaynağın kod tabanının %70’inden fazlasını oluşturduğunu bulduk.
Kuruluşunuz kendi güvenlik uygulamalarını doğrulayabilir, ancak uygulamalarınızda kullandığınız açık kaynak kodunu yazan ve sürdüren açık kaynak bakımcıları tarafından izlenen güvenlik uygulamalarını tam olarak nasıl kanıtlayabilirsiniz?
Bu çok büyük bir zorluk ve kuruluşlar, güvenlik uygulamaları hakkında daha fazla bilgi için açık kaynak bakımcıları arıyor. Ne yazık ki, bu açık kaynak bakımcılarının çoğu, geceleri ve hafta sonları açık kaynak üzerinde hobi olarak çalışan ücretsiz gönüllülerdir. Bu nedenle, güvenlik uygulamalarının NIST SSDF tarafından belirlenen yüksek standartlarla eşleştiğini doğrulamak için ekstra çalışma yapmalarını istemek pratik değildir.
Kuruluşların bu zorluktan kaçınmasının bir yolu, uygulamalarında açık kaynak kullanmamaktır. Görünüşte basit bir çözüm gibi görünse de, açık kaynak birçok yönden fiili modern geliştirme platformu haline geldiğinden, aynı zamanda giderek daha geçersiz bir alternatif haline geliyor.
Bu sorunu çözmenin daha iyi bir yolu, güvendiğiniz paketlerin bakım görevlilerine bu önemli güvenlik işini yapmaları için ödeme yapılmasını sağlamaktır.
Bu, kullandığınız açık kaynak bileşenlerinin, paketlerinin bu önemli güvenlik standartlarını karşıladığını doğrulamak için – kurumsal hayırseverler, vakıflar veya ticari çabalar tarafından – ödeme yapılan bakıcılara sahip olduğundan emin olmak için ekstra araştırma yapmanızı gerektirebilir. Ya da kendiniz bakımcılara ulaşabilir ve işlerinin kurumsal sponsoru olabilirsiniz. Yaklaşımınızı tasarlarken, önemsiz olmayan modern uygulamaların çoğunun, her biri farklı bir kişi veya ekip tarafından oluşturulan ve sürdürülen binlerce farklı açık kaynak bağımlılığına sahip olduğunu unutmayın; bu nedenle, bu yaklaşımı ölçeklendirmek için elle yapılan çaba oldukça fazladır.
Zorlu Ama İleriye Doğru Gerekli Bir Adım
Bu gerekliliklere uymak sancılı olabilir, ancak kamu ve özel sektöre büyük zararlar veren artan güvenlik açıklarının zemininde, bunlar ileriye doğru atılmış gerekli bir adımdır. ABD hükümeti, dünyadaki en büyük mal ve hizmet alıcısıdır ve bu, diğer alanlar için olduğu kadar BT için de geçerlidir. Hükümet, yazılım için genel güvenlik standardında iyileştirmeleri zorlamak için satın alma gücünü kullanarak, daha güvenli, daha güvenli bir geleceğin sağlanmasına yardımcı oluyor.