Copilot'ın üretmeye devam ettiği dört güvensiz GitHub Actions deseni

Copilot çalışan workflow'lar yazar, ama mutlaka güvenli olanları değil

GitHub Copilot, GitHub Actions YAML konusunda yetkinlidir: şemayı bilir ve hızla çalıştırılabilir workflow'lar üretir. Ancak jjoyneriv'in dev.to'daki yazısına göre, eğitim verisini dolduran güvensiz desenleri de aynı rahatlıkla yeniden üretiyor ve inceleme sırasında ikisini ayırt etmek kolay değil. Yazı, maliyetlerine göre sıralanmış dört özel hata modunu ve modelin ürettiklerini gerçekten değiştiren çözümleri tanımlıyor.

github.event üzerinden command injection

En maliyetli hata, katkıda bulunanların kontrolündeki değerleri — bir pull request başlığını, açıklamasını, branch adını veya commit mesajını — doğrudan ${{ }} ile bir run: adımına yerleştirmektir. İfade, shell onu ayrıştırmadan önce scripte yerleştirildiği için, kötü niyetli bir pull request başlığı runner üzerinde rastgele komutlar çalıştırabilir ve YAML tırnaklama hiçbir koruma sağlamaz.

Çözüm mekaniktir: güvenilmeyen değerleri bir env: bloğu üzerinden geçirin, böylece shell onları sıradan ortam değişkenleri olarak alır. Yazarın gözlemi, Copilot'ın açıkça istendiğinde güvenli sürümü, varsayılan olarak ise güvenlik açıklı sürümü ürettiğidir.

Workflow token'ları depo varsayılanlarında bırakılıyor

Üretilen workflow'lar genellikle permissions bloğunu tamamen atlar, böylece job token'ı deponun varsayılan olarak verdiği — sık sık geniş yazma erişimi olan — izinleri devralır. Önerilen desen, workflow düzeyinde contents: read kullanmak ve yalnızca ihtiyaç duyan belirli job içinde contents: write olarak genişletmektir. Yazı, bloğu tamamen atlatmanın, onu yanlış yazmaktan çok daha yaygın olduğunu belirtiyor.

Taşınabilir tag'lere sabitlenmiş üçüncü taraf action'lar

Copilot genellikle action'lara @v3 gibi sürüm tag'leriyle atıfta bulunur. Bir tag, bakımcının — ya da hesabını ele geçirmiş bir saldırganın — herhangi bir anda farklı bir koda yönlendirebileceği bir etikettir ve deponuzda görünür bir değişiklik olmaz. Her üçüncü taraf action'ı tam bir commit SHA'sına sabitlemek bunu engeller. Yazar, neredeyse her genel örneğin tag kullandığı için bunun Copilot'ın kendini düzeltme olasılığının en düşük olduğu alan olduğunu vurguluyor.

Fork kodunu çalıştıran pull_request_target

Dördüncü desen bilinen bir güvenlik açığı vektörüdür. pull_request_target, workflow'ların fork pull request'lerine yorum yapabilmesi veya etiket verebilmesi için vardır; yazılabilir bir token ve base deposu bağlamında secret erişimiyle çalışır. Üretilen bir workflow bu tetikleyiciyi fork'un head'inin checkout'ıyla eşleştirip ardından kurulum ve test script'lerini çalıştırdığında, güvenilmeyen kod, secret'lara ve yazma yeteneğine sahip bir token'a sahip bir job içinde çalışır — bu, "fork'lardan gelen pull request'leri test et" isteğine makul görünen ama aynı zamanda ciddi bir delik olan bir yanıttır. Tavsiye, yükseltilmiş bağlam gerçekten gerekli olmadıkça düz pull_request kullanmak ve bu bağlama sahip job'da asla fork kodu çalıştırmamaktır.

Saklı kimlik bilgileri yerine OIDC

Dördün ötesinde, yazı, uzun ömürlü bulut kimlik bilgilerinin yerine OIDC kullanılmasını savunuyor; burada workflow, depoya ve branch'e kapsamlı bir token'ı kısa ömürlü sağlayıcı kimlik bilgileriyle takas eder. Bu, sızabilecek, döndürülmesi gerekebilecek veya loglarda ortaya çıkabilecek kalıcı secret'ları ortadan kaldırır. Copilot, adıyla istendiğinde OIDC'yi iyi ele alır, aksi halde enjekte edilmiş secrets.AWS_ACCESS_KEY_ID tarzı anahtarlara yönelir.

Instructions dosyaları ve actionlint

İki değişiklik, prompt ifadesinden daha çok çıktıyı iyileştirir. Kuralları içeren bir .github/copilot-instructions.md dosyası — SHA'lara sabitle, github.event'i asla run: içine yerleştirme, izinleri bildir — modele her istekte, zaten sahip olmadığı bilgileri verir. Ve injection desenlerini, hatalı ifadeleri ve şema hatalarını kabaca bir saniyede işaretleyen actionlint, mekanik alt küme için bir kapı görevi görür. Kör noktası önemli: izinler, sabitleme ve tetikleyici seçimi sözdizimi değil politika meselesidir, bu yüzden hâlâ insan inceleyicısına veya instructions dosyasına ihtiyaç duyarlar.

Neden önemli

CI runner'ları depolara, package registry'lere ve bulut hesaplarına yazma erişimine sahiptir ve asistanlar artık yeni workflow YAML'ının anlamlı bir kısmını tasarlaıyor. Tehlike, üretilen workflow'ların başarısız olması değil — incelemeden geçerken injection açıkları, aşırı kapsamlı token'lar, sabitlenmemiş action'lar veya yanlış kullanılmış bir tetikleyici taşıyarak başarılı olmasıdır. Statik linting sözdizimi düzeyindeki sorunları kapsar, ancak politika düzeyindeki kararlar hâlâ insan işidir ve bunları kalıcı bir instructions dosyasında kodlamak, şu anda bir asistanın bunları varsayılan olarak uygulamasını sağlamanın en güvenilir yoludur.