Kendi ekibimizle yayından önce kodu güvenlik açısından incelemeye nasıl başlarız?

Otomasyon tarafında statik analiz kadar bağımlılık taraması da kritik. Kullandığınız harici kütüphanelerdeki bilinen güvenlik açıklarını derleme anında kontrol eden açık kaynak bağımlılık denetleyicileri kurun. Ayrıca yetkilendirme açıklarını engellemek için kod tarafında iş mantığını denetleyen birim ve entegrasyon testlerini zorunlu kılın; kullanıcı kimliği ile veri nesnesi eşleşmesi test edilmeden kod geçmemeli.

Dört kişilik bir ekipte güvenlik kontrolünü tek bir kişinin sırtına yüklerseniz o kişi kısa sürede darboğaz olur. İncelemeyi bir ceza veya onay mekanizması değil, ortak sorumluluk haline getirin. Her çekme isteğinde iki göz kuralı uygulayın; kodu yazan değil, inceleyen kişi güvenlik maddelerini tek tek işaretlesin. Basit bir kontrol listesi bile hataların çoğunu daha geliştirme ortamındayken yakalar.

ek: aşağıda sorulmuş, cevabı ikinci mesajda yazdım.

Hemen yarın sabah başlayabileceğiniz en pratik adım çekme isteği şablonunuza güvenlik başlığı açmaktır. Geliştirici kodu göndermeden önce 'Kullanıcı girdisini doğruladım' ve 'Yetki kontrolü ekledim' kutucuklarını işaretlemek zorunda kalsın... Bu iki soru bile yazılımcıyı kodu göndermeden önce durup düşünmeye zorlar.

bizim ekipte de benzer sey oldu haariici kutuphaneler yuzunden patlamistik... ucretsiz acik kaynak tarama araclarini depoya bagladik acik bulunca birlestirmeyi engelliyor. iste ilk bassta herkes sikayet etti ama iki haftada alistik kafamiz cok rahatladi.

Geçen yıl benzer bi süreçten geçtik. Otomatik statik analizi ve çekme isteği kontrol listesini oturttuktan sonra, altı ay sonraki bağımsız güvenlik testinde tespit edilen kritik bulgu sayısı sıfıra indi. İnceleme sürelerimiz çekme isteği başına ortalama sadece 12 dakika uzadı. Harcadığımız bu 12 dakika bizi binlerce dolarlık acil yama maliyetinden kurtardı.

Müşterinizin yaptırdığı sızma testi raporunda çıkan yetkilendirme atlaması tam olarak API katmanında mı yoksa veritabanı sorgusu düzeyinde mi gerçekleşmiş? Eğer API uç noktalarında merkezi bir yetki katmanı yoksa, her fonksiyon içine tek tek kontrol yazmak ileride yine açık üretir. Mimarinizde merkezi bir kimlik ve erişim kontrolü var mı?

Otomatik tarayıcılara çok fazla güvenmeyin. Statik analiz araçları kütüphane açıklarını veya basit SQL açıklarını iyi yakalar ama sizin yaşadığınız yetkilendirme atlaması gibi iş mantığı hatalarını asla göremez. Biri 'A kullanıcısı B nin faturasını görebiliyor mu' testini koda bakarak mantıksal olarak yapmadığı sürece hiç bir otomatik yazılım sizi o rapordan kurtaramaz.

Toparlarsak yol haritası net: 1) Ücretsiz otomatik araçları depoya entegre edip bağımlılıkları ve temel açıkları taratın, 2) Çekme isteklerine yetkilendirme ve veri doğrulama odaklı 5 maddelik inceleme şartı koyun, 3) İş mantığı kontrollerini geliştiricilerin manuel incelemesine emanet edin. Büyük bütçelere gerek yok, disiplin yeterli.

Aynısını yaşadım.

Bir dönem biz de aynı yerde takıldık. Karar verirken en kötü senaryoyu da yazın, sadece iyisini değl.

Başka türlü yapan varsa onu da merak ederim.

çok teşekkurler buügn deneyeceğim.

Kaydettim.

Sonuna kadar katılıyorum. Envanter çıkarmadan alınan önlem, görmediğiniz kapıyı açık bırakıyor.

Bizde en çok zaman kaybettiren şey kimin karar vereceğinin belli olmamasıydı.

Aynı hatayı yapmayın diye yazıyorum. Test edilmemiş bi yedek yedek değildir.

Bir sorunu fark etme süreniz o sorunun maliyetini doğrudan belirliyor. Başka türlü yapan varsa onu da merak ederim.

Bunu yaparken çok düşülen bir hata var. Zaman kaybının çoğu, onay bekleyen işlerde birikiyor.

Benim görüşüm bu, kesin doğru diye yazmıyorum.

Küçük bir işletmeyim, benim tarafımdan anlatayım. Herkesin yaptığı şey, doğru olduğu anlamına gelmiyor.

Sormaktan çekinmeyin, sormayan hep daha pahalıya ödüyor.

kafamdaki soru işaerti kalkı teşekkurler

Anlamadığım bi yer var. İlk kez yapıyorsanız küçük başlayın ölçek sonra gelir.

Test edilmemiş bir yedek, yedek değildir... Ben olsam bu yoldan giderdim.