Kendi kodumuzda güvenlik açığı incelemesini denedik ama takıldık — yaygın tuzaklar neler?

Ebru K***7 ay önce·43 mesaj·13,6 B görüntülenme#güvenli kod inceleme #yazılım güvenliği #kod analizi #siber güvenlik

Görev: İnsan kaynakları uzmanı
Sektör: Mobilya üretimi
Yapı: tek kişilik işletme
Katılım: Eki 2024
Mesaj: 105

7 ay önce#1

Austinde 4 kişilik çekirdek bir yazılım ekibiyle B2B finansal veri analitiği platformu geliştiriyoruz. neyse kurumsal bir müşterimizin güvenlik denetimi talebi öncesinde, platformun veri tabanı sorguları ve kimlik doğrulama katmanlarını kapsayan yaklaşık 12.000 satırlık yeni kodu kendi içimizde güvenli kod incelemesinden geçirmek istedik. Dışarıdan güvenlik danışmanlığı almak icin şu an bütçemiz kısıtlı.

Üç hafta önce kolları sıvadık ancak tam bir operasyonel çıkmaza girdik. Açık kaynaklı bir statik analiz aracı çalıştırdığımızda karşımıza 320'den fazla uyarı çıktı. işte ekip bu uyarıların hangisinin sahte pozitif, hangisinin gerçek tehdit olduğunu tartışırken sprint hızımız neredeyse yarı yarıya düştü. Yazılımcılar savunmaya geçti süreç çok yavaşladı ve asıl korktuğumuz iş mantığı açıklarını yine de kaçırdığımız hissiyatı oluştu.

Küçük yazılım ekiplerinin kendi kodunu güvenlik odaklı incelerken düştüğü en yaygın tuzaklar nelerdir? Bu süreci ekibi tüketmeden ve teslimat takvimini felç etmeden nasıl yönetilebilir bir rutine dönüştürebiliriz?

Hakan U***KatılımcıTopluluk üyesi

Katılım: Nis 2024
Mesaj: 43

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

Kısa cevap: En yaygın tuzak otomatik araçların ürettiği yüzlerce uyarıyı önceliklendirmeden tek seferde çözmeye çalışmak ve tüm koda aynı güvenlik hassasiyetiyle yaklaşmaktır. neyse güvenli kod incelemesi ancak tehdit modellemesi yapılarak riskli alanlar daraltıldığında ve statik analiz kuralları filtrelendiğinde sürdürülebilir olur.

İlk adımda statik analiz aracınızın gürültüsünü kesin. 320 uyarının çıkması çok normaldir; bunların önemli bir bölümü katı kodlama standartları veya düşük riskli stil uyarılarıdır. Aracınızın kural kümesini yalnızca kritik ve yüksek seviyedeki zafiyetlere (SQL enjeksiyonu, yetkisiz veri erişimi, güvensiz oturum yönetimi ve şifreleme hataları) odaklanacak şekilde daraltın. Bilgi amaçlı ve orta seviye uyarıları ilk etapta devre dışı bırakarak incelenecek bulgu sayısını yönetilebilir bir seviyeye indirin.

İkinci adımda inceleme kapsamını 12.000 satırdan kritik yüzeylere çekin. açıkçası veri tabanına doğrudan yazan fonksiyonlar kullanıcı girdisini işleyen uç noktalar ve yetkilendirme kontrolleri dışındaki yardımcı sınıfları tam güvenlik incelemesine sokmak ekibi yorar. 12.000 satır yerine belki sadece 1.500 satırlık kritik temas noktasını masaya yatırmalısınız.

Son olarak statik tarayıcıların mantıksal yetkilendirme açıklarını (örneğin kullanıcının parametre değiştirerek başka şirketin faturasını görmesi gibi) asla tespit edemeyeceğini unutmayın. valla bu tür iş mantığı açıklarını bulmak için ekip içi çapraz senaryo testleri yapın: bi geliştirici diğerinin yazdığı uç noktada 'rol kontrolü eksik olursa ne olur' sorusunu manuel olarak sormalıdır.

Feyza S***KatılımcıTopluluk üyesi

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

6 ay önce#3

Statik analiz araçlarında 'taint analysis' yani kirli veri takibi özelliğini iyi yapılandırın. Kullanıcıdan gelen parametrenin veritabanına ya da sistem komutuna gidene kadar sterilize edilip edilmediğini takip edin. Her dize birleştirmesini SQL açığı sayan kuralları kapatırsanız uyarılardan en az üçte ikisi anında temizlenir.

Nuri E***Uzman

Görev: Genel koordinatör
Sektör: Deri
Yapı: bölge bayisi
Katılım: Şub 2023
Mesaj: 386

6 ay önce#4

Güvenlik eğitimi almamış yazılımcıya kendi kodunu güvenlik açısından inceletmek sadece formalitedir. Kodu yazan kişi kendi tasarım hatasını göremez. Bütçeniz darsa tüm sisteme değil, sadece kimlik doğrulama ve ödeme modülüne özel 2-3 günlük odaklı bir dış denetim aldırmak çok daha ucuz ve etkilidir.

Ercan T***Katılımcı

Görev: Teknoloji direktörü
Sektör: Elektrik-elektronik
Yapı: bölge bayisi
Katılım: Oca 2023
Mesaj: 1

Doki · Güvenlik açığı taraması · 2024

6 ay önce#5

12.000 satırı tek seferde inceleme hatasına bir daha düşmeyin. Güvenlik incelemesini çekme isteklerine bölün. Her birleştirmede 300 satırdan fazla kod olmasın ve kontrol listesinde sadece 5 kritik güvenlik maddesi bulunsun. Sprint biterken deil, kod yazılırken baksınlar.

Orhan D***Uzman

Görev: Mağaza görevlisi
Sektör: Bilişim hizmetleri
Yapı: yeni kurulmuş girişim
Katılım: Kas 2024
Mesaj: 228

6 ay önce#6

Biz ilk taramada 410 uyarı almıştık. İki hafta boyunca ekipçe debelendik. Sonra güvenlik filtresini sadece en kritik 10 web açığına göre yapılandırdık; sayı bir anda 19'a düştü. O 19 bulgunun da gerçekten düzeltilmesi gereken sadece 4 tanesi gerçek risk taşıyordu.

Ahmet Z***Uzman

Görev: Teknik servis elemanı
Sektör: Gıda toptancılığı
Yapı: aile şirketi
Katılım: Ara 2023
Mesaj: 159

6 ay önce#7

otomasyon araçları kodun ne iş yaptığını bilmez sadece şablon eşler sonra veritabanı sorgularınızda parametreli kütüphaneler kullanıyorsanız zaten sql injection riskinin çoğunu otomatik bertaraf edersiniz bşouna aracın her uyarısına takılmayın.

Sinan B***Yeni üye

Görev: Üretim planlama
Sektör: Reklam ve tanıtım
Yapı: orta ölçekli işletme
Katılım: Eyl 2026
Mesaj: 59

6 ay önce#8

İlk ürünümüzde ekiple günlerce karmaşık regex doğrulama kurallarını tartıştık, güvenli kod incelemesi yaptık diye sevindik. Canlıya çıktığımızın üçüncü günü bir müşteri url parametresindeki id değerini değiştirip başka firmanın finansal tablosunu çekti. Araçların göremediği tam olarak bu mantık hatalarıydı.

Hande B***Katılımcı

Görev: Operasyon müdürü
Sektör: Spor ve fitness
Yapı: butik ajans
Katılım: Haz 2023
Mesaj: 353

6 ay önce#9

Düştüğünüz üç klasik tuzak var: 1) Araç çıktısını mutlak doğru kabul edip sahte uyarılara saatler harcamak, 2) Güvenlik incelemesini geliştiricinin performans değerlendirmesi gibi algılatıp savunma refleksi yaratmak, 3) Kod stili ile güvenlik açığını birbirine karıştırmak.

Filiz A***UzmanTopluluk üyesi

Katılım: May 2025
Mesaj: 14

6 ay önce#10

Konuşulanların özeti şu: Otomatik tarayıcıların uyarı eşiğini yükseltip gürültüyü azaltın, incelemeyi küçük parçalara bölün ve araçların yakalayamayacağı yetkilendirme mantığı hatalarını manuel senaryolarla test edin.