OWASP SPVS: Yazılım Güvenliğini Sağlama Dersleri Pipeline

Yıllarca saldırganlar uygulamaları tek tek hedef aldı. Taktiklerini değiştirdiler: Tek bir uygulamayı tehlikeye atmak yerine neden hepsini birden tehlikeye atmayasınız? pipeline Pek çok ürün üreten mi? Xygeni'nin ürünü mü? Kötü Amaçlı Yazılım Erken Uyarı Sistemi (MEW) algılandı 2025 yılında 4,452 zararlı yazılım paketi hem de 2026'da şu ana kadar 1,281 kişi daha fazla.Son birkaç yıldaki her önemli olay, yazılım dağıtım zincirinin farklı bir halkasını etkiledi:

• Güneş Rüzgarları (2020): Yapı ortamında güvenlik açığı; 18,000 müşteriye gizlice gönderilen güncellemeler.
• Codecov (2021)Yanlış yapılandırılmış bir Docker imajı, saldırganların bir bash yükleyici betiğini değiştirmesine ve 23,000'den fazla müşterinin CI sırlarını sızdırmasına olanak sağladı.
• CircleCI (2023)Bir mühendisin dizüstü bilgisayarındaki oturum çerezlerinin çalınması, üretim erişim belirteçlerine dönüştürüldü; her müşteriye tüm gizli bilgileri değiştirmesi söylendi.
• XZ Utils'in arka kapısı (2024) :Neredeyse tüm Linux dağıtımlarına ulaşan, çok yıllık bir sosyal mühendislik kampanyası.
• tj-eylemleri (2025) — 23,000'den fazla depoda kullanılan bir bileşeni zehirleyen bir GitHub Actions tedarik zinciri zincirleme reaksiyonu.
• Saldırı Aqua Trivy hem de kontrol işareti (2026) — TeamPCP kampanyası, yaygın olarak kullanılan iki güvenlik tarayıcısını saldırı vektörüne dönüştürdü ve ardından çalınan verileri kullandı. CI/CD Kimlik bilgilerinin npm, OpenVSX ve PyPI'ye kademeli olarak aktarılması.

Her saldırı, sistemin farklı bir bölümünü hedef aldı. pipelineDerleme ortamı, CI araçları, bağımlılıklar, geliştirici kimlik bilgileri, bakımcı güveni, yapıtlara yönelik değiştirilebilir referanslar. Çoğu kuruluş, nokta kontrolü, CI'da bir tarayıcı, kimlik sağlayıcısında 2FA, dal koruması ile yanıt verir. mainGenellikle eksik olan şey, soru sormanın bir yoludur. Sistematik olarak güvence altında mıyız? ziyade Son olaydan sonra X'i etkinleştirmeyi hatırladık mı?

Uygulama güvenliği sağlayıcıları tam olarak hedef tahtasında yer alıyor; bunlardan birinin güvenliğinin ihlal edilmesi, onların ürünlerine güvenen her müşteriyi etkiliyor. Reaktif kontrollerden sistematik bir yaklaşıma geçme baskısı teorik değil, gerçektir.cisOWASP SPVS'yi benimsemenin ardındaki motivasyon neydi? standard en öncelikli proje olarak.

SPVS Nedir ve Yapısı Neden Önemlidir?

Olayın başlangıç ​​hikayesi basit. LASCON 2023'te Farshad Abasi ve Cameron Walters birbirlerine sürekli aynı soruyu soruyorlardı: ASVS nerede? pipelineOWASP ASVS, uygulama güvenliğine kapsamlı ve doğrulanabilir bir yaklaşım kazandırmıştı. standardBunun eşdeğeri hiçbir şey mevcut değildi. CI/CD.

OWASP Top 10 listesi vardı. CI/CD Risks, farkındalık odaklıydı, test edilemezdi; SLSA, yalnızca derleme kökenine odaklandı; S2C2F, yalnızca bağımlılık tüketimine odaklandı; ve OpenSSF Her biri belirli veri tabanı kontrollerini kapsayan puan tablosu. Her biri bir parçayı kapsıyordu, hiçbiri tamamını kapsamıyordu.

Çerçeve veya Proje	Birincil Kapsam
OWASP Top 10 CI/CD Riskler	Farkındalık odaklı CI/CD Risk kılavuzu, test edilebilir bir doğrulama değil. standard.
SLSA	Eserlerin kaynağını ve bütünlüğünü belirleyin.
S2C2F	Bağımlılıkların güvenli bir şekilde tüketilmesi.
OpenSSF karne	Depo düzeyinde özel güvenlik kontrolleri.

Aradaki fark: Her çerçeve önemli bir parçayı kapsıyordu. software supply chain securityAncak bunların hiçbiri uçtan uca, doğrulanabilir bir çözüm sunmadı. standard bütün için CI/CD pipeline.

