Innersource Security Advisories GA: Kurum İçi Zafiyet Yönetimi
Doğrusu, Açık kaynak tarafında bir CVE patladığında ne olacağını hepimiz az çok biliyoruz (evet, doğru duydunuz). GitHub Advisory Database’e düşer, Dependabot (belki yanılıyorum ama) uyarı verir, PR’lar açılır, ekipler de bir anda hareketlenir. Peki ya aynı şey şirket içindeki o meşhur “shared-utils” kütüphanesinde olursa? İşin aslı, yıllarca cevap kabaca şuydu: Slack’te duyur, herkese mail at, sonra da elle takip et.
Bi saniye — Neyse ki GitHub bu boşluğu doldurdu. Innersource Security Advisories artık genel kullanıma açık, yanı GA. İlk bakışta “e küçük bir feature işte” gibi durabilir. Sahada kurumsal ekiplerle çalışan biri olarak söyleyeyim; bu, kurum içi bileşen güvenliğinde baya kritik bir eşik.
Peki neden?
Peki Innersource Advisory Tam Olarak Ne Işe Yarıyor?
Kısaca şöyle: GitHub’ın açık kaynak advisory sistemi zaten vardı. CVE yayınlanır, veritabanına iner, Dependabot tarar, uyarır. Innersource advisories aynı mantığı kuruluşunuzun içine taşıyor. Ama görünürlük sadece o enterprise’a ait repolarla sınırlı kalıyor. Yanı dünyaya açmıyorsunuz; evin içinde dönüyor işte.
Bence, Ne değişiyor? Bak şimdi: Diyelim finans ekibiniz “internal-auth-lib” diye bir NuGet paketi yayınlamış. On beş farklı repo bunu kullanıyor. Bir gün JWT doğrulamasında bypass buldunuz. Eskiden ne yapardınız? Confluence’a yazı girer, ekip lead’lerine mesaj atar, JIRA ticket açar geçerdiniz… Şimdi işe REST API üzerinden bir advisory yayınlıyorsunuz; gerisini GitHub toparlıyor (buna dikkat edin)
Nasıl Çalışıyor Teknik Olarak?
Akış aslında sade görünüyor ama altında güzelce oturmuş bir düzen var. Advisory oluşturuyorsunuz — hangi bileşen etkilenmiş, hangi versiyon aralığı riskli, düzeltme hangi sürümde gelmiş, severity ne — sonra Dependabot devreye giriyor (evet, bildiğiniz o alert motoru). Enterprise içindeki repoları tarayıp bu bileşeni kullananları buluyor, uyarı çıkarıyor ve gerekiyorsa otomatik PR açıyor. Open source için ne yapıyorsa aynısını kapalı devrede yapmış oluyor.
POST /enterprises/{enterprise}/code-security/advisories
{
"summary": "Auth bypass in internal-auth-lib",
"description": "JWT signature validation can be bypassed...",
"severity": "high",
"vulnerabilities": [{
"package": {
"ecosystem": "nuget",
"name": "Contoso.InternalAuthLib"
},
"vulnerable_version_range": ">= 2.0.0, < 2.4.3",
"patched_versions": "2.4.3"
}]
}İtiraf edeyim, Endpoint detaylarını yine resmî dokümanda kontrol etmek lazım ama iskelet bu kadar net. Bir kere bu isteği attınız mı artık Dependabot sizin yerinize konuşmaya başlıyor.
Evet, doğru duydunuz.
Bu Neden Önemli? Sahadan Bakış
Kurumsal müşterilerde en sık gördüğüm dertlerden biri şu: shared libraries. Her büyük şirkette illâ bir core team olur; logging yazarlar, auth yazarlar, config yazarlar, retry policy çıkarırlar… Sonra bu kütüphaneler kurumun DNA’sına işlemiş gibi her yere yayılır.
Sorun şu ki güvenlik yönetimi çoğu zaman tribal knowledge seviyesinde kalıyor — yanı ağızdan ağıza dolaşıyor, Slack’ten Slack’e sıçrıyor. Kim hangi versiyonu kullanıyor belli değil (bizzat test ettim). Sız kalkıp da “şu paketin 1.2.4 sürümünde açık var” dediğinizde yarısı 1.1.x’te takılmış oluyor (neden öyle kaldılar bilmiyorum), diğerleri 1.2.6’ya geçmiş oluyor, üç repo hâlâ 0.9-beta kullanıyor… Sız ne dersiniz? klasik tablo.
Peki neden?
Open source zafiyet yönetimini çözdük diye kendimizi kandırıyoruz bazen.
Halbuki büyük şirketlerde saldırı yüzeyinin ciddi kısmı kimsenin görmediği o internal-utils paketinden geçiyor.
Bence, İşte innersource advisories tam bu boşluğa oturuyor.
SBOM (Software Bill of Materials) tarafında Dependabot’un iç envanteri. Vardı.
Şimdi onun üstüne bir de kurum içi CVE katmanı geliyor.
Bir nevi dışarıdaki NVD veritabanının içerideki kuzeni gibi düşünün.
Bunu Türkiye’deki Şirketler Açısından Dusunursak
Vallahi, Türkiye’de büyük kurumlar — bankalar, telco’lar, sigorta şirketleri, kamu tarafı — inanılmaz miktarda in-house kod üretiyor.
Regülasyon yüzünden çoğu zaman açık kaynak paketi doğrudan kullanamıyorlar; onun yerine kendi onaylı fork’larını çıkarıyorlar.
Bu da her bankada ve her telcoda paralel bir internal package registry dünyası doğuruyor.
Ve o paketlerde bulunan zafiyetler… Neden önemli bu? genelde sessizce kalıyor.
Utangaçlık mı dersiniz, süreç eksikliği mi dersiniz bilmiyorum ama durum böyle.
Sahada şunu çok görüyorum: güvenlik ekibi internal bir kütüphanede bug buluyor, düzeltiyor ve versiyon çıkarıyor.
Ama bilgi ekiplere iş öncelikleriyle birlikte gidiyor; yanı acil olmayan işlerin arasında kayboluyor.
Üç ay sonra hâlâ eski sürümü kullanan repolar çıkabiliyor karşınıza.
GitHub’ın bu yeni akışı en azından teknik olarak bu boşluğu kapatma potansiyeli taşıyor.
Regülasyon uyumluluğu tarafında da işleri kolaylaştırabilir çünkü artık “bu bileşende zafiyet bulundu”, “X tarihinde duyuruldu”, “Y tarihinde %90 repo güncellendi” diye denetlenebilir iz bırakıyorsunuz (ki bu çoğu kişinin gözünden kaçıyor)
Kimin Işine Yarar Kimin Yaramaz?
Açık konuşayım: bu özellik GitHub Advanced Security lisansı olan enterprise müşterilere yönelik.
Yanı herkes gidip kullanamıyor.
Fiyat tarafında GHAS zaten pahalı sayılır; kullanıcı başına aylık ücret var.
Küçük ekipseniz ya da startup’sanız buraya gelmek için önce ciddi bir GitHub Enterprise Cloud + GHAS yatırımı gerekiyor.
Bence, O yüzden şöyle ayırmak daha doğru olur:
| Profil | Innersource Advisory Mantıklı mi? | Alternatif |
|---|---|---|
| 10-30 kişilik startup, 20-30 repo | Hayır, fazla gelir | Slack #security kanalı + tag’li release notes |
| Orta ölçekli SaaS, 100+ repo | Sınırda — GHAS zaten varsa evet | Renovate + kendi advisory feed’ınız |
| Kurumsal yapı (banka, telco, kamu) | Evet diyebilirim — özellikle burada anlamlı |
Dürüst olayım, çok temiz alternatif yok — manuel süreç zorlayıcı kalır |
| Düzenlemeye tabi finans/sağlık | Evet — audit trail için baya işe yarar | Tamamı manuel süreç, ama denetimde yorucu olur ve hata payı artar |
Bütçe sıkışıksa GHAS almadan da bazı şeyler yapılabiliyor tabiî.
Renovate self-hosted kurarsınız,
kendi advisory JSON’unuzu beslersiniz,
bir şekilde akışı döndürürsünüz.
Ama itiraf edeyim:
Dependabot’un GitHub UI içine gömülü gelmesi ayrı rahatlık sağlıyor.
Ekipler zaten alert görmeye alışkın olduğu için oraya bir tane daha düşmesi doğal karşılanıyor;
ayrı tool koyunca adaptasyon biraz uzuyor,
işte orası sıkıntılı.
Nereden Başlanır? Pratik Yol Haritası Bu Tarafta Daha Faydalı Olur Mu?
Diyelim karar verdiniz ve bunu kuracaksınız.
İlk adımda ben şunları öneririm:
- Evin envanterini çıkarın. Kurum içinde yayınlanan internal package’ları listeleyin.
NuGet feed’i mi var,
npm registry mi var,
Maven repo mu dönüyor…
hepsine bakın.Kaç tane paket var,
kim maintain ediyor,
hangi repolar tüketiyor?
Bunları bilmeden ilerlemek biraz kör dövüşü oluyor. - Sahiplik matrisi kurun..
Her paketin sahibi net olsun.“Şu paket için security kararını kim veriyor?”
sorusunun cevabı yoksa,
advisory yayınlamaya kalktığınızda ekip içi çekişme çıkabiliyor.Bu kısmı hafife almayın;
sonra herkes birbirine bakıp dürüyor. - Ciddiyet rehberi yazın..
Ne zaman critical diyeceksiniz,
ne zaman high diyeceksiniz…
basit bir kılavuz hazırlayın.CVSS skoru kullanılabilir ama iç bileşenlerde bazen fazla akademik kaçıyor.
Ben daha pratik bakıyorum:
exploitability + blast radius.İkisi birleşince tablo daha anlaşılır oluyor;
fazla teoriye boğmaya gerek yok bence. - Pilot seçin..
Tüm kuruma aynı anda açmayın.Bir domain seçin mesela;
platform ekibinin paketleri olabilir.Orada süreç oturdukça genişletirsiniz.
Aksi hâlde ilk hafta herkes sorularla gelir,
ortam gereksiz karışır,
neyse uzatmayayım. - REST API’yi otomasyona bağlayın..
Security scanning tool’unuz
(Snyk olabilir,
SonarQube olabilir,
başka bir şey de olabilir)
internal repolarda açık bulunca otomatik advisory taslağı oluşsun.Sonra insan review etsin,
ardından publish edilsin.Tam otomasyon kulağa hoş geliyor ama burada küçük bir insan kontrolü iyi gidiyor doğrusu.
- Advisory publish edildi
- Dependabot enterprise içindeki dependency graph ‘ i taradı
- Etkilenen repolarda Security tab ‘ ında alert çıktı
- Eğer
dependabot.ymlconfigure edilmişse,güncelleyen PR otomatik açıldı - Repo sahibi PR ‘ i merge etti ve iş bitti
NuGet,NPM,Maven each use a different semver notation.
If you write the range wrong,
Dependabot may alert the wrong repos or not alert at all.
Before publishing,test it with a dry run in your ecosystem first.
It saves time later,
cidden kurtarıyor sizi.
Küçük Bir Uyarı: Custom Rol Meselesi Var Burada Ilginç Şekilde()
Güncel durumda advisory publish etme yetkisi enterprise owner veya security manager rolüyle sınırlı dürüyor.
Custom rol yok
yanı sadece Java paketleri için advisory yayınlayabilen daraltılmış rol tanımlayamıyorsunuz.
Büyük organizasyonlarda bu gerçekten problem yaratabilir.
Umarım GitHub önümüzdeki aylarda RBAC granularity ekler;
şu an taraf biraz ham kalmış durumda,
açık söyleyeyim.
Dependabot Entegrasyonu ve Otomatik PR
En sevdiğim taraf burasıdır.
Advisory yayınladığınızda Dependabot etkilenen repoları bulup
hem alert atıyor hem de fix PR açıyor.
Yanı süreç şöyle ilerliyor:
Kağıt üstünde gayet iyi dürüyor.
Pratikte işe göreceğiz;
özellikle monorepo ‘ larda dependency graph ‘ in ne kadar doğru çıktığı biraz merak konusu.
Büyük repolarda bazen Dependabot ‘ un dependency inference ‘ i sıkıntılı olabiliyor,bunu bilen bilir.
Bu tarafta hâlâ eksik olan X var diyeceğim,
o X de monorepo ‘ da hangi subproject etkilendi granularity ‘ si.
Umarım zamanla toparlanır.
Bu arada,iç zafiyet yönetimini konuşurkenGitHub Secret Scanning:Genişletilmiş Metadata ve Çoklu Doğrulamawritedığım secret scanning tarafındaki iyileştirmeler de resmin parçası sayılır.
İkisi birlikte düşünülünce,Github’ın supply chain security hikâyesi baya olgunlaşmış durumda.
İşte,
Alternatifler ve Ekosistem
GHAS dışında da benzer işi yapan araçlar var.
Snyk’in enterprise tarafında buna yakın bir internal advisories yaklaşımı bulunuyor.
JFrog Xray,Sonatype Nexus IQ…
hepsi kendi advisory feed’lerini destekliyor.
Peki fark nerede?
`Github`’ın avantajı geliştiricinin zaten olduğu yerde olmasıdır.Dependabot` uyarısı Security tab’da çıkınca PR da aynı akıştan geliyor.Bu adaptasyon açısından değerli.`Snyk` gibi ayrı tool kurduğunuzda geliştirici dashboard’a girmeye üşenir,bazen alert’ler bekleyip durur,kimsede ses olmaz.Bunu gerçekten çok gördüm,açık konuşayım.
Öte yandan Snyk’in vulnerability veritabanı daha geniş olabiliyor,lizans compliance tarafı daha güçlü kalabiliyor.Yani sadece iç advisory için GHAS almak bazen pahalıya gelebiliyor.Ama zaten GHAS lisansınız varsa,bence özelliği kullanmamak tuhaf kaçabilir.
`DevOps` entegrasyonu açısından bakarsak,Azure DevOps’ta SQL Projeleri:Pipelin e Kurmanın Temelleriwritedığım pipeline yaklaşımlarını bu advisory sistemine bağlayabilirsiniz.CI’da advisory kontrolü koyup build’i kırmak,fena olmayan bir gate oluyor.
Anlatırken Ben Ne Düşünüyorum?>Hmm,bir düşüneyim… Evet,dediğim gibi:b u özellik doğru yönde atılmış adım ama devrimsel değil.Yani olmazsa olmaz değil,var olan boşluğu dolduruyor.GHAS müşterisiyseniz kesinlikle bakın.Değilseniz hemen koşup GHAS almayın önce mevcut security sürecinin en zayıf halkasına bakmak lazım.
Bence en büyük kazanım d e n e t i m izi . Regülatöre `biz iç bileşenlerde bulunan zafiyetleri nasıl yönetiyoruz?` sorusuna artık `işte advisory feed’miz`, `işte remediation süresi metrikleri` diyebiliyorsunuz.Bu da özellikle KVKK,BDDK,SOX gibi düzenlemelere tabi kurumlarda değerli hâle geliyor.
>Bir de şu var:this feature kurumların `internal open source` kültürünü teşvik ediyor.Innersource dediğimiz felsefe zaten `iç kaynağı açık kaynak gibi yönet` demek.Advisory sistemi bunun security ayağını tamamlıyor.Ekiplerin kendi paketlerini ciddiye almasını,sürüm politikası kurmasını,semver’e uymasını dolaylı biçimde zorlayan güzel bir parça olmuş.Bunu olumlu buluyorum.
Sıkça Sorulan Sorular
Innersource advisory kullanmak için hangi GitHub lisansı lazım?
İnanın, GitHub Enterprise Cloud + GitHub Advanced Security lisansı gerekiyor. Yanı GHAS’sız enterprise’larda bu özelliği açamıyorsunuz. Fiyatlandırma kullanıcı başına aylık, açıkçası ciddi bir maliyet kalemi olabiliyor.
Yayınladığım bir advisory’yi geri çekebilir mıyım?
Evet, çekebilirsiniz. REST API üzerinden “withdraw” operasyonu var. Yanlış yayınladığınızı fark ederseniz ya da bulgunun geçersiz olduğu ortaya çıkarsa kullanabilirsiniz. Ama şunu da söyleyeyim — alert bir kere düştüyse insanların dikkatini çekmiş oluyor. Neden önemli bu? Geri çekmek güveni biraz zedeliyor, bence publish etmeden önce gerçekten iyi doğrulamak gerekiyor.
Dependabot her paket yöneticisini destekliyor mu?
Ana ekosistemleri destekliyor: npm, NuGet, Maven, PyPI, RubyGems, Composer, Go modules, Cargo. Ama aslında önemli olan şu — iç registry’nizin Dependabot tarafından okunabilir olması lazım. Private feed authentication’ı doğru yapılandırmazsanız Dependabot repoyu tarayamıyor, dolayısıyla hiç alert de atmıyor.
Advisory yayınlamak açığın detayını dışarı sızdırmaz mı?
Hayır, sızdırmıyor. Innersource advisory’lerin görünürlüğü enterprise’la sınırlı. Hani public GitHub Advisory Database’e düşmüyorlar. Zafiyet detayları sadece sizin enterprise’ınızdaki kullanıcılar tarafından görülebiliyor — bu da mesela regüle sektörler için önemli bir garanti aslında.
Mevcut zafiyet yönetim sürecimi baştan mı kuracağım?
Şart değil. Mevcut süreçlerinizin üstüne bir katman olarak ekleyebilirsiniz. Mesela Snyk veya SonarQube kullanıyorsanız, onların bulgularını innersource advisory formatına çeviren bir automation yazıp API üzerinden publish edebilirsiniz. Böylece geliştiricilerin gördüğü tek arayüz GitHub oluyor, backend’de istediğiniz tool’u çalıştırabiliyorsunuz. Tecrübeme göre bu yaklaşım geçiş sürecini çok daha az acılı hâle getiriyor.
Kaynaklar ve İleri Okuma
GitHub Changelog: Innersource security advisories are generally available
GitHub Docs: Creating and using innersource advisories
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments