Bir CodeAuditAgent Raporu Nasıl Okunur ve Nasıl Harekete Geçilir

Bir güvenlik raporu ancak birleştirilen düzeltmelere dönüşürse işe yarar. CodeAuditAgent raporları tam da bunun etrafında tasarlanmıştır: her bulgu hızla doğrulanacak kadar belirgindir ve uyarlayabileceğiniz bir yamayla gelir. Bu rehber, bir raporun her bölümünü, ayrılmış bir güvenlik mühendisiniz yokken raporu nasıl triyaj edeceğinizi ve düzeltmelerinizin işe yaradığını nasıl doğrulayacağınızı anlatıyor.

Neler denetlenir

Bir denetim, ya herkese açık bir GitHub deposu ya da yapıştırdığınız bir kod parçası üzerinde çalışır. Depolar için CodeAuditAgent varsayılan dalı okur. Özel depolar URL ile denetlenemez ve henüz pull request yorumları yoktur; sonuçlar panelde ve dışa aktarımlarda yer alır.

Bir deponun ne kadarının okunacağı planınıza bağlıdır. Ücretsiz plan 1 depoyu, ayda 3 denetimi ve denetim başına en fazla 20 dosyayı kapsar. Ayda 49 dolarlık Starter planı 5 depoyu, 50 denetimi ve denetim başına 40 dosyayı kapsar. Ayda 199 dolarlık Pro planı sınırsız depoyu, 500 denetimi ve denetim başına 80 dosyayı kapsar. 60 KB'tan büyük dosyalar atlanır. Aylık denetim sayaçları her takvim ayının başında (UTC) sıfırlanır. Yapıştırılan bir kod parçası, tüm depoyu denetlemeden önce endişelendiğiniz tek bir dosyayı hızlıca kontrol etmenin de iyi bir yoludur.

Bu limitler nedeniyle dosyalar dışarıda kaldığında rapor kısmi anlık görüntü olarak etiketlenir. Bu etiketi ciddiye alın. Temiz görünen kısmi bir rapor, okunan dosyaların temiz göründüğü anlamına gelir; deponun temiz olduğu anlamına gelmez. En çok önemsediğiniz kod atlandıysa onu yapıştırılmış bir kod parçası olarak ya da daha fazla dosya kapsayan bir planda denetleyin.

Risk skoru

Her raporun başında 0 ile 100 arasında bir risk skoru bulunur; Markdown dışa aktarımı yanında genel önem derecesini de belirtir. Skorun yüksek olması daha fazla risk demektir. Bu skor, o denetimdeki bulguların bir özetidir ve iki şey için faydalıdır: bir depoya ne kadar acil bakılacağına karar vermek ve deponun zaman içinde iyileşip iyileşmediğini izlemek.

Birbiriyle ilgisiz depolar arasındaki küçük farklara fazla anlam yüklemeyin. Bir skor her zaman neyin denetlendiğine görelidir ve kısmi bir anlık görüntü daha az kod görür. Sayının en anlamlı olduğu yer, aynı deponun düzeltmelerden önceki ve sonraki hâlini karşılaştırmaktır.

Önem derecesi ve güven seviyesi

Her bulgunun bir önem derecesi ve bir güven seviyesi vardır. Bunlar farklı soruları yanıtlar: önem derecesi, bulgu gerçekse durumun ne kadar kötü olacağını; güven seviyesi ise inceleyicinin bulgunun gerçek olduğundan ne kadar emin olduğunu gösterir.

• Kritik: doğrudan istismar edilebilen ve ciddi etkisi olan sorunlar; herkese açık bir endpoint'te enjeksiyon, kimlik doğrulama atlatma veya açığa çıkmış üretim kimlik bilgileri gibi.
• Yüksek: bir ön koşul gerektiren ya da önemli ama sınırlı etkisi olan gerçek bir güvenlik açığı.
• Orta: başka hatalarla birleştiğinde önem kazanan ya da orta düzeyde etkisi olan bir zayıflık.
• Düşük: sağlamlaştırma sorunları ve derinlemesine savunma boşlukları.
• Bilgi: tek başına güvenlik açığı olmayan ama bilinmesinde fayda olan gözlemler.

