Merhaba

Bu kelimeyi ilk kez bir ay önce duydum. Anton Chuvakin kavramı bir gönderisinde kullanmış ve tanımı hakkında topluluktan geri bildirim istemişti.

Şöyle yazmıştı.

“Anton’ın Vulnpocalypse’i, zero-day’ler dahil olmak üzere yazılım açıklarının sayısındaki hızlı bir sıçramaya, bunlara dayalı exploitation’a ve ortaya çıkan zarara eşittir.”

İki kez okudum. İçimden bir şey, ikinci okumayı bitirmeden önce bunu tanıdı. Şaşkınlık değil. Tanıma. Bu, er ya da geç geleceğini zaten bildiğim bir şeydi ve nihayet bir adı olmuştu. Bir şey yerine oturdu, bir başka şey ise oturmadı.

Yerine oturan kısım açıktı. Bir sıçramanın içinden geçiyoruz. Bir vulnerability feed’ine, bir threat intelligence masasına ya da bir patch management kuyruğuna yakın olan herkes bunu iliklerinde hissediyor. Bu yıl hacim farklı. Biraz farklı değil. Yapısal olarak farklı.

Beni durduran şey ise bu sorunu on yıldır yakından izlemekten geliyordu. Açıkların sayısının asıl mesele olduğunu hiçbir zaman düşünmedim. Açıkları saymak, biraz yağmuru sayıp ona sel demeye benziyor; oysa tehlike hiçbir zaman yağmurun kendisi değildi. Yağmur ancak, baraj arkasında yükselen suyun, kimsenin zamanında kapatmadığı bir çatlağı bulmasıyla tehlikeye dönüşür.

Siber güvenlikte, barajdaki o çatlağın bir adı var. Bir patch’in var olması ile o patch’in uygulanması arasındaki mesafe.

Tanımı Nerede Zorladım

Anton’ın tanımı hacmi yakalıyor. Exploitation’ı yakalıyor. Bana eksik gelen şey ise, hacmi asıl zarara dönüştüren kısım. Exploit’i olmayan bir açık, rezervuarın henüz ulaşmadığı bir su seviyesinin altındaki bir çatlaktır. Exploit’i olan ama remediation önünde sürtünme bulunmayan bir açık, yükselen su ulaşmadan kapatılmış bir çatlaktır. Zarar ancak su, çatlağı bulup kapatabileceğimizden daha hızlı yükseldiğinde birikir.

Bu yüzden tanımın üzerinde bir süre durdum; yalnızca teknik bir kitle için değil, bir yönetim kurulu için de işe yarayıp yaramayacağını görmeye çalıştım.

Vulnpocalypse, zero-day’ler dahil yazılım açıklarının hacmindeki hızlı bir sıçramaya ve bunların exploitation’ına eşittir; bu, patching ve remediation’daki yapısal sürtünmeyle daha da artar ve savunucuların kaldıramayacağı ölçekte zarar üretir.

Bu son cümle argümanın tamamı. Savunucuların kaldıramayacağı ölçekte zarar. Rahatsız edici bulduğumuz bir ölçek değil. Fazladan bir sprint gerektiren bir ölçek değil. Remediation kapasitesinin matematiğinin artık kapanmadığı bir ölçek; ekibiniz ne kadar iyi olursa olsun.

Daha önce bir patch’in kaynak ağacında var olması ile production’da var olması arasındaki boşluk hakkında yazmıştım. Bu boşluk eskiden haftalar ya da aylarla ölçülürdü. Kimse ona bir ad koymadan önce bile bir sorundu. Değişen şey, boşluğun varlığı değil. Değişen şey, artık içine akan şey.

Hiç Eklenmemiş Bir Açık

Bir açığın nasıl var olduğuna dair neredeyse tuhaf bir şey var; onu hızlandıran şeye geçmeden önce üzerinde durmaya değer.

Bir sunucu düşünün. Tamamen patch’lenmiş, tamamen güncel, hiçbir sorunu yok. Kapatın. Kilitli bir odaya koyun. Üç ay boyunca uzaklaşın.

Geri gelin, fişe takın, açın. Sunucu değişmedi. Tek bir dosya bile. Tek bir satır kod bile. Ama artık, kapıyı kapattığınız gün orada olmayan bir avuç kritik açık taşıyor.

