Yazılım geliştiren şirket ISO 27001’de güvenli kodlamayı nasıl sağlar?
ISO 27001:2022 Ek A.8.25–8.28 kontrolleri, güvenliğin geliştirme yaşam döngüsünün her aşamasına gömülmesini ister. Uygulamada bu; yazılı bir güvenli geliştirme politikası, geliştirme-test-canlı ortam ayrımı, zorunlu kod gözden geçirme, güvenli kodlama standardı ve değişikliklerin kayıtlı onayla canlıya alınması demektir.
Bir yazılım firmasının ISO 27001 denetiminde en hızlı uygunsuzluk çıkan yer sunucu odası değil, sürüm yönetimi ekranıdır. Ek A’nın 2022 revizyonu geliştirme kontrollerini dört ardışık maddeye yaydı ve bunları birbirine bağladı: politika (8.25), değişiklik yönetimi (8.32 ile birlikte 8.25), ortam ayrımı (8.31), dış kaynaklı geliştirme (8.30) ve güvenli kodlama (8.28). Bunları tek tek belge üretmek yerine mevcut geliştirme akışına yerleştirmek gerekir.
A.8.25 kapsamındaki politika, “güvenli yazılım yaparız” temennisi değil, karar kuralları listesidir. En az şunları içermelidir: hangi dillerde hangi kodlama standardının uygulandığı, güvenlik gereksinimlerinin ne zaman tanımlandığı, kimin onaylamadan merge yapamayacağı, hangi test türlerinin zorunlu olduğu ve üçüncü parti kütüphanelerin nasıl seçildiği.
Politikayı yazarken en işlevsel yöntem, mevcut pull request şablonunuzu açıp oradaki adımları metne dökmektir. Böylece politika ekibin gerçekten yaptığı işi tarif eder; denetimde de “biz böyle çalışıyoruz” demek yerine ekranda gösterilir.
A.8.31 ayrımı, üç ortamın farklı erişim yetkileriyle ve farklı verilerle çalışmasını ister. Kanıt olarak ortam envanteri, her ortama erişimi olan kişilerin listesi ve canlı verinin test ortamında kullanılmadığını gösteren maskeleme/anonimleştirme kaydı sunulur. Aynı kişi hem geliştirip hem canlıya alıyorsa telafi edici kontrol gerekir.
A.8.28 için beklenen kayıtlar dört başlıkta toplanır: kabul edilen güvenli kodlama standardı (OWASP ASVS, CERT vb. referanslı), statik kod analizi (SAST) çıktıları, bağımlılık taraması sonuçları ve bulunan zafiyetlerin kapatılma kayıtları. Tarama yapmak yeterli değildir; kritik bulguların ne kadar sürede kapatıldığı ölçülmelidir.
Mini karar kuralı: Bir tarama aracının çıktısını gösterip “bunlar false positive” diyorsanız, bu değerlendirmenin de kaydı olmalıdır. Değerlendirilmemiş bulgu, kapatılmamış bulgu sayılır.
A.8.30, geliştirmeyi dışarıya verseniz de bilgi güvenliği sorumluluğunun sizde kaldığını söyler. Sözleşmede güvenli kodlama şartları, kaynak koda erişim hakkı, güvenlik testi yaptırma yetkisi, zafiyet bildirim süresi ve fikri mülkiyet maddeleri bulunmalıdır. Tedarikçinin kendi sürecini izlediğinize dair periyodik bir kanıt da beklenir.
Uygulamada en pratik yöntem, yıllık tedarikçi değerlendirmesine iki soru eklemektir: son 12 ayda kaç güvenlik bulgusu bildirildi ve ortalama kapatma süresi neydi? Bu iki veri, sayfalarca taahhüt metninden daha güçlü bir kanıttır.
Uygulanabilirlik Bildirgesinde her kontrol için uygulanıyor/uygulanmıyor kararı, gerekçesi ve uygulama referansı yer alır. Yazılım geliştirmeyen bir şirket 8.25–8.31 grubunu hariç tutabilir; ancak kendi iç otomasyonlarını, makrolarını veya düşük kodlu uygulamalarını geliştiriyorsa bu hariç tutma denetimde sorgulanır.
Hariç tutma gerekçesi “yazılım geliştirmiyoruz” ise, bunun bir doğrulaması olmalıdır: BT envanterinde şirket içi geliştirilmiş uygulama bulunmaması gibi. Aksi hâlde SoA ile varlık envanteri çelişir.
Durumunuzu birkaç dakikada konuşalım; size özel süre ve yol haritası çıkaralım.
Standart sızma testini isimle zorunlu kılmaz; ancak A.8.29 güvenlik testini ve A.8.8 teknik zafiyet yönetimini ister. İnternete açık uygulama yayınlayan kuruluşlarda düzenli sızma testi, bu kontrollerin karşılanmasının en yaygın kabul gören yoludur.
Hayır. Beklenen şey kullanılan bileşenlerin envanterinin (SBOM benzeri bir liste) tutulması, lisans uygunluğunun kontrol edilmesi ve bilinen zafiyetler için düzenli tarama yapılmasıdır. Kontrolsüz kullanım sorun yaratır, kullanımın kendisi değil.
Kontroller sprint akışına gömülür: güvenlik gereksinimleri kabul kriterine, kod gözden geçirme merge kuralına, taramalar CI hattına eklenir. Ayrı bir “güvenlik aşaması” kurmak yerine mevcut tanım-of-done listesini genişletmek hem sürdürülebilir hem denetlenebilir olur.
Üretilen kodun da aynı gözden geçirme, tarama ve onay sürecinden geçmesi gerekir. Ek olarak, koda gizli bilgi veya müşteri verisi girilmemesi için araç kullanım kuralları yazılı hâle getirilmelidir. Bu konu son dönem denetimlerinde giderek daha sık soruluyor.
Maliyet, ekip büyüklüğüne, mevcut araç setine ve geliştirme hattının olgunluğuna göre değişir. Var olan repo ve CI altyapısını kullanan ekiplerde ek yük birkaç birimle sınırlı kalırken, sürüm yönetimi olmayan yapılarda kurulum daha kapsamlıdır. Sizin için en ideal çözüm, danışmanlarımızla doğrudan görüşmenizdir.