Güven seviyesi yüksek, orta veya düşüktür. Yüksek güvenli bir bulgunun, okunan kodda net bir kanıtı vardır. Düşük güvenli bir bulgu ise genellikle denetimin göremediği bir şeye bağlıdır: başka bir dosyadaki ara katman, bir veritabanı politikası ya da dağıtım sırasında verilen bir yapılandırma değeri. Düşük güven, yok sayın demek değildir; düzeltmeden önce bir insanın eksik bağlamı kontrol etmesi gerektiği anlamına gelir.

Bir bulgunun anatomisi

Her bulgu aynı yapıyı izler; böylece onu tutarlı bir sırayla doğrulayabilirsiniz.

• Başlık ve CWE: zayıflığın sınıfı; örneğin kullanıcı kontrolündeki bir anahtar üzerinden yetkilendirme atlatma için CWE-639. CWE, nasıl bir düzeltme bekleyeceğinizi söyler.
• Konum: dosya ve satır; böylece kodu doğrudan açabilirsiniz.
• Kanıt: dosyadan alıntılanan ilgili kod. Alıntının mevcut kodunuzla eşleştiğini kontrol edin; satır çoktan değiştiyse bulgu bayatlamış olabilir.
• İstismar senaryosu: bir saldırganın zayıflığı adım adım nasıl kullanacağı. Bulgunun sizin bağlamınızda gerçek olup olmadığına karar vermenin en hızlı yolu budur.
• Düzeltme yaması: çevresindeki kodun tarzına uygun, önerilen bir değişiklik.

Yamayı, birleştirmeye hazır bir commit olarak değil, güçlü bir başlangıç noktası olarak görün. Yama, denetimin okuduğu koddan yazılır; bu yüzden yardımcı fonksiyonlarınızı, ORM alışkanlıklarınızı ya da kod tabanının başka bir yerindeki bir çağrıyı bilmiyor olabilir. Tipik bir yama küçük ve hedeflidir:

--- a/app/api/invoices/[id]/route.ts
+++ b/app/api/invoices/[id]/route.ts
@@
-  const invoice = await db.invoice.findUnique({ where: { id } });
+  const invoice = await db.invoice.findFirst({
+    where: { id, userId: session.user.id },
+  });
   if (!invoice) return Response.json({ error: 'not_found' }, { status: 404 });

Olumlu gözlemler ve sonraki adımlar

Raporlar iyi yapılanları da listeler: tutarlı biçimde kullanılan parametreli sorgular, ortamdan yüklenen gizli anahtarlar, katı bir çerez yapılandırması. Bunları okumaya değer. Hangi kalıpları koruyup yeni koda taşıyacağınızı gösterirler ve bir kod tabanının durumunu başka birine anlatırken işinize yararlar.

Önerilen sonraki adımlar bölümü, bulguları sıralı bir plana dönüştürür. Çoğu zaman ilişkili bulguları gruplar; örneğin beş ayrı yama yerine tek bir ortak yardımcı fonksiyonla düzeltilmesi daha iyi olan birkaç eksik sahiplik kontrolünü bir araya getirir.

Küçük ekipler için bir triyaj akışı

Güvenlik mühendisi olmadığında risk, raporu görmezden gelmek değildir; kritik bir bulgu beklerken düşük bulgulara bir gün harcamaktır. Basit bir sıra iyi sonuç verir:

