Örnek sorular
Ds Pipeline Security GatesZorluk 1
Tipik bir CI/CD güvenlik-kapısı pipeline'ında SAST genellikle neden SCA ve DAST'tan ÖNCE yerleştirilir?
- aSAST'ın çalışması için tam olarak deploy edilmiş, çalışan bir örnek gerekir, bu yüzden diğer tüm kapılardan sonra gelmelidir
- bSAST her zaman en yavaş kapıdır, bu yüzden ekipler hızlı kontrolleri engellememek için onu en sona koyar
- cSAST sadece kaynak koda ihtiyaç duyar, bu yüzden bir artefakt oluşmadan build'den hemen sonra çalışabilir✓
- dSAST, SCA ve DAST'ın yerini tamamen alır, bu yüzden diğer kapılar isteğe bağlı hale gelir
Açıklama:SAST kaynak kodu ya da derlenmiş artefaktı doğrudan analiz eder, bu yüzden build adımından hemen sonra çalışabilir; bu, artefakt paketlenip bağımlılık taramasına (SCA) ya da deploy edilip dinamik teste (DAST) tabi tutulmadan çok önce gerçekleşir. Erken yerleştirmek geliştiricilere mümkün olan en hızlı geri bildirimi sağlar.
Ds Pipeline Security GatesZorluk 1
SCA (yazılım kompozisyon analizi), neden genellikle ham kaynak kod yerine çözümlenmiş bir bağımlılık manifestosuna (örn. bir lockfile'a) karşı çalışır?
- aLockfile'lar her zaman daha küçüktür, bu yüzden diğer tüm pipeline artefaktlarından daha hızlı taranır
- bGeçişli bağımlılıkların tam olarak hangi sürümlerinin çözümleneceği ancak lockfile üretildikten sonra bilinir✓
- cHam kaynak kod, manuel açıklama olmadan hiçbir otomatik araç tarafından okunamaz
- dSCA araçları sadece binary artefaktlarla uyumludur, metin dosyalarıyla asla çalışmaz
Açıklama:SCA'nın doğrudan ve geçişli bağımlılıkların gerçekte hangi sürümlerinin projeye dahil edileceğini kesin olarak bilmesi gerekir; bu çözümleme yalnızca bağımlılık çözümlemesinden sonra üretilen lockfile/manifestoda mevcuttur, kaynak koddaki ham import ifadelerinde değil.
Ds Pipeline Security GatesZorluk 2
Bir ekip, production'a benzeyen bir staging ortamına karşı DAST'ı production deploy'undan önceki EN SON kapı olarak çalıştırıyor. Bu aşamada kritik bir SQL injection bulunuyor. Bunu SAST ile pipeline'ın daha erken bir noktasında yakalamaya kıyasla, sadece burada yakalamanın temel dezavantajı nedir?
- aDüzeltme artık tam bir yeniden build, önceki her kapının yeniden çalışması ve yeni bir staging deploy'u gerektirir✓
- bDAST bulguları SAST bulgularına kıyasla daha az güvenilir kabul edilir, bu yüzden gerçek olmayabilir
- cÇoğu çerçeve altında staging ortamlarında DAST taraması çalıştırmaya izin verilmez
- dSQL injection hiçbir koşulda SAST araçları tarafından tespit edilemez
Açıklama:DAST pipeline'ın sonunda yer aldığı için, burada bulunan bir zafiyet değişikliği yeniden build, SAST ve SCA'dan geçirip yeni bir staging deploy'unu test etmeye zorlar; oysa aynı zafiyetli kalıp genellikle build kapısından hemen sonra SAST tarafından kaynak kodda doğrudan görülebilir ve çok daha ucuz ve erken yakalanır.
Ds Pipeline Security GatesZorluk 1
build -> SAST -> SCA -> DAST -> deploy şeklindeki bir pipeline kapı sırasında, DAST'ın SCA'dan SONRA yerleştirilmesinin temel nedeni nedir?
- aDAST her zaman SCA'dan daha fazla bulgu üretir, bu yüzden rapor boyutunu dengelemek için ikinci sırada çalışır
- bSCA internet erişimi gerektirir, DAST gerektirmez, bu yüzden sıralama ağ erişilebilirliğine dayanır
- cDüzenleyici standartlar her yerde bağımlılık taramasının dinamik taramadan önce gelmesini zorunlu kılar
- dDAST deploy edilmiş bir artefakta ihtiyaç duyar, bu yüzden önce SCA ile bağımlılıkları elemek mantıklıdır✓
Açıklama:DAST'ın çalışması için uygulamanın gerçekten çalışan bir örneğine ihtiyaç vardır, bu genellikle bir test ortamına paketlenip deploy edilmesi anlamına gelir. Bağımlılıkları önce SCA ile taramak daha verimlidir, çünkü kritik zafiyetli bir kütüphanenin bulunması, ekip bir DAST hedefi deploy etmek için zaman ve altyapı harcamadan build'i başarısız kılabilir.
Ds Pipeline Security GatesZorluk 2
Bağımsız kapıları mümkün olduğunda paralelleştirmek yerine her güvenlik kapısını kesinlikle sıralı (build -> SAST -> SCA -> DAST -> deploy) çalıştırmanın temel bir kısıtı nedir?
- aSıralı kapılar hesaplama maliyeti açısından her zaman paralel kapılardan daha ucuzdur
- bSAST ve SCA bağımsız olsa bile toplam geri bildirim süresi her kapının süresinin toplamıdır✓
- cSıralı çalıştırma her SAST ve SCA satıcısının lisans şartları tarafından zorunlu kılınır
- dParalel kapılar tek bir build artefaktını paylaşamaz, bu yüzden her biri ayrı bir derleme adımına ihtiyaç duyar
Açıklama:SAST ve SCA genellikle birbirinin sonucundan bağımsızdır (biri kaynak kodu, diğeri bağımlılık manifestosunu analiz eder), bu yüzden bunları build adımından sonra paralel çalıştırmak, güvenlik kapsamını zayıflatmadan toplam kapı süresini sıralı çalıştırmaya kıyasla kabaca yarıya indirebilir.
Ds Pipeline Security GatesZorluk 3
Bir pipeline şu anda build -> SAST -> SCA -> DAST -> deploy'u tamamen sıralı çalıştırıyor ve toplam 40 dakika sürüyor. Ekip, SAST ve SCA'nın birbirinden bağımsız olduğunu ve her birinin 8 dakika sürdüğünü, DAST'ın ise deploy edilmiş bir artefakta bağımlı olduğunu ve 20 dakika sürdüğünü fark ediyor. Hiçbir kapıyı zayıflatmadan geri bildirim süresini azaltmak için en mantıklı ilk değişiklik nedir?
- aSCA'yı tamamen kaldır, çünkü SAST zaten birinci taraf kaynak kodu kapsıyor
- bEn uzun kapı ilk bitsin diye DAST'ı SAST ve SCA'dan önce taşı
- cSAST ve SCA'yı build'den hemen sonra paralel çalıştır, DAST'ı ikisi bitince çalıştırmaya devam et✓
- dPull request'ler için build adımını atla, çünkü sadece main gerçek bir build'e ihtiyaç duyar
Açıklama:SAST ve SCA bağımsız olduğu için bunları paralel çalıştırmak, hiçbir kontrolü kaldırmadan ya da DAST'ı yeniden sıralamadan pipeline'dan kabaca 8 dakika kısaltır; DAST gerçekten deploy edilmiş bir artefakta ihtiyaç duyar ve bu tasarımda hâlâ kaynak/bağımlılık kapılarından sonra gelmelidir.