Codex Security Cloud, DevDay 2026'da GitHub depolarını tarama ve yeni commitleri izleme işini bulut eklentisine taşıdı. OpenAI bunu araştırma önizlemesi olarak sunuyor. Değer önerisi yalnız “açık buldu” demek değil: bulgunun etkilenen kodunu, doğrulama kanıtını ve önerilen düzeltmeyi birlikte görüp insan kararıyla taslak pull request oluşturmak.
Güvenlik araçlarında otomatik sonuca aşırı güvenmek kolaydır. Resmî kurulum akışı bu nedenle bulguyu açma, bağlamı inceleme ve yamayı gözden geçirme adımlarını içeriyor. Bu yazı özelliğin kapsamını ve bir web ekibinde nasıl pilotlayacağımı anlatıyor; belirli bir deponun güvenli olduğunu veya aracın bütün açıkları bulacağını iddia etmiyor.
Bu yazının duyuru ve erişim bilgileri OpenAI’nın resmî özellik belgesi ile DevDay 2026 toplu duyurusu üzerinden doğrulandı. Örnek proje ve deneme önerileri editoryal yorumdur.
İlk kurulum nasıl başlıyor?
ChatGPT web ya da masaüstü Plugins alanında Codex Security Cloud eklentisi yüklenip Security Cloud açılıyor. Yeni taramada GitHub bağlantısı istenirse erişilecek depolar seçiliyor. Codex Cloud çalışma alanının kurulmuş olması ve uygun Cloud Environment seçilmesi gerekiyor. Ekip, bağlantı iznini tüm organizasyona yaymadan önce küçük, iyi bilinen bir depoyla deneme yapmalı. Tarama için gerekli repo izni ile düzeltme için gereken PR yetkisi ayrı değerlendirilirse yanlışlıkla fazla kapsam açılmaz.
Bulgu ekranı ne gösteriyor?
Resmî kılavuz, bulguya girildiğinde etkilenen kod, doğrulama kanıtı ve iyileştirme rehberi görülebileceğini söylüyor. “Fix with Codex” uygun bulguda önerilen yamayı üretiyor. Bir güvenlik mühendisi veya kod sahibi, yamayı yalnız derleniyor diye kabul etmemeli: davranışı değiştiriyor mu, korumayı gerçekten sağlıyor mu, başka hata açıyor mu? Bulgu önem sırası da gerçek tehdit modeline göre okunmalı. Otomatik açıklamanın kanıtını görmek bu yüzden kritik.
Commit izleme neyi değiştiriyor?
Bir kerelik repo taramasından farklı olarak yeni commitler izlenebiliyor. Yeni tarama oluştururken “Commit changes” kapsamı seçiliyor; ardından değişiklikler geldikçe inceleme akışı sürüyor. Bu, CI sinyaline benzeyen sürekli bir güvenlik gözlemi sağlayabilir; ancak araştırma önizlemesindeki araç için kapsam, gecikme ve hatalı alarm oranı kendi depoda ölçülmeli. Her alarmı acil müşteri sorunu saymak da, hiçbirini incelememek de sağlıklı değil. Kod sahipliği ve önceliklendirme kuralı gerekli.
Taslak PR neden son durak?
Önerilen yamanın draft pull request olarak açılması, düzeltmenin otomatik üretime girdiği anlamına gelmez. Taslakta diff, test sonucu ve güvenlik gerekçesi değerlendirilebilir. Ben bu aşamada güvenlik açığının yeniden üretim adımını ve yama sonrası davranışı karşılaştırırdım. Değişiklik gizli bilgiye dokunuyor mu, geriye uyumluluğu bozuyor mu, performansı etkiliyor mu? Kod incelemesi ve normal dağıtım süreci geçerli kalmalı. Araç öneriyi hızlandırabilir; merge kararı ekipte kalır.
Örnek pilot: form işleyen web uygulaması
Bir müşteri formu ve dosya yükleme alanı olan örnek depoda önce bilinen kod haritasını çıkarırdım. Security Cloud taramasından gelen bulguların hangisi gerçek kullanıcı akışına açık, hangisi yalnız test verisinde görülüyor, ayırırdım. Ardından önerilen iki yamayı ayrı dallarda çalıştırıp birim ve uçtan uca testleri tekrar koştururdum. Bu senaryo bir güvenlik kanıtı değil; aracın bulgu ve düzeltme zincirini denetlemek için kontrollü yöntem. Gerçek müşteri verisi yerine sentetik test içeriği kullanılmalı.
Tehdit modeliyle bağlantı
Resmî kaynaklarda “improving the threat model” rehberi ayrıca bulunuyor. Depoda hangi varlıkların önemli, hangi sınırların geçilemez ve hangi saldırı yüzeylerinin internetten erişilebilir olduğu bilinmezse bulguları sıralamak zorlaşır. Yalnız araç puanına bakmak yerine uygulamanın gerçek mimarisini ve yayına çıkma biçimini belgelerdim. Bir admin panelindeki yetki açığı ile yalnız geliştirme aracındaki uyarı aynı iş etkisine sahip olmayabilir. Bu ayrım, güvenlik ekibinin kapasitesini doğru yerde kullanmasını sağlar.
Araştırma önizlemesi ne ifade eder?
OpenAI, Security Cloud'u research preview diye adlandırıyor. Bu, ürünün herkeste aynı erişimle, sabit fiyat ve aynı davranışla çalıştığı varsayımından kaçınmak gerektiği anlamına gelir. Özellik, kullanılabilir depo türleri ve bulgu kalitesi değişebilir. Bir kurumda resmî güvenlik kontrolünün yerine koymadan önce uyum, erişim ve denetim kayıtları incelenmeli. Araç uygun görünse bile mevcut güvenlik tarayıcıları ve insan incelemesiyle birlikte çalışması daha gerçekçi bir konumlandırma.
Başarıyı nasıl ölçerdim?
Tarama başına bulgu sayısı tek ölçü olmamalı. Doğrulanabilen gerçek bulgu oranı, inceleme için harcanan dakika, yamanın kabul oranı ve regresyon sayısı daha açıklayıcı. Yeni commit izleme için uyarının ilgili ekibe ulaşıp ulaşmadığına da bakardım. Bir ay sonunda “çok alarm verdi” yerine “hangi gerçek riski daha erken fark ettik?” sorusu cevaplanmalı. Önerilen düzeltme iş yükünü azaltmıyorsa otomatik PR sayısını artırmak başarı değildir.
Bulgunun kanıtını nasıl okurum?
Bir bulguda kod satırı, iddia edilen etki ve doğrulama kanıtı aynı hikâyeyi anlatmalı. Yalnız potansiyel tehlike cümlesi varsa bunun gerçek kullanıcı yoluna bağlanıp bağlanmadığını araştırırım. Kanıt belirli bir girdi veya çağrıya dayanıyorsa test ortamında yeniden üretilebilmeli. Yanlış pozitif olasılığı kadar, önemli bir açığın tarama dışında kalabileceği de kabul edilmeli. Bu nedenle bulguyu önce repo sahibi, sonra gerekiyorsa güvenlik sorumlusu görmeli. Kanıt görüntüsünü veya otomatik önem derecesini bağlamdan koparıp müşteri duyurusu yapmak erken ve yanıltıcı olabilir.
Yama için kabul ölçütü
Önerilen düzeltmenin yalnız uyarıyı susturması yeterli değil. Kabul testinde açığın yeniden üretilememesi, var olan işlevlerin korunması ve kodun sürdürülebilir kalması aranmalı. Örneğin yetki açığında tüm endpoint'i kapatmak riski azaltır ama ürünü de bozabilir; doğru kullanıcıların erişimini koruyan çözüm gerekir. Draft PR içinde değişen dosyalar, yeni test ve kalan risk açıkça yazılmalı. Araç bir yama önerdiğinde “merge” adımını ayrıca düşünmek, Security Cloud'un inceleme odaklı tasarımına uygun. İnsan kararı, otomasyonun düşmanı değil güvenlik bağlamının tamamlayıcısıdır.
Commit akışında alarm sahipliği
Yeni commit izlemesi açıldığında bulgunun kime gideceği belirlenmeli. Her uyarı aynı genel kanala düşerse ekip kısa sürede okumamaya başlayabilir. Repo kod sahibi, güvenlik sorumlusu ve ürün sahibi arasında öncelik kuralı koyardım: kullanıcı verisi etkisi, internetten erişilebilirlik ve düzeltme kolaylığı. Uyarı aynı değişiklik için tekrar geliyorsa tek bir takip kaydına bağlanmalı. Bu editoryal süreç, resmî ürünün hazır triage sistemi sunduğu iddiası değil; olay akışından anlamlı karar çıkarma yöntemi. Araştırma önizlemesinde alarm kalitesini gözlemlemek özellikle önemli.
Bulut ortamı bağımlılığı
Security Cloud taraması için Codex Cloud'un kurulmuş olması ve uyumlu Cloud Environment seçilmesi gerekiyor. Ortamın repo bağımlılıklarını karşılamaması, taramanın veya yama doğrulamasının eksik kalmasına yol açabilir. Bir güvenlik pilotuna başlamadan önce ortamda testlerin çalıştığını, GitHub bağlantısının doğru depoya verildiğini ve gizli değerlerin gereksiz yere açılmadığını doğrularım. Özellikle güvenlik aracına yüksek repo yetkisi verme eğilimine karşı önce okuma ve öneri akışını sınırlı depoda görmek iyi. Bulut ortamının internete çıkış ve Agent Security ayarları da ayrı gözden geçirilmeli.
Araştırma önizlemesinde raporlama dili
Müşteriye “AI güvenlik taraması tüm açıkları buldu” demek hem kanıtsız hem riskli. Daha doğru rapor, taranan repo ve commit aralığını, bulunan ve doğrulanan bulguları, yapılan düzeltmeleri ve açık kalan incelemeleri listeler. Uyarı çıkmaması güvenlik sertifikası değildir. Bir uygulamanın sır yönetimi, altyapı ayarı ve çalışan cihazı gibi repo dışındaki riskleri bu tarama tek başına kapsamayabilir. Pilotun sonunda aracı mevcut statik analiz, bağımlılık taraması ve manuel gözden geçirme ile nasıl tamamlayacağımızı yazarım. Böylece yeni araç gerçek güvenlik programında yerini bulur.
İnceleme kuyruğunu sınırlandırmak
İlk taramada çok sayıda bulgu çıkarsa hepsini aynı hafta çözmeye çalışmak gerçekçi değil. Önce kullanıcı verisine, yetki sınırına ve internete açık akışa etkisini değerlendiririm. Düşük öncelikli önerileri ayrı kayıt altında tutarım; hiçbiri sessizce kaybolmaz. Böyle bir sıralama için kod sahibi ve güvenlik sorumlusu beraber çalışmalı. Security Cloud'un önerdiği önem derecesi başlangıç sinyali olabilir, iş etkisinin yerine geçmez. Pilotun başarısı “kaç uyarı kapattık?” değil, hangi gerçek riskin neden önce ele alındığının açıklanabilmesi.
Yama sonrası izleme
Bir PR kabul edilip dağıtıldıktan sonra güvenlik işi bitmez. Aynı bulgu yeni commitlerde tekrar çıkıyor mu, düzeltme başka işlevi bozuyor mu, izlenmeli. Security Cloud yeni commit taramasını desteklediğinden bu geri besleme için kullanılabilir. Fakat araştırma önizlemesinde aracın kapsamı değişebilir; normal CI testleri ve bağımlılık kontrolleri korunmalı. Ben her doğrulanmış bulgu için kök neden notu tutardım: eksik test, yanlış yetki modeli veya belirsiz kod sahibi mi? Böylece araç yalnız tek yamayı değil ekipteki tekrar eden hatayı azaltmaya yardım eder.
Sonuç
Codex Security Cloud, repo taraması ile önerilen düzeltmeyi aynı inceleme zincirinde buluşturuyor. Araştırma önizlemesi olduğu için geniş vaatlerden kaçınmak ve kontrollü pilot yapmak gerekiyor. En anlamlı kullanım, etkilenen kodu, kanıtı ve yamayı beraber görebilen bir ekibin güvenlik kararını hızlandırması. Nihai kabul, test ve dağıtım kararı yine kod sahibinde kalmalı.
Sık sorulan sorular
Security Cloud kodu otomatik düzeltip yayımlar mı?
Resmî akış bulgu ve önerilen yamayı inceletir; uygun durumda insan kararından sonra taslak PR oluşturulabilir.
Hangi depoları izler?
Bağlanan GitHub depoları ve seçilen yeni commit kapsamı; erişim izinleri kurulumda belirlenir.
Bu genel erişimde mi?
OpenAI özelliği araştırma önizlemesi olarak duyuruyor; hesap erişimi ve koşullar kontrol edilmeli.
İlgili yazılar
- DevDay 2026: bütün duyurular
- Codex'te Astra Ultrafast: Hız, Erişim ve Kullanım Bedeli
- Codex Cloud Environments: Hazır Ortamla Bulutta Geliştirme