• Önce her kritik ve yüksek bulguyu okuyun. Her biri için istismar senaryosunu okuyun ve karar verin: gerçek, gerçek değil ya da bağlam gerekiyor.
• Gerçek kritik bulguları aynı gün düzeltin. Düzeltme zaman alacaksa endpoint'i devre dışı bırakmak veya bir kontrolü sıkılaştırmak gibi geçici bir önlem alın.
• Bağlam gerektiren bulgular için eksik parçayı kontrol edin: bunu zaten engelleyen bir ara katman, bir satır düzeyi politika veya bir yapılandırma var mı? Yanıtı yazın.
• Yüksek bulguları mevcut sprint'e, orta olanları backlog'a alın; düşük ve bilgi düzeyindekileri bir sağlamlaştırma turunda toplayın.
• Bir bulgu gerçek değilse nedenini kaydedin. Bu not, bir sonraki kişiyi aynı incelemeyi baştan yapmaktan kurtarır.

Her bulguyu tek bir sahibe atayın. Tüm ekibe ait olan bulgular genellikle kimseye ait olmaz.

Bulgu gezgini ve dışa aktarımlar

Elinizde birkaç denetim biriktiğinde, tek tek raporlar yerine bulgu gezgininden çalışmak daha kolaydır. Gezgin, denetimler arasındaki bulguları listeler ve bunları önem derecesi, CWE ve depoya göre filtreler. CWE'ye göre filtrelemek özellikle işe yarar: aynı zayıflık üç depoda birden görünüyorsa bu genellikle ortak bir kalıba ya da eksik bir yardımcı fonksiyona işaret eder ve kalıbı düzeltmek her örneği tek tek düzeltmekten ucuzdur.

Bulgular gezginden CSV olarak dışa aktarılabilir; bu da bir iş takip aracına veya elektronik tabloya aktarmak için kullanışlıdır. Tek tek raporlar Markdown olarak dışa aktarılabilir; bu biçim bir pull request açıklamasında, dahili bir wiki sayfasında veya düzeltmeyi yapacak bir yükleniciye gönderilecek bir mesajda iyi okunur.

Düzeltmeyi doğrulamak için yeniden denetleyin

Bir düzeltme, siz kontrol edene kadar tamamlanmış sayılmaz. Birleştirmeden sonra aynı depoda yeni bir denetim çalıştırın. Her rapor bir önceki denetimle karşılaştırılabilir; böylece hangi bulguların kaybolduğunu, hangilerinin kaldığını ve yeni bir şey çıkıp çıkmadığını görürsünüz. Gerçek sorunlar düzeltildiğinde risk skoru düşmelidir; düşmüyorsa nedenini görmek için karşılaştırmaya bakın.

Karşılaştırmayı adil tutun. İlk denetim kısmi bir anlık görüntüyse ve ikincisi farklı dosyaları okuduysa, fark yalnızca düzeltmeleri değil kapsamı da yansıtır. Denetimler aylık kotanızdan düşer; bu yüzden her commit'ten sonra yeniden çalıştırmak yerine birkaç düzeltmeyi biriktirip sonra yeniden denetlemek genellikle daha mantıklıdır.

Bir raporun kapsamadıkları

Sınırları bilmek boşlukları doldurmanıza yardımcı olur. Denetimler kaynak kodunuzu okur; bağımlılıkları bilinen açıklı sürümler için taramaz, bu yüzden paket yöneticinizde yerleşik olan ya da GitHub'ın sunduğu gibi bir bağımlılık tarayıcısını da çalışır durumda tutun. Denetimler dağıtım zamanındaki yapılandırmayı, deponun dışındaki altyapıyı veya atlanan dosyaları görmez. Ayrıca ister insan ister yapay zekâ olsun her inceleyici gibi denetim de yanılabilir: kanıt ve güven seviyeleri tam da bu yüzden vardır, böylece bulguyu körü körüne kabul etmek yerine hızlıca kontrol edebilirsiniz.

Bu şekilde kullanıldığında bir rapor, kanıtı ekli, kısa ve önceliklendirilmiş bir değişiklik listesine dönüşür. Kritik olanları düzeltin, belirsiz olanları kontrol edin, yeniden denetleyin ve skorun hareket etmesini izleyin.