Sızma testi 40 açık buldu — boğulmadan bunları düzeltmeyi nasıl organize ederiz?

İbrahim T***12 ay önce·37 mesaj·22,3 B görüntülenme#sızma testi #açık yönetimi #yazılım güvenliği #risk değerlendirmesi

İbrahim T***KatılımcıTopluluk üyesi

Katılım: Ağu 2023
Mesaj: 279

12 ay önce#1

Austin merkezli B2B lojistik takip yazılımı sunan 12 kişilik bir girişimimiz var. Kurumsal bir müşterimizin güvenlik şartnamesi gereği bağımsız bir siber güvenlik şirketine ilk defa web uygulaması ve API sızma testi yaptırdık. Bu test için 6.500 dolar bütçe ayırmıştık ve süreç geçen cuma tamamlandı.

Gelen nihai raporda toplam 42 adet güvenlik açığı listelenmiş: 4 kritik 9 yüksek 18 orta ve 11 düşük seviye bulgu var. Rapor 80 sayfa ve her bulgu için CVSS skorları teorik senaryolar, istismar kanıtları eklenmiş. Ancak neyin hangi sırayla, kim tarafından ve ne kadar sürede kapatılması gerektiğine dair operasyonel hiçbi yönlendirme yok.

Yazılım ekibimiz 4 kişiden oluşuyor ve şu an devam eden ürün geliştirme sprintleri var. Bu 42 açığı mevcut iş akışını kitlemeden, ekibi tüketmeden ve kurumsal müşteriye geçerli bi düzeltme takvimi sunacak şekilde nasıl organize edebiliriz?

Kader K***KatılımcıTopluluk üyesi

Katılım: Nis 2024
Mesaj: 393

12 ay önceEn çok yardımcı olan#2

Kısa cevap: Kırk iki açığın hepsini aynı anda düzeltmeye çalışmak ekibi kilitler; bulguları teknik efor ve iş etkisi matrisine göre üçe ayırıp kritik ve yüksek seviyeleri ilk iki sprintte kapatacak kademeli bi açık giderme süreci kurgulamalısınız.

Süreci yönetmek için şu adımları uygulayın: 1) İlk 48 saatte filtreleme toplantısı: Raporu yazılımcılara olduğu gibi atmak yerine, ürün lideri ve kıdemli geliştirici 4 kritik ve 9 yüksek bulguyu tek tek incelesin. Kimlik doğrulama atlatma, SQL enjeksiyonu veya yetkisiz veri okuma gibi doğrudan müşteri verisine dokunan maddeleri acil iş olarak ayırın. 2) Düşük efor, yüksek kazanım ayrımı: Bazı yüksek ve orta açıklar tek satırlık bir kütüphane güncellemesi veya sunucu başlık ayarıyla 15 dakikada çözülür; bu kolay maddeleri hemen ilk sprinte serpiştirerek toplam bulgu sayısını hızla aşağı çekin. 3) Kalan orta ve düşük seviyeleri ürün yol haritasına yayın: Mimari değişiklik gerektiren orta seviye açıkları sonraki 60 güne, düşük ve bilgilendirme seviyesindeki bulguları ise 90 günlük rutin bakım periyotlarına paylaştırın.

Kurumsal müşterinize 80 sayfalık panik havası yerine bi İyileştirme Eylem Planı sunun. 'Kritikler 7 gün içinde, yüksekler 21 gün içinde kapatılacaktır; tekrar testi şu tarihte yapılacaktır' taahhüdü kurumsal denetçiler icin 40 açığın varlığından çok daha güven vericidir.

Fatih A***Veteran

Görev: Ürün yöneticisi
Sektör: Turizm
Yapı: orta ölçekli işletme
Katılım: Eki 2023
Mesaj: 15

12 ay önce#3

CVSS skorlarına körü körüne aldanmayın. Örneğin içeride kalan bi API ucundaki yüksek skorlu açık kimlik doğrulama arkasındaysa gerçek riski düşüktür. Buna karşılık genel internete açık bi parametredeki orta seviye bilgi sızıntısı sizi daha hızlı vurabilir. İstismar edilebilirlik bağlamını mutlaka hesaba katın.

