GitLab 18.9: Kendi yapay zeka modelleri ve yapay zeka destekli güvenlik özellikleri

GitLab, Agentic Chat, Planner Agent ve Security Analyst Agent'ı içeren Duo Agent platformunu bu yılın başlarında genel kullanıma sunduktan sonra şirket, GitLab 18.9'un yayınlanmasını takip ediyor. Yenilikler, diğer şeylerin yanı sıra, AI modellerimizi birbirine bağlamaya, güvenlik araçlarının geniş çapta genişletilmesine ve geliştiriciler tarafından uzun süredir talep edilen bir özelliğin sağlanmasına odaklanıyor: proje düzeyinde Epic.

Yapay zeka modellerinizi belirteç kimlik doğrulaması yoluyla bağlayın

Kendi Anahtarını Getir (BYOK) sloganı altında GitLab, ilk aşamada GitLab AI Gateway aracılığıyla şirkete ait AI modellerine abonelik kullanma olasılığını sunuyor. Amaç, şirketlerin AI sağlayıcılarıyla mevcut sözleşmeleri kullanmaya devam etmesi ve aynı zamanda Duo Agent platformunun aracı iş akışı özelliklerine erişim kazanmasıdır. Bağlantı, belirteç tabanlı kimlik doğrulama yoluyla yapılır. İşlevsellik, Duo Agent platformunun kendi kendine barındırılan seçeneğine ve önceki sürümlerin şablon seçimine dayanmaktadır.

Agentic Chat de genişletilecek: gelecekte dosya yüklemelerini ve web içeriğini eksiksiz bir bağlam olarak işleyebilecek. Ekipler bunu, harici belgelerde GitLab'a gitmek zorunda kalmadan günlükleri, özellikleri ve belgeleri doğrudan temsilci konuşmalarına getirmek için kullanabilir. Duyuruya göre bunun, tamamen veri havuzuna dayalı akıl yürütmeden çapraz kaynaklar hata analizi ve planlamasına doğru bir adım uzaklaşması amaçlanıyor.

Yanlış alarmlara karşı ve otomatik güvenlik açığı onarımı için yapay zeka

Güvenlik söz konusu olduğunda GitLab giderek daha fazla yapay zekanın yardımına güveniyor. Yeni yapay zeka destekli hatalı pozitif tespit özelliği, gizli tespit sonuçlarını geliştiricilere ulaşmadan önce analiz etmeyi amaçlıyor. GitLab'a göre sistem, test kimlik bilgilerini, örnek değerleri ve yer tutucu sırlarını tanımlayarak açıklamalar ve güven değerleri sağlıyor. Doğrulanmış yanlış alarmlar toplu silme yoluyla ortadan kaldırılmalıdır. GitLab, algılama doğruluğunu sürekli olarak iyileştirmek için hassasiyet ve geri çağırma ölçümlerinin toplandığını vurguluyor.