O makineye hiçbir şey kurulmadı. Onun hakkında bir şey keşfedildi. İşte bu, bir vulnerability raporu okuyan her yöneticiyi tedirgin etmesi gereken kısım. Açıklardan, bir menteşede oluşan pas gibi sisteme sonradan eklenmiş şeylermiş gibi söz ederiz. Öyle değiller. Zaten oradaydılar. Birisi onları basitçe buldu.

Bu da demek oluyor ki her yönetim kurulu sunumunda, her risk raporunda, her dashboard’da alıntıladığımız sayı, yazılımımızın ne kadar güvensiz hale geldiğinin bir ölçüsü değil. Hiç değişmemiş bir yazılım hakkında başkalarının halihazırda ne kadar çok şey bildiğinin bir ölçüsü.

Ve bu, kimsenin üzerinde uzun süre durmak istemediği rahatsız edici bir soruyu gündeme getiriyor. Onu ilk kim buldu ve bize söyledi mi?

Binlerce insan, geri kalanımızın çalıştırdığı kodu incelemeye ömrünü adıyor. Kimisi vendor için çalışıyor. Kimisi bir bug bounty programı için. Kimisi, hiçbir zaman disclosure yapma niyeti olmayan bir devlet için. Kimisi ise, herhangi bir bug bounty’nin ödeyeceğinden çok daha iyi ödeme yapan ve bir patch’in var olmasıyla hiç ilgilenmeyen alıcılar için.

Üzerinde tartıştığımız açıklar, bir CVE numarası ve bir patch Tuesday’i olanlar, yalnızca birilerinin bilmemize izin verdiği açıklardır. Açıklanan her açık bir keşif değil, bir tercihtir. Hiçbir zaman açıklanmayan, birinin envanterinde doğru anı bekleyerek sessizce duran şey ise, bu sorunun hiçbir dashboard’un asla gösteremeyeceği kısmıdır.

Buldukları şeyin bir kısmı hiçbir zaman CVE’ye dönüşmez. Bir yeteneğe dönüşür. Bir ulus devlet, kullanmayı planladığı bir açığı raporlamaz. Onu, bir ordunun bir silahı depoda tuttuğu gibi tutar; onarmak için değil, tam olarak önemli olan hedefe karşı, tam olarak önemli olan anda bir kez uzanmak için. Suç grupları da aynı şekilde davranır; daha az sabırla ve daha çok açlıkla, çünkü başkasının bilmediği bir açık, çalabilecekleri neredeyse her şeyden daha değerlidir kendi pazarlarında. Bunlar keşfedilmemiş açıklar değil. Sessizlikten inşa edilmiş siber silahlar. Açık en baştan beri oradaydı. Birisi onu raporlamak yerine kullanmayı seçti.

İşte bu yüzden Vulnpocalypse yalnızca sayabildiğimizle ölçülemez. Sayı, görünen tepedir. Geri kalanı ise her zaman olduğu yerde; gözden uzak ve giderek erişilmez.

Kimsenin Fiyatlamadığı Tetikleyici

Şu anda o boşluğa yakıt döken bir şey var ve hiç de üstü kapalı değil. Yeni nesil AI frontier modeller, herhangi bir insan ekibinden daha hızlı kod yazıyor. Aynı zamanda kodu daha hızlı okuyor, kodda örüntüleri daha hızlı buluyor ve giderek kodda açıkları da daha hızlı buluyor. Bir geliştiricinin bir öğleden sonrada bir özellik göndermesine yardım eden aynı yetenek, bir saldırganın o özellikteki bir açığı aynı öğleden sonrada keşfetmesine yardım ediyor.

Daha önce de hızlanma gördük. Open source, on yıl önce bağımlılıkların sayısını patlattı. Cloud’a geçiş, birkaç yıl sonra saldırı yüzeyini katladı. Her seferinde maruziyetin hacmi büyüdü ve her seferinde endüstri yavaş yavaş, acıyla da olsa uyum sağladı.

Bu farklı ve nedenini net söylemek istiyorum. Önceki her hızlanma denklemin tek bir tarafını vurdu. Daha çok kod, daha çok açık demekti. Daha çok cloud, daha çok yanlış yapılandırma demekti. Ama denklemin savunucu tarafı aşağı yukarı insan hızında kaldı. Analistler hala analist hızında triyaj yaptı. Patch’ler hala mühendislik hızında test edildi.

