ETSI Güvenlik Konferansı 2025’te siber güvenlik uzmanı ve açık kaynak savunucusu Æva Black ile açık kaynak güvenliğinin gelişen ortamı hakkında konuştuk. Black, yazılım tedarik zinciri izlenebilirliği, güvenli açık kaynak yazılımı sürdürmenin zorlukları, SBOM’ların ve içsel tanımlayıcıların rolü ve güvenlik açıklarına yanıt vermede küresel işbirliğinin önemi hakkındaki görüşlerini paylaştı.
Bize biraz geçmişinizden, şu ana kadar nerede çalıştığınızdan ve siber güvenlikteki yolunuzdan bahseder misiniz?
Uzun bir hikaye, biraz tuhaf. Son zamanlarda, Azure CTO’nun Microsoft’taki ofisinde birkaç yıl boyunca açık kaynak yazılım güvenliğine liderlik ediyordum. Daha sonra ABD hükümeti beni CISA’nın açık kaynak güvenliği üzerinde çalışmak üzere işe aldı.
Şu anda Bow Shock Systems Consulting adında küçük bir konsorsiyumun parçasıyım; bu, birlikte çalışan bir grubumuz. Şirketimin adı Node Point Studio. Siber güvenlik ve açık kaynak danışmanlık hizmetleri sağlıyoruz.
Açık kaynak güven üzerine kuruludur ancak aynı zamanda Log4Shell gibi çeşitli güvenlik açıklarını da beraberinde getirmiştir. Bu vakalardan hangi dersleri çıkarmalıyız ve bu güveni nasıl yeniden inşa edip koruyabiliriz?
Aslında açık kaynak topluluklarının güvenilirliği ve şeffaflıkları sayesinde bu güvenlik açıklarına karşı savunma yapabildiğimizi söyleyebilirim. Bu yalnızca küresel işbirliği ve topluluğun ve araçlarının açıklığıyla mümkündür. Ancak gelişmeye devam etmemiz gerekiyor; özellikle de şu anda finansman modelleri söz konusu olduğunda.
Son zamanlarda bakımcı tükenmişliği hakkında daha fazla tartışma gördük. Bunların birçoğu gönüllülerin öncülük ettiği projeler olduğundan, ekosistem bunları boş zamanlarında inşa eden ve sürdüren bireysel geliştiricileri nasıl daha iyi destekleyebilir?
C: Açık kaynak, küçük projelerden dünya çapında birlikte çalışan binlerce geliştiricinin yer aldığı çok büyük konsorsiyumlara kadar oldukça geniş bir katkıda bulunanlar yelpazesine sahiptir. Çoğunlukla dikkat sadece büyük projelere yoğunlaşıyor. Şirketlerden gelen fonlar kolayca onlara gidiyor çünkü görünürler ve genellikle arkalarında büyük pazarlama ekipleri veya vakıflar var.
Bağış alacak tüzel kişiliği olmayan, doğru vergi statüsüne sahip olmayan küçük bir gönüllü ekibini desteklemek çok daha zordur; ya da belki de bunu istemiyorlardır. Belki boş zamanlarında bunun üzerinde çalışıyorlar ya da hala öğrenciler. Ancak bazı şirketler hâlâ yazılımlarını kullanmayı tercih ediyor.
Şeffaflık konusundaki gerilimin bir kısmı da burada yatıyor. Siber Dayanıklılık Yasası (CRA), gereksinimleri değiştiriyor ve üreticilerin, ürünlerine dahil ettikleri tüm yazılımların sorumluluğunu alması gerektiğini açıkça ortaya koyuyor. Sorumlu tutulabilirler, bu da gerekli özeni göstermeleri, yani iyi, güvenli açık kaynak kullanım uygulamalarını takip etmeleri ve katkıda bulunmaları gerektiği anlamına gelir.
Bu yalnızca bağımlılıklarının veya ticari satıcılarının en üst katmanına bakmakla ilgili değil; tedarik zincirlerinin ve kullandıkları tüm açık kaynak bileşenlerin tüm derinliğini anlamak ve bunları en iyi şekilde nasıl sürdürebileceklerini bulmakla ilgili.
Sunumunuzda tasarımla güvenli, taleple güvenli olmak kavramlarından bahsettiniz. Bu, üreticiler ve tüketiciler arasında ortak bir sorumluluğun olduğunu göstermektedir. Bu denge gerçekçi bir şekilde nasıl sağlanabilir?
Tüketici açısından ise bu, yalnızca daha fazla şeffaflıkla, yani CRA’nın sunduğu CE işareti gibi ürün etiketlemesiyle mümkün olabilir. Bu, dijital ürün tüketicilerinin, ürünlerinde daha iyi güvenlik talep etmelerine olanak tanır. Elbette insanlar ürüne bakıp ne kadar güvenlik düşünülerek üretildiğini anlamadıkça bu mümkün değil. Gerçekten CRA’nın “talebe göre güvenlik” tarafında bundan daha fazlasını sağlayacağını umuyorum.
Üretim sürecine gelince aynı prensip geçerlidir. Üreticiler ticari tedarikçilerinden güvenlik talep edebilirler ancak açık kaynağa bağımlı olduklarında sorumluluk onlara düşer; topluluktan talepte bulunmak değil, ortaya çıkıp yardım etmek.
Dolayısıyla tasarım açısından güvenlikten bahsettiğimizde, bu, ürün üreten bir şirketin en başından itibaren güvenli tasarımla başlaması gerektiği anlamına gelir. Bu, kullanmayı seçtikleri herhangi bir açık kaynak projesini nasıl sürdüreceklerini düşünmeyi de içeriyor; bu, pek çok ürüne fayda sağlayan ancak aynı zamanda uzun vadeli desteğe de ihtiyaç duyan bir şey.
Ayrıca işletim sistemlerinin milyonlarca satır koda sahip olduğunu ve birçok farklı geliştiricinin katkısı olduğunu da gösterdiniz. Bu karmaşıklık göz önüne alındığında, kuruluşlar güvenlik açıklarını verimli bir şekilde belirlemek için hangi pratik stratejileri benimseyebilir?
Konuşmamda yaklaşık 20 milyon satır koda sahip Linux çekirdeği ve yaklaşık 2 milyar satıra sahip Debian işletim sistemi örneğini kullandım.
Diğer sektörlerde tedarik zinciri güvenliğini yönetme konusunda uzun bir geçmişe sahip olan ETSI ve CEN gibi standart kurumlarımız zaten mevcut. Genellikle yaklaşık 40.000 parçadan oluşan modern bir araba benzetmesini kullanırız; bu tür bir tedarik zincirini yönetmek için standartlar vardır. Ancak şimdi dijital ürünler için tedarik zinciri karmaşıklığında ani ve birkaç kat artışla karşı karşıyayız.
Geleneksel üretimde kullandığımız tekniklerin aynısı burada işe yaramıyor. Tedarik zinciri boyunca dijital bileşenlerin tanımlanmasına yönelik yeni standartlara doğru hızla ilerlememiz gerekiyor. Bu izlenebilirlik olmadan yazılım için makul bir şekilde “ürün geri çağırma” yapamayız.
Fren balatalarınız arızalıysa onları takip edebilir ve geri çağırabilirsiniz. Bir kutu çorba kontamine olursa gıda güvenliği geri çağırma süreci vardır. Ancak şu anda dijital bileşenler için bu tür bir izlenebilirliğe sahip değiliz ve bu benim birkaç yıldır savunduğum bir şey.
Buna SBOM’lar veya başka bir şey dahil mi?
SBOM’lar bunun için iyidir ancak yalnızca SBOM kullanmak yeterli değildir. Bunu bir kutu çorbanın içindekiler listesi gibi düşünebilirsiniz; bu liste size yer fıstığı gibi bir şeye alerjiniz olup olmadığını söyleyebilir, böylece bilinçli bir seçim yapabilirsiniz. Bu faydalıdır ancak çiftlikten üreticilere, mağazaya ve tüketiciye kadar tam izlenebilirlik için yeterli bilgi sağlamaz. OMNIBOR, NIC’ler veya yazılım karma kimlikleri gibi içsel tanımlayıcıları birleştiren bir şeyin yardımcı olabileceği yer burasıdır.
Yeniliği engellemeden açık kaynak güvenliğini sağlamak için ne tür bir politika veya sertifika çerçevesini desteklersiniz?
CRA son birkaç yılda birçok diyalog gerçekleştirdi. Geçen yılın sonunda onaylandığında, açık kaynağı açıkça muaf tutuyor ve küçük ve orta ölçekli işletmelerin katı düzenlemeler olmaksızın açık kaynağa katkıda bulunmaları ve bunları kullanmaları için inovasyon potansiyelini ve esnekliğini korumaya çalışıyor. Bu, yasal metinde çok açıktır ve Komisyonun kamuoyuna yaptığı açıklamalarla da desteklenmektedir.
CRA, ürünlerde açık kaynak kullanımını etkilemekte ve aynı zamanda açık kaynağın sürdürülmesini teşvik edecek mekanizmalar kurmaya çalışmaktadır. Avrupa çapında Asylum Tech Agency gibi pek çok girişim görüyorum ve yakın zamanda açık kaynak altyapısının güvenliğine ve sürdürülmesine yardımcı olmak için Avrupa çapında bir “teknoloji fonu çözme” önerisi geliyor. Çok fazla hareket var ama elbette hala yapılması gereken işler var.
Küresel topluluğun açık kaynaklı yazılım açıklarını (kültürel, teknik veya kurumsal olarak) nasıl ele aldığıyla ilgili bir şeyi değiştirebilseydiniz bu ne olurdu?
Aslında iki şeyi değiştirirdim; bunlar birbiriyle bağlantılı, yani bu bir nevi kapsayıcı bir değişiklik ama her parça diğerine bağlı.
“Sihirli değneğim” ile derleyicilere içsel tanımlayıcılar ekler ve açık kaynakta isteğe bağlı ancak varsayılan olarak açık olan araçlar oluştururdum. Zamanla tüm açık kaynaklı yazılımlar izlenebilir hale gelecektir. İnsanlar isterlerse bunu kapatabilirler ancak bu, koordineli güvenlik açığı müdahalesinin bugün olduğundan çok daha hızlı ve kesin olmasını sağlayacaktır.
Örneğin, bir bileşen tedarik zincirinin derinliklerine gömülüyse (SBOM’unuzda görünmeyecek kadar derinde) ve geliştirici Log4Shell gibi ciddi bir güvenlik açığının olduğunu fark ederse, kendi bileşeninin bu tanımlayıcısını küresel CVE kaydına ekleyebilir.
Diğer değişiklik ise CVE programını daha fazla katılımcıyla küresel olarak daha işbirlikçi hale getirmektir. CVE programı yıllardır genişlemektedir ve şu anda birkaç yüz CVE Numaralandırma Yetkilisini içermektedir. Bu genişlemenin de devam etmesi gerekiyor.
İzlenebilir bir ağaç yapısındaki belirli bir tanımlayıcıyla, nihai ürünler, içine giren tüm küçük bileşenlerin tam bir grafiğine sahip olacaktır. Bir tüketici olarak, karma tanımlayıcıya bakabilir ve güvenli olup olmadığını veya savunmasız bir bileşenin ürünlerimin yığınının derinliklerinde bir yere gömülmesi nedeniyle etkilenip etkilenmeyeceğini görmek için karma tanımlayıcıya genel bilgilerle çapraz referans verebilirim. Savunmasız olduğunu kesin olarak bilmesem bile, en azından potansiyel bir risk olduğunu bilir ve harekete geçebilirim. Bence bu, şu anda kimsenin sahip olmadığı inanılmaz derecede yararlı bir bilgi çünkü mevcut araçlarımız buna olanak vermiyor.
ETSI’ye dönersek, dünya için daha güvenli açık kaynaklı yazılımların şekillendirilmesinde ETSI gibi kuruluşların rolünü nasıl görüyorsunuz?
ISO gibi geleneksel Standart Geliştirme Organizasyonlarının (SDO’lar) hızı ile IETF, Apache veya diğer açık kaynak projelerinden herhangi biri gibi açık kaynak yazılım toplulukları ve standartlarının hızı arasında bir yazılım geliştiricisi olduğum sürece bir gerilim vardı. Açık kaynak, geleneksel SDO’lardan çok daha hızlı hareket ediyor ve bu gerilim artık bir yol ayrımına geldi.
Birkaç yıl önce ISO, açık kaynak ihtiyacı olduğunda daha hızlı standardizasyon için hızlı bir yol oluşturdu ve bence bundan daha fazlası (açık kaynak projelerinin standartlara ulaşmasını sağlamak) çok faydalı olacaktır.
Yıllar geçtikçe, artık tüm bu yazılım geliştirme gruplarımız var ve her zaman bazı tepkiler oluyor, ancak asıl zorluk şu ki, ETSI’de yazılım oluşturabiliyor olmanız, yazılımın ETSI dışındaki daha geniş açık kaynak topluluklarını destekleyebileceği anlamına gelmiyor.