Hasan E***KatılımcıTopluluk üyesi

Katılım: Ağu 2022
Mesaj: 333

12 ay önce#4

Geçen sene 38 bulgulu bir raporda benzer süreçten geçtik. Ekip ilk başta haftalarca yeni özellik yazamayacağını düşündü. İncelediğimizde 38 açığın 14 tanesinin sadece iki eski paket bağımlılığını güncellemekle kendiliğinden kapandığını gördük. Paket güncellemeleri iş yükünün üçte birini 3 saatte eritti.

Emre Y***UzmanTopluluk üyesi

Katılım: May 2025
Mesaj: 48

12 ay önce#5

Hemen test firmasına sözleşmedeki tekrar test (re-test) hakkınızın süresini sorun. Sözleşmelerde genellikle düzeltmeler için 30 veya 45 günlük ücretsiz doğrulama süresi bulunur. neyse o süre dolmadan kritik ve yüksekleri kapatıp onay raporunu alamazsanız firmaya ek ücret ödemek zorunda kalırsınız.

Orhan O***Katılımcı

Görev: Yönetim kurulu üyesi
Sektör: Su ürünleri
Yapı: orta ölçekli işletme
Katılım: Haz 2023
Mesaj: 17

11 ay önce#6

İş akışını korumak için sprint kapasite kuralı: 1) Önümüzdeki sprintin yüzde otuzunu yalnızca kritik açıklara ayırın. 2) Geri kalan yüzde yetmişlik kapasitede müşteri taahhütlü ana işlerinize devam edin. 3) Düşük öncelikli açıkları teknik borç havuzuna aktarıp sonraki döngülerde eritin.

Hakan U***UzmanTopluluk üyesi

Katılım: Eyl 2024
Mesaj: 86

11 ay önce#7

İlk sızma testimizde 50 sayfa rapor gelince yazılımcılarımız kişisel algılayıp defansa geçmişti, güvenlikçiler abartmış havası oluştu. Burada en kritik şey ekibin moralini korumak. Raporu yazılımcılara bir karne gibi değil dış gözün yakaladığı standart bir teknik borç listesi olarak sunmanız gerekiyor. Yoksa geliştiricilerle güvenlik ekibi arasında anlamsız bir sürtüşme başlıyor.

Aycan K***Katılımcı

Görev: Mağaza müdürü
Sektör: Catering
Yapı: 20 kişilik firma
Katılım: Mar 2024
Mesaj: 132

11 ay önce#8

O 11 düşük bulgunun en az 5 tanesi büyük ihtimalle TLS desteği, cookie bayrakları veya sunucu sürüm numarası gibi şablon maddelerdir. Bunlar saldırganın canını acıtmaz, bunlarla vakit kaybetmeyip doğrudan oturum yönetimi ve yetkilendirme açıklarına odaklanın.

Selim K***Katılımcı

Görev: Satış müdürü
Sektör: Medya ve yayıncılık
Yapı: 120 kişilik şirket
Katılım: Mar 2025
Mesaj: 305

Doki · SEO danışmanlığı · 2024

11 ay önce#9

Kurumsal müşteriniz düzeltme için size sözleşmeyle belirlenmiş resmi bi süre (SLA) verdi mi? Örneğin kritik açıklar için 14 gün yüksekler için 30 gün gibi bağlayıcı bi madde yoksa takvimi tamamen kendi geliştirme hızınıza göre esnetebilirsiniz.

Mustafa U***Katılımcı

Görev: Sosyal medya sorumlusu
Sektör: Gayrimenkul
Yapı: 8 kişilik ekip
Katılım: Ağu 2023
Mesaj: 65

11 ay önce#10

Özet plan belli: Kütüphane güncellemelerini hemen yapıp kalabalığı azaltın, kritik ve yüksekleri firmanın re-test penceresine sığdırın, müşteriye de net tarihler içeren tek sayfalık düzeltme takvimini iletin.