AI frontier modeller denklemin her iki tarafını aynı anda hızlandırıyor. Keşif daha hızlı. Exploit üretimi daha hızlı. Ve savunucu tarafında, yetişmeyi vaat eden araçlar hala çoğunlukla temenni düzeyinde, hala çoğunlukla bir pilot proje, hala çoğunlukla gelecek yılın bütçe talebindeki bir slayt. Eski bir sorunun daha büyük bir sürümüyle karşı karşıya değiliz. Saldırganın araçlarının savunucununkinden daha hızlı olgunlaştığı ilk vulnerability kriziyle karşı karşıyayız.

Vulnerability zaman çizelgelerini yirmi yıldır izliyorum. Örüntü hep aynıydı. Bir açık keşfedilir. Bir patch yazılır. Saldırganların çoğu harekete geçmeden önce bir proof of concept’in ortaya çıkmasını bekler, çünkü çalışan bir exploit yazmak eskiden gerçek beceri isterdi. O bekleme süresi, kendi bozuk yolunda, bir tür merhametti. Savunuculara bir pencere veriyordu.

AI frontier modeller o pencereyi kapatıyor. Her yerde tamamen ortadan kaldırmıyor, henüz değil; ama endüstrinin daha önce planlamak zorunda kalmadığı bir biçimde onu sıkıştırıyor.

Ve unutmayın, bu hızlanma yalnızca kamuya açık alanda gerçekleşmiyor. Bir zamanlar elle bir açığı bulmak için aylar harcayan her araştırmacı, artık raporlamayı da elde tutmayı da amaçlasa, bir öğleden sonrada birkaç tanesini bulabiliyor. Özel envanter, tam olarak kamuya açık olanı kadar hızlı büyüyor; sadece biz onun büyüdüğünü hiç görmüyoruz.

Bu Kadar Erken Görmeyi Beklemediğim Sayı

Şimdiye kadar yazdığım her şey argümandı. İşte kanıt; ve bunu bu kadar erken elimde tutmayı beklemiyordum.

Microsoft, her ayın ikinci Salı günü patch yayınlar ve bunu yirmi yıldır aralıksız yapmaktadır. Bu düzenlilik, bize endüstrideki en temiz yirmi yıllık veri setini verir, çünkü süreç hiç değişmedi. Değişen tek şey, içinden akan hacimdi.

Kaynak: TrendAI Zero Day Initiative

O yirmi yılın çoğunda tırmanış istikrarlı ama sıradandı. Sayı 2007’de 255 CVE ile açıldı. 300’lerden, 500’lerden, 800’lerden yıl yıl geçti; bir güvenlik programının etrafında plan yapabileceği türden bir büyüme. 2020’de 1.250’ye ulaştı; Microsoft’un o güne kadar kaydettiği en yüksek yıllık toplam. Sonraki üç yıl aslında daha düşük geldi: 887, 952, 914; ve eğrinin durulduğuna inanmak istiyorsanız, veriler buna inanmanıza izin veriyordu.

Şimdi 2026’ya bakın. Yalnızca Temmuz, tek bir Patch Tuesday’de 621 CVE’ye karşılık geliyor ve Zero Day Initiative incelemesini yazan Dustin Childs bu sayıyı önemli olan tek bağlama oturttu. Microsoft’un son yirmi yıllık yayınlarına geriye dönük baktı ve yıl-başından-bugüne toplamın kayıtlardaki her önceki yılı çoktan geçtiğini gördü. Ve bu rakam, bu yıl Chromium ve Microsoft Edge’de ayrıca açıklanan yaklaşık 480 ek bug’ı bile içermiyor. O ipin ucunu başka bir güne bırakıyorum, ama size şunu söylüyor: elimizdeki sayı bir tavan değil, bir taban.

Yılın yarısını bile bitirmedik ve Microsoft’un yirmi yılda ürettiği en yüksek tam yıl toplamını çoktan geçtik. Ona yaklaşmadık. Onu geçtik, hem de yüzden fazlasıyla.

Hesabı açıkça yapın, çünkü asıl argüman bu yalın hesap. Yılın ortasını yeni geçtik ve koşan toplam, kendinden önce gelen her tam yılı çoktan geride bıraktı. Önümüzdeki aylar, şimdiye kadar izlediğimiz hıza yakın bir tempoyla açık eklerse, 2026 yalnızca yeni bir rekor kırmakla kalmaz. Eskisinin üzerine bir tur biner; tek bir yılda, önceki zirvesine ulaşması yirmi yıl süren bir veri setinin içinde.

