Düzenlemeye tabi bir kuruluşta yazılım nasıl geliştirilir?

Daha fazla kişinin fikirlerini yazılıma dönüştürmesine yardımcı olun

CTO, kuruluş genelindeki insanları yapay zekâyla prototip geliştirmeye davet edebilir. Finans ekipleri onay sorunlarını bilir. Operasyon ekipleri tekrar eden manuel görevlerini bilir. Daha iyi iş akışını gösterebilmeleri için zaman ve araç verin.

Kurulum, hesaplar ve izin verilen girdiler için açık kurallar içinde farklı keşif araçlarına izin verin. Sentetik veri kümeleri, sandbox API’leri ve pratik yardım sağlayın. İnsanların üretim sistemlerini bağlamadan değer gösterebileceği açık yol olmalıdır.

Ardından sonraki kararı tanımlayın: uygulama gizli bilgi, gerçek API izni veya üretim trafiği almadan önce neler doğrulanmalıdır? Prototipi geliştiren kişi için bu yolu anlaşılır kılın.

Prototip gerçek erişime ihtiyaç duyduğunda ne değişir?

Çalışan özellik, hizmetin bir parçasıdır. Kuruluş ayrıca onu kimin kullanabildiğini, veriyi nasıl işlediğini ve nasıl kurtarıldığını açıklamalıdır. Bu sorumluluklar yayından sonra sürer.

Uygulanabilir gereksinimler; hizmete, sektöre, yetki alanına, sözleşmelere ve verilere bağlıdır. Sorumlu hukuk, gizlilik ve güvenlik uzmanlarından bunları belirlemelerini isteyin. Geliştirme çerçevesi veya tedarikçi sertifikası, sizin hizmetiniz için uyumu kanıtlamaz.

Aşağıdaki adımlar mühendislik iş akışı sağlar. Gereksinimleri kararlara ve kanıta bağlamak için kullanın. NIST SSDF, mevcut SDLC’yi destekleyebilen güvenli geliştirme uygulamaları sunar. Uygulanabilir yükümlülükleri belirlemenin yerine geçmez.

1. Yararlı prototipi hizmet tanımına dönüştürün

Geliştiren kişiden sorunu açıklamasını, iş akışını göstermesini ve kullanıcıların öğrendiklerini kaydetmesini isteyin. Geliştiren kişiyi alan uzmanı olarak sürece dahil tutun. Teknik değerlendirmeyi ve sürekli işletimi bu sorumluluklara sahip ekiplere atayın.

Kullanıcı görevini, amaçlanan sonucu ve hatanın sonuçlarını yazın. Ürün sorumlusunu, hizmet sorumlusunu, güvenlik irtibat kişisini ve artık riski kabul edebilen kişiyi belirtin. Yayını kimin durdurabileceği konusunda anlaşın.

Örneğin, müşteri verisi dışa aktarımı indirme düğmesinden fazlasını gerektirir. Kimin hangi kayıtları, hangi amaçla ve hangi saklama süresiyle dışa aktarabileceğini tanımlayın. Yetkisiz dışa aktarmayı kimin araştıracağını belirleyin. Bu kurgusal örnektir.

Saklanacak kanıt: hizmet tanımı, sorumluluk haritası ve onaylı kabul ölçütleri.

Gereksinimler ve izlenebilirlik ile hizmet sorumluluğu dersleriyle devam edin.

2. Veri veya API erişimi vermeden önce sınırı doğrulayın

Gizli bilgiyi, kişisel veriyi, erişim bilgilerini ve diğer kısıtlı içeriği belirleyin. İstemlerin, alınan bağlamın, günlüklerin ve üretilen çıktıların nereye gittiğini haritalayın. Seçilen hizmetin saklama, eğitim, erişim ve bölgesel işleme koşullarını kontrol edin.

Fikir keşfederken sentetik veya onaylı test verisi kullanın. Başarılı prototip, sağlayıcısının üretim verisini işleyebileceğini kanıtlamaz. Her sağlayıcıyı ve dağıtım yapılandırmasını kontrol edin.

Salı günü geliştirilen kurgusal banka paneli, uydurma işlemlerle iyi çalışabilir. Salt okunur hesap erişimi bile gizli kayıtları açığa çıkarabilir. Ödeme izinleri finansal sonuçlar ekleyebilir. Bağlantıyı etkinleştirmeden önce gerçek kapsamı, erişim bilgisi işlemeyi, yetkilendirmeyi ve hata davranışını doğrulayın. Bankacılık prototipi örneğini adım adım inceleyin.