Bu görüşme iki yıllık bir çalışmaya dönüştü ve Ekim 2025'te SPVS çalışma grubu v1.0'ı yayınladı: Planlama, Geliştirme, Entegrasyon, Yayınlama, İşletme yaşam döngüsü boyunca 127 gereksinim, üç olgunluk seviyesine ayrıldı: L1 Temel, L2 Standardve L3 İleri Düzey. Her gereksinim NIST SP 800-53 ve OWASP ile eşleştirilmiştir. CI/CD İlk 10 ve CWE.

Çoğu kuruluşun zorlandığı nokta burası. Bağımlılıkları tarıyorlar ama sürüm yönetimine aldırmıyorlar. Yapıtları imzalıyorlar ama tehdit modellemesi yapmıyorlar. pipeline Mimari alanında çalışıyorlar. Üretim ortamlarını izliyorlar ancak derleme ortamlarını izlemiyorlar.

Bu, çabayı haklı çıkaran tezdir. Bir aşamadaki güçlü yönler, diğer bir aşamadaki zayıf yönleri telafi etmez. Saldırganların kırması gereken tek bir bağlantı vardır. Bir yaşam döngüsü. standard Sizi hepsini kontrol etmeye zorlar ve L1'den L2'ye, L3'e doğru ilerleme, gereksiz ayrıntılara girmeden bunu yapmanızı sağlar. SPVS, SLSA, S2C2F, Scorecard veya Sigstore'un yerini almaz; size her birinin nereye uyduğunu gösteren bir iskelet sunar.

Uyarlama Standard Kuruluşunuza

İlk doğal adım, kuruluşunuzun ve yazılım altyapınızın her bir gereksinime göre doğrudan denetimini yapmaktır. Resmi kaynaklardan alınan verilerle oluşturulmuş bir Google Sheets tablosu. SPVS gereksinimleri CSV Başlangıç ​​noktası olarak iyi iş görüyor. Üç görünüm faydalı: her kontrol için durum ve sahibi içeren bir gereksinim matrisi, depo başına bir ısı haritası ve bir dashboard Aşamalar ve seviyeler bazında ilerlemenin izlenmesi. Elde edilen sonuçlar, planlamadan işletmeye kadar her aşamayı kapsayan, sürekli güncellenen bir belge olan teknik yol haritasına doğal olarak entegre olur.

Çoğu olgun mühendislik organizasyonu, bu ilk haritalamayı yaptıklarında zaten L2 seviyesinde olacaktır. Bu aslında iyi bir durumdur: ilk aşama, sıfırdan temeller oluşturmak yerine belirli eksiklikleri gidermeye odaklanabilir.

Ancak bir elektronik tablo yalnızca anlık bir görüntüdür ve SPVS daha fazlasını ister. V1.1.7, VCS yöneticilerinin üç ayda bir denetlenmesini zorunlu kılar; V5.1.1'den V5.1.3'e kadar olan sürümler düzenli kullanıcı denetimleri, erişim günlüğü incelemesi ve ayrıcalıklı erişim izlemesi ekler; V2.1.x, V3.3.x ve V4.2.x kontrollerinin birçoğu sürekli iş akışı-YAML temizliği gerektirir. Kuruluş genelinde elle yürütülen bu işlem, her çeyrekte yarım günlük tıklama takibi anlamına gelir ve sessizce gözden kaçma riski taşır. Bu, ya otomatikleştirilen ya da ancak kötü bir şey olduktan sonra gözden geçirilen türden bir iştir.

Bazı SPVS kontrolleri tek seferlik kontrol listesi öğeleri değildir. Bunlar, depolar, kullanıcılar, iş akışları ve ayrıcalıklı erişim genelinde tekrarlayan inceleme, denetim kanıtı ve sapma tespiti gerektirir.

SPVS Alanı	Gereksinim Türü
V1.1.7	VCS yöneticilerinin üç aylık denetimi.
V5.1.1–V5.1.3	Düzenli kullanıcı denetimleri, erişim kayıtlarının incelenmesi ve ayrıcalıklı erişim izleme.
V2.1.x, V3.3.x, V4.2.x	Devam eden iş akışı YAML temizliği.