Ve bu yalnızca Microsoft’a özgü bir örüntü değil. Aynı eğriyi ikinci bir büyük vendor’a genişlettiğinizde, tablo tekil bir anomali olmaktan çıkar. Aşağıda Microsoft ile Oracle’ın 2008’den bu yana yıllık açıklanan CVE sayıları yan yana; 2026 ise yalnızca ilk yarı verisi, kesikli çubuklar ise bu tempo yıl sonuna kadar sürerse ortaya çıkacak kaba projeksiyon. Her iki vendor da tek bir yılda, önceki tüm zirvelerinin katbekat üzerine çıkacak bir yörüngede.

Kaynak: cve.org · 2026 rakamları yalnızca ilk yarıyı yansıtır, tam yıl toplamı değildir.

Bir sıçramanın, bir blog yazısındaki bir ifade olmaktan çıkıp bir grafikteki bir çizgiye dönüştüğünde nasıl göründüğü işte budur. Yirmi yılımı vulnerability trendlerini okuyup müşterilere, etrafında bütçe planlayabilecekleri kademeli artışlar beklemelerini söyleyerek geçirdim. Yılın daha yarısındayken, ikinci yarı başlamadan önce yirmi yıllık tarihi kıran bir sayı hakkında yazıyor olacağımı beklemiyordum.

Bu büyüklükte bir sayı tek başına kanıt değil. Hacim, ancak exploitation ve zarar ona yetiştiğinde bir apocalypse’e dönüşür; ve bu yazının geri kalanı tam olarak bununla ilgili.

Kanıtın Diğer Yarısı

Bu yılki Verizon Data Breach Investigations Report  Microsoft sayısının tek başına gösteremediği yarıyı sağlıyor.

Exploitation of vulnerabilities, ihlallerin fiilen nasıl başladığına dair en yaygın yol olarak credential abuse’ı geride bıraktı. Artık bilinen giriş noktalarının yüzde 31’inde yer alıyor; yıllarca başı çeken vektör olan credential abuse ise yüzde 13’e düştü. Bu, bir grafikteki küçük bir kayma değil. İhlallerin baş nedeninin el değiştirmesi; halihazırda var olanı çalan bir teknikten, kimsenin henüz kapatmadığını bulan bir tekniğe geçiş.

Kaynak: Verizon DBIR 2026

Remediation ise aynı anda yanlış yöne gitti. CISA’nın Known Exploited Vulnerabilities listesindeki kritik açıkların yalnızca yüzde 26’sı geçen yıl tamamen patch’lendi; bir önceki yılki yüzde 38’den düşüş. Bir kritik açığı tamamen kapatmanın medyan süresi 32 günden 43 güne çıktı. Ve backlog’un kendisi büyüdü. Tipik kuruluş, bir önceki yıla kıyasla patch’lenmeyi bekleyen yüzde 50 daha fazla kritik açık taşıyordu.

Exploitation tam da remediation yavaşlarken yükseliyor ve ikisinin de arkasındaki kuyruk büyümeye devam ediyor. Bu, yan yana tesadüfen duran iki ayrı sorun değil. Bu, bu yazının anlatıp durduğu sürtünmenin; kaç açığın yayınlandığını değil, ihlallerin fiilen nasıl gerçekleştiğini ölçmek için özel olarak kurulmuş tek veri setinde ortaya çıkması.

Patch Yayınlandıktan Sonraki Yarış

İşte bir patch’in hikayenin sonu olduğunu varsayanları şaşırtan kısım. Bir patch hikayenin sonu değildir. Saldırgan için yeni bir başlangıçtır.

Bir vendor bir düzeltme yayınladığı anda, düzeltmenin kendisi kanıta dönüşür. Bir analist eski kodu yeni kodla satır satır karşılaştırabilir ve tam olarak neyin değiştiğini görebilir. Bu fark, doğrudan patch’in kapatmak için yazıldığı açığı işaret eder. Bu uygulamanın endüstride bir adı var, patch diffing; ve yıllardır gerçek dünyadaki exploitation’ın büyük bir kısmını sessizce üretiyor, çünkü pek çok saldırgan bir zero-day beklemez. Salı’yı bekler, sonra Çarşamba’nın ödevini tersine mühendislikle çözer.

Eskiden gerçek beceri ve gerçek zaman isterdi. Yayınlanmış bir patch’ten çalışan bir exploit’e gitmek günler, bazen haftalar alırdı. O boşluk hiçbir zaman cömert değildi ama en azından bir şeydi. Pek çok kuruluş tüm remediation planını onu geçmek üzerine kurdu.