Aracı tabanlı toplu güvenlik açığı iyileştirmesi bir adım daha ileri gider: Aynı güvenlik açığı modeli kodun birden çok yerinde meydana geldiğinde, sistem ilgili bulguları ortak nedenlere göre gruplandırmayı ve birleştirilmiş birleştirme istekleri (MR'ler) oluşturmayı amaçlar. GitLab bununla birlikte her bir örnek için ayrı bir MR oluşturulduğunda ortaya çıkabilecek “inceleme yorgunluğunu” da ortadan kaldırmak istiyor. Bu özellik mevcut SAST çözünürlük akışını temel alır.

Ek olarak GitLab, bağımlılık artırma yoluyla otomatik iyileştirmeyi genişletiyor: Otomatik iyileştirme, DÜŞÜK'ten KRİTİK'e kadar yapılandırılabilir önem düzeylerini desteklemeli ve büyük, küçük ve yama sürümü atlamaları arasında seçim yapılmasına izin vermelidir. Etkilenen bağımlılıklar daha sonra gruplandırılmış veya bireysel birleştirme istekleri halinde güncellenebilir.

Varsayılan dalın ötesinde güvenlik açığı yönetimi

GitLab'a göre sıklıkla talep edilen bir özellik, varsayılan olmayan dallardaki güvenlik açıklarının izlenmesidir. Platform bugüne kadar yalnızca varsayılan daldaki güvenlik açıklarını günlüğe kaydediyor; bu da kuruluşlara uzun süredir devam eden sürüm dallarına, üretim kodlarının güvenlik durumu hakkında hiçbir görünürlük kazandırmıyor. Gelecekte ekipler, güvenlik açığı yönetimi için hangi şubelerin izleneceğini yapılandırabilmelidir. Durum değişiklikleri yerel olarak bireysel şubelere veya genel olarak uygulanabilir ve güvenlik açığı raporu şubeye özel filtreler alır.

Bu şube farkındalığı aynı zamanda güvenlik kontrol panelini ve yazılım malzeme listesini (SBOM) de kapsamalıdır: Güvenlik açığı eğilimleri, bağımlılık listeleri ve SBOM dışa aktarımları (CycloneDX, JSON ve SPDX formatlarında) gelecekte şubeye özel olarak mevcut olmalıdır.

Risk bazlı politikalar ve güvenliğin yeni rolü

GitLab, birleştirme isteği onay politikalarını KEV ve EPSS filtrelerini içerecek şekilde genişletiyor. KEV (Bilinen Suistimal Edilen Güvenlik Açıkları) ve EPSS (Exploit Tahmin Puanlama Sistemi), onay gerekliliklerinin artık yalnızca CVSS önem düzeyine göre değil, bir güvenlik açığının fiili olarak kullanılabilirliğine göre belirlenmesini mümkün kılar. Gelecekte güvenlik ekipleri, “bir bağımlılığın bilinen bir istismarı varsa birleştirmeleri engelle” gibi politikalar formüle edebilecek.

GitLab, yeni güvenlik yöneticisi rolüyle bir izin sorununu çözüyor: Daha önce güvenlik ekipleri, güvenlik açığı yönetimi için geliştirici veya bakımcı erişimine ihtiyaç duyuyordu ve bu nedenle gerekenden çok daha fazla hak alıyordu. GitLab'a göre yeni rol, Reporter'dan devralıyor ve misafirden sahibine doğrusal mirası kesen hiyerarşik olmayan bir model olan güvenliğe özel izinler ekliyor.

CI/CD, DORA ölçümleri ve proje düzeyindeki epikler

Manuel ardışık düzen işleri için iş girdileri artık CI/CD ardışık düzeni için kullanılabilir. Şu ana kadar girdiler yalnızca boru hattı düzeyinde mevcuttur; Bireysel manuel işlerin parametreleri değişirse işlem hattının tamamen yeniden başlatılması gerekir. Gelecekte, bireysel işlerin parametreleri önceki işlerin sonuçlarına göre de yapılandırılabilir olmalıdır. Bu yenilikle GitLab, özellikle Jenkins'ten taşınmak isteyen ekipler için geçişi kolaylaştırmayı umuyor.

DORA 4 Metrics API'nin, dört DORA metriğinin tamamını kapsamlı bir şekilde kapsaması amaçlanmaktadır: dağıtım oranı, değişikliklere yanıt süresi, değişiklik başarısızlık oranı ve hizmeti geri yükleme süresi. Bu, geliştiricilere GitLab arayüzüne bağlı kalmadan kontrol panellerine, yönetici raporlamasına ve otomatik uyarılara programlı erişim sağlamalıdır.

Proje düzeyinde Epics ile GitLab en çok istenen özelliklerden birini sunuyor. Şu ana kadar Epic'ler yalnızca grup düzeyinde mevcut ve GitLab'a göre bu, ekipleri gereksiz alt gruplar oluşturmaya veya kilometre taşlarını kötüye kullanmaya zorluyor. Gelecekte, yol haritası, pano ve görselleştirme desteği de dahil olmak üzere premium seviye destanlar proje düzeyinde de kullanılabilir olacak. GitLab bunu geçişler için belgelenmiş bir blok olarak tanımlıyor.

Blog yazısı ve sürüm notları, tüm değişikliklere ilişkin eksiksiz bir genel bakışın yanı sıra GitLab 18.9'un bireysel yönleri hakkında daha fazla ayrıntı sağlar.

(harita)