Çözüm, kuruluş sahibi kimliği altında çalışan ve yapılandırılmış üç aylık bir paket üreten araçlar oluşturmak veya benimsemektir: yönetici listesi, dal koruması, CODEOWNERS kapsamı, sabitlenmiş eylemlerle iş akışı YAML hijyeni, açık izinler, pull_request_target Giriş kontrolü, üye 2FA, kurulu GitHub Uygulamaları ve dağıtım anahtarları. Eskiden yarım gün süren elektronik tablo araştırmaları, artık JSON ve Markdown çıktısı veren tek bir komut haline geldi. Çeyrek dönemlik değerlendirmeler arasında CISOrganizasyon ve yönetici kadrosu bir de haline geliyor.cisBu, veri toplama amaçlı bir toplantı değil, bir bilgi paylaşım toplantısıdır ve eyleme geçirilebilir bulgular, ciddiyet tabanlı SLA'lara sahip birikmiş iş sorunları haline gelir.

Onaylı yöneticiler, onaylı uygulamalar ve depolar ile iş akışları için işlevlere göre izinler de dahil olmak üzere bir izin listesi politikası, güvenlik ekibinin PR incelemesiyle denetlenen, sürüm kontrollü bir depoda YAML olarak yer almalıdır. Herhangi bir izin listesi değişikliği bir inceleme izi bırakır, böylece denetim kanıtı kendiliğinden oluşturulur. Bunun etkisi, "üç ayda bir denetim yapmalıyız" gibi ideal olan kontrolleri, "bu çeyreğin denetimi Pazartesi günü yapıldı" gibi rutin kontrollere dönüştürmek ve kuruluşa uçtan uca ilkenin gerektirdiği sapma tespiti için tekrarlanabilir bir mekanizma sağlamaktır.

Önlem Almanız Gereken Sürtüşmeler

Teknik kontroller kolay kısım. İnsanlar daha zor.

En göze çarpan örnek neredeyse her zaman CODEOWNERS'tır. Ek olarak .github/workflows/ @your-org/security Her depoda bu işlemi yapmak önemsiz gibi görünüyor. Bir dosya, bir satır. Ancak bu, yıllardır iş akışı değişikliklerini kendi kendine birleştiren mühendislerin artık bir güvenlik incelemesine ihtiyaç duyduğu anlamına geliyor. Güvenlik konusunda bilinçli kişiler bile itiraz ediyor: Bu iş akışını ben yazdım, anlıyorum, neden bekliyorum?

Nedenini belirlemek için gerçek bir konuşma gerekir. İş akışları kimlik bilgilerini sızdırabilir, dosyaları yeniden yönlendirebilir ve alt kademe tüketicileri zehirleyebilir. İkinci bir gözün bakması güvensizlik anlamına gelmez; üretim veritabanı değişikliklerinde dört gözün bakmasıyla aynı mantıktır. Sektörden veya kendi ortamınızdan somut, yakın tarihli bir tedarik zinciri olayına işaret etmek son derece yardımcı olur. Hiçbir şey, bir kontrolün yokluğunun gerçek bir örneği kadar etkili olamaz.

Diğer sürtünmeler de aynı şekli izler:

• Açık izinler: İş akışlarındaki engellemeler, katkıda bulunanlar kapsamlı izinleri anlayana kadar CI hatalarına neden olur. Bu bir izin sorunu değil, zihinsel model sorunudur.
• Etiketin değiştirilemezliği: Yıllardır sessizce yeniden etiketleme yapan sürüm araçlarını bozuyor.
• imzalı commits: GPG veya SSH anahtarları tüm iş istasyonlarında doğru şekilde kurulana kadar, yeni kullanıcıların sisteme entegrasyonunda zorluklar yaşanır. SPVS bunu yalnızca ana depolar ve katkıda bulunanlar için değil, her depo ve katkıda bulunan için zorunlu hale getirir.
• Klasik kişisel erişim belirteçlerinin yerini alacak olanlar: Birçok depoyu ve iş akışı dosyasını kapsayan bu özellik, neredeyse her ekibi etkiliyor.

İşe yarayan yöntem şu: Her bir kontrolü, engellediği belirli bir tehditle birlikte tanıtın, bir veya iki depoda pilot uygulama yapın, izin verilen istisnalarla birlikte kullanıma sunun ve tanımlanmış bir zaman çizelgesinde istisnaları devre dışı bırakın. En çok karşı çıkan mühendisler, mantığını anladıklarında çoğu zaman en güçlü savunucular haline gelirler.

Daha derin bir nokta: Uçtan uca ilke burada devreye giriyor. Seçme ve ayırma yapamazsınız. Sürüm yönetimini gevşek bırakırken derleme aşamasını güçlendirmek, yanlış bir güven duygusu yaratır ki bu da SPVS yazarlarının tam olarak belirttiği başarısızlık biçimidir. Belirli bir kontrol tek başına orantısız görünse bile, her aşama birlikte ilerlemelidir.