AI, patch diffing’i saatlere sıkıştırıyor. Bir modele bir patch’in öncesini ve sonrasını verin; çoğu zaman düzeltmeyi bulup açığı yeniden kurgulayabilir ve çoğu change advisory board haftalık toplantısını bitirmeden çalışan bir proof of concept üretebilir. Bu işi bir zamanlar koruyan beceri ortadan kalkıyor. Geriye kalan hız; ve hız artık patch’i yazandan değil, ilk okuyandan yana.

İşte bu yüzden, öncesindeki her şey ne kadar iyi gitmiş olursa olsun, son mesele her zaman patching’dir. Diyelim vendor disiplinli. Diyelim disclosure temiz, patch iyi test edilmiş ve söz konusu sistem tamamen destekli, güncel, yakınında hiçbir legacy bileşen yok. Bunların hiçbiri, patch’in production’a, karşı taraftaki biri onu bir silaha dönüştürmeden önce ulaşacağını garanti etmez. Darboğaz hiçbir zaman vendor hızı değildi. Bizim hızımızdı, ve hala öyle.

Kitabın Kabul Ettiğinden Daha Fazla Vaka

Bu sorunun yalnızca eski, desteklenmeyen, unutulmuş sistemlerde yaşadığına inanmak cazip. Yaşamıyor. Tamamen destekli ortamlar kendi sürtünmelerini taşır ve bu, çoğu vulnerability programının planladığından daha fazla yerde ortaya çıkar.

Güncel, tamamen destekli bir çekirdek sistem çalıştıran bir banka, yine de her patch’i bir change advisory board’dan, bir staging ortamından ve yalnızca ayda bir açılan bir bakım penceresinden geçirmek zorundadır. Vendor düzeltmeyi zamanında yayınladı. Üç haftalık gecikmeyi ekleyen şey, ortada tek bir legacy bileşen yokken, kuruluşun kendi yönetişimi.

Tamamen destekli bir işletim sistemi üzerinde tıbbi cihazlar çalıştıran bir hastane, vendor’ın patch’ini basitçe uygulayamaz, çünkü cihaz üreticisinin önce o güncellemeyi sertifikalandırması gerekir ve o sertifikasyon döngüsü günlerle değil aylarla ölçülür. İşletim sistemi vendor’ı her şeyi doğru yaptı. Cihazın etrafına sarılı ekosistem, patch hızında hareket edecek şekilde hiç kurulmamıştı.

Hepsi güncel, hepsi destekli birkaç bin point of sale terminali olan bir perakendeci, iş gününün ortasında başarısız bir dağıtım riskine girmeden tek bir patch’i her terminale aynı anda gönderemez. Güncelleme dalgalar halinde çıkar ve o kuyrukta hala bekleyen her terminal, kendi dalgasının gelmesi tam olarak ne kadar sürüyorsa o kadar süre maruz kalır.

Başkasının patch’lenmiş bir bileşenini kendi ürününün içine paketleyen bir yazılım vendor’ı, müşteriler güvenle güncelleyebilmeden önce kendi sürümünü yeniden sertifikalandırmak zorundadır. Bu gecikme ne asıl vendor’a ne de müşteriye aittir. Kimsenin etrafında bir zaman çizelgesi kurmadığı, aradaki katmana aittir.

Bu kuruluşların hiçbiri legacy teknoloji çalıştırmıyor. Her biri tamamen destekli, tamamen güncel ve yine de saldırganın ihtiyaç duyduğundan daha uzun süre maruz. Patching, upstream’deki her şey tam da amaçlandığı gibi çalışsa bile, ne kadar hızlı hareket edebileceğimizin her zaman tavanıydı.

İkinci Katlayıcı Güç

AI modeller hızlandırıcıysa, legacy sistemler kuru odundur. Birlikte çalıştığım her kuruluş, kimsenin dokunmak istemediği bir altyapı katmanı taşır. Kimsenin taşımaya cesaret edemediği tek bir kritik süreci çalıştıran eski işletim sistemleri. Vendor yıllar önce desteği bıraktığı için mevcut patch’i olmayan uygulamalar. Bir tesisi kapatmadan çevrimdışına alınamayan endüstriyel kontrol sistemleri. Bu sistemler, bu yeni açık dalgası gelmeden önce bile herhangi bir patching döngüsünün en yavaş parçasıydı.

