Vet – Uzak kabuk betiklerini daha güvenli çalıştıran araç

 (getvet.sh)
10 puan yazan GN⁺ 2025-07-02 | 1 yorum | WhatsApp'ta paylaş
  • vet, curl | bash tarzı uzak kurulum betiklerinin çalıştırılmasını "indir→incele→çalıştırmayı onayla" sürecine güvenli biçimde dönüştüren bir CLI aracıdır
  • Betik değişikliklerini (diff) görüntüleme, shellcheck tabanlı lint (statik analiz), doğrudan onay (inceledikten sonra çalıştırma) gibi katmanlı savunma özellikleri sunar
  • Tek bir komutla (vet https://example.com/install.sh) uzak bir betiği çalıştırmadan önce olası riskleri, kurcalamayı, yazım hatalarını ve zafiyetleri otomatik olarak denetleyebilir
  • Kurulumda da kendi içinde hem "indirip inceleme" yöntemini hem de curl | sh yöntemini destekler; vet’in kendi kurulum kodu da doğrudan incelenebilir
  • Geliştirme/operasyon ortamlarındaki güvenlik risklerini önlerken aynı anda otomasyon ve kullanım kolaylığı sağlayan, yüksek güvenilirlikli bir çözümdür

Sorun: Uzak kurulum betiklerinin gelişigüzel çalıştırılması

  • Birçok açık kaynak proje ve araç, curl -sSL https://example.com/install.sh | bash gibi uzak betik tabanlı kurulum yöntemlerini önerir
  • Bu yaklaşım, betiğin değiştirilmesi/sunucunun ele geçirilmesi/ağ hataları gibi nedenlerle kötü amaçlı kod çalıştırma, eksik dosya çalıştırma gibi kritik güvenlik riskleri barındırır

vet’in çözümü: Güvenli etkileşimli çalıştırma

  • vet, uzak betik çalıştırmayı aşağıdaki 4 adımlı güvenlik süreciyle sarar
    • 1. Fetch: Uzak betiği geçici bir konuma güvenli biçimde indirir
    • 2. Diff & Review: Önceki çalıştırma geçmişiyle karşılaştırıp değişiklikleri (diff) gösterir, yeni/değişen kodun gözle doğrudan incelenmesini sağlar
    • 3. Lint: shellcheck (kuruluysa) ile hata/zafiyet/anormal kalıplar için otomatik statik analiz yapar
    • 4. Confirm: Gerçek çalıştırmadan önce kullanıcıdan son onayı (yes/no) ister
  • Tek komut: 
    vet https://example.com/install.sh

Kurulum yöntemi

Güvenli önerilen yöntem (indir → incele → çalıştır)

Hızlı kurulum (güvene dayalı tek satır)

vet’in özellikleri ve avantajları

  • Değişiklik algılama (diff): Daha önce çalıştırılan betiklerle karşılaştırıp nelerin yeni değiştiğini görmeyi sağlar
  • Otomatik lint (shellcheck entegrasyonu): Kabuk betiklerinde zafiyetleri, yazım hatalarını ve şüpheli kodu otomatik teşhis eder
  • Açık yürütme onayı (Confirm): Tek bir tıklama/girdiyle gerçek çalıştırmayı doğrudan kontrol etmeni sağlar
  • Betikleri otomatik kaydetme ve geçmiş yönetimi: Sık kullanılan kurulum betiklerini de güvenli biçimde izlemeyi mümkün kılar
  • Dahili olarak güvenli kurulum/güncelleme de garanti eder

Sonuç

  • vet, hem geliştiriciler hem de operasyon ekipleri için gerekli olan güvenli bir "curl | bash" alternatifi olarak, kurulum otomasyonu ile güvenliği aynı anda hayata geçirir
  • "Öylece çalıştırmayın; vet ile doğrulayıp sonra çalıştırın!"

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-02
Hacker News yorumları
  • Vakaların %90’ında, bir yükleyici kullanırken yazılımın güvenilirliğinin gerçekte nasıl doğrulandığını merak ediyorum. Bazı durumlarda kod imzalanmış oluyor ama çoğu durumda kod, ek doğrulama olmadan aynı HTTPS sunucusundan geliyor. Kod derlenmiş haldeyse diff yapılıp yapılmadığını da merak ediyorum. İnternetten rastgele yükleyici çalıştırmak iyi bir yöntem değil; işletim sistemi dağıtımından kurulum yapıldığında çok daha iyi doğrulama yöntemleri mevcut. Yine de bunların güvene çok büyük katkı sağladığını düşünmüyorum
    • vet’in amacı kurulum betiğinin kendisinin güvenliğine odaklanmak; özellikle de kurulum betiğinin checksum doğrulamasını atlayacak ya da kötü niyetli bir URL’den ikili dosya indirecek şekilde değiştirilmesini önlemeye yoğunlaşıyor. Bu, zincirin bir bölümünde güçlü koruma sağlıyor ama tüm zinciri kapsamıyor
    • Yükleyiciler genelde yalnızca bir kez çalıştırılıyor; önceki çalıştırmaya göre değişiklikleri göstermenin ne kadar faydalı olduğu konusunda şüpheliyim
    • Yalnızca güvenilir, kriptografik olarak imzalanmış, topluluk tarafından yönetilen paket listeleri üzerinden kurulum yapıyor ve güvenlik geçmişi güçlü yöntemler kullanıyorum. Bence asıl sorun indirme betiklerinin güvenliğinin zor olması değil, macOS gibi bazı topluluklarda bu tür hackvari kurulum yöntemlerinin kültürel olarak kabul görmesi. Güvenilir platformlara yönelik daha güçlü beklentilere ihtiyaç var. İnternetten indirilen shell script’e lint çalıştırmanın güvenliği artırdığını düşünmüyorum
  • Biri kötü niyetli bir betiğe sürekli # shellcheck disable= pragma’ları eklerse ne olacağını merak ediyorum
    • İyi bir nokta. Evet, bunu yapabilirler. vet yalnızca ShellCheck’e güvenmiyor; asıl önemli olan diff. Linter sessiz kalsa bile diff, endişe verici # shellcheck disable= kodu eklemelerini tespit eder. Bu değişikliğin kendisi zaten bir uyarı işareti
  • Bir ironi hissediyorum: 
    # Uzak betiğe körü körüne güvenilen durum:
curl -sSL https://example.com/install.sh | bash
    ardından 
    curl -sL https://getvet.sh | sh
    diye çalıştırılıyor
    • Sanırım o kısmı okumadan geçmişsin. vet’in kilit noktası, bu ironinin kendisinin farkında olması. Kullanıcılara vet’in kurulum betiğini bizzat incelemeleri öneriliyor. vet’in amacı zaten tam olarak bu. install.sh kaynağını doğrudan görebilirsin
  • Bence gerçekten harika bir çözüm. Bunu sık sık düşünüyordum; uv gibi araçlarda da bunu merak etmiştim. Ama çoğu durumda herkes kod yöneticilerine güvendiği için pratik bir uzlaşmayla kullanılıyor
    • uv hakkında ne düşündüğünü merak ediyorum
  • Bu tartışmayı görünce vet için bir sonraki adım olarak özel ortam desteğini düşünmeye başladım. Herkese açık betikleri doğrulamak güzel, ama dahili GitHub repo’larından veya iç sunuculardan dağıtım betikleri çalıştırma ihtiyacı da var. Bunun için vet’e kimlik doğrulama eklenmesi yönünde bir özellik isteği açtım. Yol haritasında .netrc desteği, VET_TOKEN ortam değişkeni ve ileride HashiCorp Vault gibi secret manager entegrasyonları var. İlgileniyorsanız GitHub issue altında görüşlerinizi duymak isterim. Geri bildirim için teşekkürler
  • Sayfada ya da README’de çalışırken nasıl göründüğünü veya bir demo videosunu gösterebilir misiniz diye merak ediyorum. Pager ya da editörle mi açılıyor, ShellCheck uyarıları nasıl gösteriliyor diye soruyorum
    • Haklısın. README şu anda vet’in nasıl çalıştığını anlatıyor ama gerçek kullanım deneyimini iyi göstermiyor. Sayfaya bir demo GIF eklemeyi planlıyorum. Soruna cevap olarak: varsayılan olarak dosyayı pager’da açıyor (less, ya da bat kuruluysa daha iyi vurgulama sunan bir pager), yanlışlıkla değişiklik yapılmasını önlemek için editör açmıyor. ShellCheck bir sorun bulursa bunu terminalde renkli şekilde hemen gösteriyor. Sonrasında incelemeye devam edilip edilmeyeceğini [y/N] biçiminde doğrudan soruyor. Örnek: 
      ==> Running ShellCheck analysis...

In /tmp/tmp.XXXXXX line 7:
echo "Processing file: $filename"
           ^-- SC2086: Double quote to prevent globbing and word splitting.

==> WARNING: ShellCheck found potential issues.
[?] Continue with review despite issues? [y/N]
      Güzel öneri, teşekkürler
  • curl | bash kalıbı gibi otomatik çalışmaması biraz üzücü. Windows’ta kullanıcı bir şey kurmaya çalıştığında dosyayı otomatik tarayan özellikler var
  • Fikir çok iyi. Bu tür güvenlik araçlarında en büyük zorluk, LLM’lerin deterministik olmaması ve kodun üçüncü taraf API’lere gönderilmesinin doğurduğu gizlilik riskleri. vet’in ShellCheck’e dayanmasının nedeni tam da bu. ShellCheck deterministik, kural tabanlı ve tamamen çevrimdışı çalışan bir linter. Aynı girdide her zaman aynı güvenilir çıktıyı veriyor. Daha akıllı analiz için bir gün vet’in hızlı ve yerelde çalışan yapay zekaya yönelmesi gerekebilir diye düşünüyorum. Güzel bir düşünce konusu
  • Gerçekten çok zekice bir fikir. Ek özellik olarak shell script içeriğini bir LLM’e gönderip güvenlik açısından şüpheli kısımları buldurmak da ilginç olabilir
  • Selam HN, vet’in geliştiricisiyim. curl | bash kalıbı beni hep tedirgin etti; betik değiştiğinde diff gösteren, shellcheck çalıştıran ve kullanıcıdan açık izin isteyen bir araca ihtiyaç olduğunu hissettim. Bu yüzden vet’i yaptım. Kurulumda da aynı ilkeleri uyguladım. Kurulum betiğini mutlaka okumanızı öneririm. Geri bildirimlere açığım. Repo: https://github.com/vet-run/vet
    • Bu tür konuları düşünen tek kişinin ben olmamama sevindim. Bunu, saldırı yüzeyinde açık bir nokta olarak görüyorum. nvm’i örnek vermen de hoşuma gitti (geçmişte nvm için de benzer bir konuyu gündeme getirmiştim). Yine de tehdit modeli biraz belirsiz. Bir SSL müdahale saldırganı kötü niyetli betik sunabilecek durumdaysa, gerçek betiğin indirdiği ikili dosyaları da kötü amaçlı olarak değiştirebilecek kadar gelişmiş demektir. Herkesin kriptografik hash doğrulamasını yönetmesi zor olsa da, sonuçta en sağlam yöntem bu gibi görünüyor. 1) uzak girdiyi al 2) commit edilmiş hash ile karşılaştır 3) internet erişimi kesilmiş bir sandbox içinde çalıştır 4) doğrulanmamış hash ile gelen payload’ları engelle
    • “Betik değiştiğinde diff gösterip shellcheck çalıştırmanın” neden gerekli olduğunu soruyorum. ShellCheck’in rolü üzerine düşündün mü, diff’in hangi durumda işe yaradığını varsayıyorsun? “Çalıştırmadan önce açık izin istemek” de yalnızca girinti değiştirilmişse pek işe yaramaz. Küçük shell script’ler hızlıca okunabilir ama büyük yükleyicilerde çeşitli meşru nedenlerle anlaşılması zor kod stilleri kullanılabiliyor. vet’in nasıl bir felsefeyi savunduğunu anlamıyorum. vet’in yaklaşımı bana aslında saldırganların kötü amaçlı yazılım dağıtırken kullandığı kalıplara benziyor (örneğin: wget -qO- https://getvet.sh ile indirildiğinde sunucu text/html dönüyor). Hatta doğrudan install.sh dosyasını almayı önermeyi tercih ederim. Geri bildirim istemene yanıt olarak, “şöyle de yapılabilir” diye bir bash ipucu paylaşıyorum: 
      check () {
  echo "> $BASH_COMMAND" >&2
  echo -n "Allow? (yes/no) " >&2
  select c in yes no
  do
    if [ "$c" = "yes" ]
    then break
    elif [ "$c" = "no" ]
    then return 1
    fi
  done
}

shopt -s extdebug
trap check DEBUG
      Bu yöntem, bash bir şey çalıştırmaya her kalktığında izin istiyor. Uzun betiklerde yorucu olabilir; bu yüzden güvenli gördüğün komutları whitelist’e alabilir ya da “remember” benzeri bir seçenekle özelleştirebilirsin. sudo ile ilgili olarak, kötü amaçlı yazılımlar önce zararsız görünen bir komutta sudo çalıştırıp kimlik bilgilerini önbelleğe alabilir, sonra da hiçbir uyarı vermeden daha sonra yeniden sudo kullanabilir. Bilinmeyen programları çalıştırmadan önce sudo -k ile oturum önbelleğini temizlemek daha güvenli olur
    • Bir sorunu fark edip çözüm üretme çabasını takdir ediyorum ama ShellCheck’in asli amacı virüs/zafiyet taraması değil; bu yüzden vet’in yönünün çok geçerli olacağını sanmıyorum
    • Fikir olarak güzel. vet, kaynak kod geliştiricinin önünde net şekilde durduğunda ve gerçekten okunabildiğinde faydalı çalışacaktır. Ben henüz o seviyede değilim; bu yüzden çoğu kullanıcı tarafında mı, az sayıdaki kullanıcı tarafında mı kaldığımı bilmiyorum diye düşünüyorum