Bu inceleme, ilk hassas girdiden veya gerçek bağlantıdan önce yapılmalıdır. Uygulamaya prototip demek, zaten sahip olduğu izinleri azaltmaz.

Ajanlara yalnızca görev için gereken araçları ve izinleri verin. Kod deposu dosyalarını ve alınan belgeleri güvenilmeyen girdi sayın. Gizli bilgileri istemlerin dışında tutun.

Saklanacak kanıt: veri akışı diyagramı, sağlayıcı değerlendirmesi ve izin politikası.

Veri sınırlarını ve ajan izinlerini okuyun.

3. Üretime desteklenen bir yol sağlayın

Hizmeti, kuruluşun kimlik, ağ, günlükleme ve dağıtım kontrolleri içine yerleştirin. Desteklenen ortamları ve kod olarak altyapıyı tanımlayın. Konteyner ve veri tabanı, işletim ortamının tamamını oluşturmaz.

Politika kendi altyapınızı gerektiriyorsa bulut hesaplarınıza veya ağlarınıza dağıtımı doğrulayın. Çalışma zamanı kontrollerini, geliştirme ve model veri akışlarından ayrı kontrol edin. Hesabınızda barındırmak uyumu kanıtlamaz veya her yapay zekâ isteğini o hesap içinde tutmaz.

Desteklenen yol; kurum içi platform, yazılım fabrikası veya her ikisini kullanabilir. Doğrulama, dağıtım, güvenlik açığı düzeltmeleri ve işletim için her birinin ne sağladığını tanımlayın. Prototip, bu yolu kullanabilmek için değişikliklere veya yeni yazılmış koda ihtiyaç duyabilir.

Kabul edilebilir kesinti süresi ve veri kaybı üzerinde anlaşın: RTO ve RPO. Kullanılabilirlik ve kurtarma mekanizmalarını bu hedeflere göre seçin. Multi-AZ, çok bölgeli yapı ve yedekler farklı arıza senaryolarını çözer. Bağımlılıklar ve geri yüklenen veriler dahil, kurtarma sürecinin tamamını test edin.

Saklanacak kanıt: mimari karar kaydı, ortam tanımları ve ölçülmüş kurtarma sonuçları.

Kurumsal altyapıyı ve RTO ile RPO’yu inceleyin. Ardından kurtarma alıştırmasını kullanın.

4. Doğrulanabilir gereksinimlerle küçük değişiklikler geliştirin

Geliştiriciye veya ajana açık görev ve kabul ölçütleri verin. Gereksinimi uygulamasına, testlerine ve incelemesine bağlayın. Değişiklikleri incelenebilecek kadar küçük tutun.

Testten önce güvenlik gereksinimlerini tanımlayın. OWASP ASVS, uygulama güvenliği doğrulaması için gereksinimler sağlar. İlgili gereksinimleri seçin ve kapsamlarını kaydedin. Güvenlik taraması sonucu tek başına uygulama davranışını doğrulamaz.

Başarılı işlemler kadar reddedilen işlemleri de test edin. Dışa aktarma örneğinde, yetkisiz kullanıcının başka müşterinin kayıtlarını isteyemediğini doğrulayın.

Saklanacak kanıt: gereksinim, değişiklik diff’i, test sonuçları ve inceleme kararı.

Kanıt olarak testler ve yapay zekânın ürettiği kodu inceleme ile devam edin.

5. Yayın kararını yeniden izlenebilir kılın

İncelenen revizyondan tanımlanabilir artefakt derleyin. Hedef ortamı, yapılandırmayı, zorunlu kontrolleri, kalan riskleri ve yayın kararını kaydedin. İhtiyaç duyulmadan önce rollback veya kurtarma yöntemini test edin.

İnsan yetkisinin ne zaman gerekli olduğuna karar verin. İstisnanın sorumlusunu, nedenini, kapsamını ve son geçerlilik tarihini tutun. Onaylı istisnayı kalıcı politika değişikliği saymayın.

Saklanacak kanıt: artefakt kimliği, yayın kaydı, onay veya politika kararı ve rollback talimatları.

Yayın kararlarını ve uyum kanıtını okuyun.

6. Dağıtımdan sonra yazılımın bakımını yapın

Bağımlılıkları ve dağıtılmış bileşenleri, yeni açıklanan güvenlik açıkları için tarayın. Hizmet, yeni kod commit’i olmadan savunmasız hâle gelebilir. Her bulguya sorumlu ve giderme kararı atayın.