Şimdi, zaten olduğundan daha hızlı hareket edemeyen bir ortamın üzerine daha hızlı bir keşif döngüsü ve daha hızlı bir exploitation döngüsü bindirin. Boşluk yalnızca sürmez. Aynı anda her iki uçtan da genişler. Keşif öne fırlar. Remediation ise legacy sistemlerin her zaman gerektirdiği aynı yavaş, dikkatli, çoğu zaman haklı temkine bağlı kalır.

Vulnpocalypse’in nadiren manşetlere çıkan kısmı budur, çünkü göz alıcı değil. Kimse tedarik zincirini kırmadan patch’lenemeyen on beş yıllık bir veritabanı hakkında yazmıyor. Ama o gösterişsiz sistem, bir sonraki büyük ihlalin başlaması en muhtemel olan yer. Daha önce de söyledim: bir kuruluştaki en büyük risk nadiren en yeni sistemdir. Herkesin ilgilenmeyi bıraktığı sistemdir.

Legacy sistemler, açıklardaki bir sıçramayı kalıcı bir yapısal açığa dönüştürür. Bir kısmı en baştan hızlı patch’lenecek şekilde hiç kurulmamış bir varlık envanterine sahipken, bir sorunu patch’leyerek geçemezsiniz.

Anton’ın On Beş Dakikalık Sorusu

Yarın uyandığınızı ve saf bir sihirle ortamınızdaki her açığın, düzeltme yayınlandıktan sonraki on beş dakika içinde patch’lenebildiğini hayal edin. Sunucular, uygulamalar, işletim sistemleri, hepsi. Rüya gerçek oldu.

Şimdi zor kısmı yapın. O gerçekliği tersine mühendislikle çözün.

On beş dakikalık bir patch penceresinin gerçekten işe yaraması için ortamınız hakkında neyin doğru olması gerekirdi? Hangi sistemlerin yeniden inşa edilmesi gerekirdi? Hangi onay adımlarının ortadan kalkması gerekirdi? Herhangi bir açık ortaya çıkmadan çok önce, hangi bağımlılıkların bilerek koparılması gerekirdi?

Bu egzersizi dürüstçe yapın ve on beş dakikaya inmeyeceksiniz. Neredeyse hiç kimse inmeyecek ve Anton da aksini iddia etmiyor. Ama onu kullanamayacağınızı açıklarken, kuruluşunuzun yıllar içinde, her seferinde tek bir kararla, hızın yerine kolaylığı seçtiği tam yerlerin bir listesini bulacaksınız. Sihirli değnek hiçbir zaman asıl mesele değildi. Onu neden kullanamayacağınızı açıklarken kurduğunuz liste asıl meseledir.

O liste, gördüğüm herhangi bir olgunluk modelinden daha iyi bir yol haritasıdır, çünkü başkasının çerçevesinden değil, kendi mimarinizden inşa edilmiştir. On beş dakikanın tam olarak nerede kaybolduğunu size söyler ve o yerlerin her biri, teoride, düzeltmeyi seçebileceğiniz bir yerdir.

Ona Ad Vermek, Onunla Nasıl Savaştığımızı Değiştirir

Anton, bu ana bir ad vererek son derece değerli bir şey yaptı. Bir olguya ad vermek, bir oda dolusu yöneticiyi onu gürültü olarak görmeyi bırakıp, kendine özgü bir yanıt gerektiren kendine özgü bir sorun olarak görmeye zorlar. Ben adın üzerinde biraz daha durmak ve yalnızca açıkların sayısını değil, hacmi zarara dönüştüren sürtünmeyi de taşıyıp taşıyamayacağını görmek istedim.

Açıklardaki hızlı bir sıçrama bir manşettir. Patching’deki yapısal sürtünmenin, hareket edemeyen legacy sistemlerle çarpışması ve bu sırada AI’ın bir saldırganın bir açığı silaha dönüştürmek için ihtiyaç duyduğu süreyi sıkıştırması, işte o bir krizdir.

Endişelenecek açık konusunda sıkıntımız yok. Hiçbir zaman olmadı. Sıkıntımız olan şey, boşluğu bize karşı kullanılmadan önce kapatacak kurumsal hız. O boşluk yeni değil. Sadece arkasında hiç bu kadar baskı ya da eski mazeretlerimize karşı bu kadar az sabır olmamıştı.

Sel hiçbir zaman yağmurla ilgili değildi. Her zaman, hiç kapatmadığımız barajdaki çatlakla ilgiliydi.

Başka bir yazımızda görüşmek dileğiyle….

---

Kaynakça