Tutar: 1. Aşama için yaklaşık bir aylık mühendislik süresi harcandı; bu süre, DevOps, Güvenlik ve mühendislik inceleme ekiplerine dağıtılmış, küçük bir kuruluş için L2 uyumluluğuna odaklandı. Yatırım kolayca geri ödeniyor. Önlenen tek bir tedarik zinciri olayı, yatırımın karşılığını defalarca veriyor. Daha büyük kuruluşlar orantılı olarak daha fazla bütçe ayırmalıdır, ancak aşamalı L1'den L2'ye ve L3'e uzanan yapı, program tamamlanmadan önce değer sunulmasını sağlıyor.

Sırada Ne Var?

SPVS v1.5, yapay zeka ile ilgili kontrollerle birlikte yakında geliyor: yapay zeka destekli kodun kaynağı, guardrails LLM'leri çağıran CI iş akışları için, yapay zeka tarafından oluşturulan izleri inceleyin. pull requestsAyrıca, saldırganların yapay zekâ kodlama asistanlarının hayal ettiği paket adlarını kaydettiği slopsquatting gibi ortaya çıkan tehditlere ve CrowdStrike'ın sahada bildirdiği operasyonel yapay zekâ tarafından üretilen kötü amaçlı yazılımlara karşı savunmalar da bulunmaktadır. Yapay zekâ destekli e-postaları zaten etiketleyen kuruluşlar... commitKurum içi geliştirme yönergelerinde yer alan yöneticiler ve halkla ilişkiler sorumluları, bu uyarlamanın yeni bir çalışma programı yerine kademeli bir süreç olduğunu göreceklerdir.

Sürüm 2.0'ın, çalışma zamanı izleme ve kimlik doğrulama yaşam döngüsü gereksinimlerini derinleştirmesi bekleniyor. Makul bir organizasyonel yol haritası: 2026 yılının 2. çeyreğinin sonuna kadar kalan L3 açıklarını kapatmak, buna şunlar dahildir: SLSA provenance entegre standard CI/CDÜretim dağıtımları için manuel kontroller ve merkezi kimlik sağlayıcısı kullanılır, ardından bakım moduna geçilir. Her yeni depo uyumlu olarak başlatılır ve her üç aylık denetim, sapmaları erken aşamada tespit eder.

Farshad Abasi'ye, Cameron Walters'a ve OWASP SPVS çalışma grubuna içten teşekkürlerimi sunuyorum. Bu tür projeler, tedarik zinciri güvenliğini reaktif değil, sistematik bir şekilde yapmak isteyen her kuruluş için çıtayı düşürüyor.

Önemli Noktalar

Belirli bağlamımızın ötesine de uygulanabilecek birkaç şey:

• Denemek için: SPVS gereksinimlerini içeren CSV dosyasını indirin ve mevcut kontrollerinizi bir elektronik tabloya aktarın. Uygun olup olmadığını bir gün içinde öğreneceksiniz.
• Hedeflediğiniz bir seviyeyi seçin ve bir sonraki seviyeye geçmeden önce onu tamamlayın. L1'den L2'ye, oradan da L3'e geçiş bir sınırlama değil, bir özelliktir.
• MKS pipeline hedeftir. Uygulama merkezli kontroller gerekli ancak yeterli değildir; pipeline birinci sınıf bir saldırı yüzeyi olarak.
• Tümünü doğrulayın. pipelineTek bir parça değil. Bağımlılık taramasındaki güçlü yönler, zayıf sürüm yönetimi veya denetlenmeyen derleme ortamlarının eksikliklerini telafi etmez.
• Elektronik tablolar anlık görüntülerdir; sapmalar süreklidir. Denetimler arasındaki sapmaları tespit etmek için, mütevazı bir şirket içi araç bile olsa, otomasyon geliştirin.
• Organizasyonel iş, teknik işten daha zordur. Görüşmeler ve devreye almadan önce yapılacak pilot uygulamalar için zaman ayırın ve her bir kontrol bloğunun oluşturduğu özel tehdidi açıklayın.

Daha Fazlasını Okuyun

• OWASP: Güvenli Pipeline Doğrulama Standard (SPVS) v1.0OWASP Projesi Sayfası.
• Farshad Abasi: OWASP SPVS'yi Neden Oluşturduk?OWASP SPVS Makaleleri.
• Farshad Abasi: Pipeline Saldırılar Giderek Kötüleşiyor. İşte Nasıl Hazırlanmalısınız?OWASP SPVS Makaleleri.
• Farshad Abasi: OWASP SPVS ve Diğer Tedarik Zinciri ÇerçeveleriOWASP SPVS Makaleleri.
• OWASP: Üst 10 CI/CD Güvenlik riskleriOWASP Projesi Sayfası.
• SLSA: Yazılım Ürünleri için Tedarik Zinciri Seviyeleri. slsa.dev.
• OpenSSF: karne. güvenlikpuankartları.dev.