Düzeltmeyi doğrulayın, dağıtın ve çalışan sürümü teyit edin. Kabul edilen riskleri kaydedin ve koşullar değiştiğinde yeniden inceleyin. Prototip bitmiş ürün sayıldığında bu sürekli iş sıklıkla eksik kalır.

Saklanacak kanıt: bileşen envanteri, tarama tarihi, ön değerlendirme kararı, giderme değişikliği ve dağıtım doğrulaması.

Sürekli güvenlik açığı yönetimi iş akışını izleyin.

7. İşletin, müdahale edin ve iyileştirin

Yararlı hizmet sonuçlarını, hataları ve güvenlik sinyallerini izleyin. Olay rolleri, konuyu üst sorumlulara iletme yolları ve SOC/SIRT sorumlulukları üzerinde anlaşın. Bu düzenlemeleri uygulamalı olarak test edin.

NIST Cybersecurity Framework, risk yönetimini yönetişim, koruma, tespit, müdahale ve kurtarmaya bağlar. İşletim modelinizi tanımlarken bu yaşam döngüsü bakışını kullanın.

Olayları ve tekrar eden sorunları incelenmiş değişikliklere dönüştürün. Otomatik kurtarmayı, doğrulaması ve durdurma koşulları olan yetkilendirilmiş işlemlerle sınırlandırın. Otomatik yeniden başlatma, ilk kusurun düzeltildiğinin kanıtı değildir.

Saklanacak kanıt: hizmet ölçümleri, olay kayıtları, kurtarma sonuçları ve doğrulanmış iyileştirme değişiklikleri.

Olay yönetimini ve sınırları belirli otomatik kurtarmayı keşfedin.

8. Hangi sorumlulukları geliştireceğinize veya satın alacağınıza karar verin

Kurum içi platformu, kodlama asistanlarını ve yapay zekâ yazılım fabrikasını aynı gereksinimlere göre karşılaştırın. Her görevi kimin yaptığını, hangi kanıtın mevcut olduğunu ve nelerin sizin sorumluluğunuzda kaldığını sorun. Bakım, kurtarma, entegrasyon ve çıkış maliyetlerini dahil edin.

Kuruluş üretime ortak yol sağlarken insanlar tercih ettikleri keşif araçlarını kullanmayı sürdürebilir. Hangi kodun, gereksinim tanımlarının ve testlerin araçlar arasında aktarılabildiğini kontrol edin. Gereken altyapıya dağıtımın ve tam bakım sürecinin gösterilmesini isteyin.

Taiga, yönetişim bilgileri ve ortak sorumluluk açıklaması yayımlar. Bunları gereksinimlerinize göre değerlendirilecek bir tedarikçinin materyali olarak kullanın. Bu öğrenme sitesini Taiga yayımlar; bağlantılar bağımsız tavsiye değildir.

Sorumluluk karşılaştırmasıyla başlayın. Ardından Taiga öğrenme yolu, bu soruların belirli ürün iş akışlarıyla ilişkisini gösterir.

Sık sorulan sorular

Düzenlemeye tabi kuruluşta vibe coding kullanabilir miyiz?

Evet. İnsanlara açık kurumsal sınırlar içinde sentetik veri, sandbox API’leri ve araç seçimi verin. Fikirleri test etmelerini ve yararlı prototipleri desteklenen teslimat yoluna getirmelerini sağlayın. Resmî üretimden önce bile, gizli veri veya gerçek izinler vermeden kontrolleri doğrulayın. Vibe coding: kullanım alanları ve sınırlar dersine bakın.

Yapay zekânın ürettiği kod farklı kabul ölçütleri gerektirir mi?

Gereken davranış ve risk kontrolleri geçerliliğini korur. Yapay zekâ; bağlam, veri işleme, izinler ve çıktı güvenilirliği hakkında ek sorular getirir. Kimin veya neyin ürettiğinden bağımsız olarak gerçek değişikliği ve kanıtını inceleyin.

Önce ne hazırlamalıyız?

Sentetik veri ve sonraki adım için belirlenmiş irtibat kişisi olan keşif ortamı hazırlayın. Yararlı prototipin amacını, kullanılması planlanan verileri, sorumluları, gereksinimleri ve kurtarma hedeflerini belgeleyin. Erişimi genişletmeden önce eksik kararları belirlemek için yazılım yaşam döngüsü alıştırmasını kullanın.