pip install Bir Güven Kararıdır

Kendi yazdığım kodu, kurduğum koddan çok daha dikkatli inceliyorum.

Düşününce bu tuhaf bir alışkanlık.

Bir pull request’i incelemek için yarım saat harcayabilirim, sonra şunu çalıştırırım:

pip install some-package

ve hiç okumadığım bir koda, uygulamamla aynı process ortamına erişim veririm.

AI projeleri bu güven açığını daha da kötüleştiriyor.

Tek bir process’te çok fazla secret var

Tipik bir AI uygulaması aynı anda bunlardan birçoğuna erişebilir:

LLM provider anahtarları
database credential'ları
vector database token'ları
cloud credential'ları
GitHub token'ları
monitoring credential'ları
internal servis URL'leri

Bir bağımlılık environment variable’ları okuyabiliyorsa, “sadece bir LLM kütüphanesi” pek de bir güvenlik sınırı sayılmaz.

LiteLLM supply-chain olayı bunun için faydalı bir hatırlatma oldu. İlginç olan kısım özel olarak LiteLLM değildi. Herhangi bir popüler paket cazip bir hedef haline gelebilir, çünkü tek bir publish yolunu ele geçirmek çok sayıda downstream ortama ulaşabilir.

Bu, bağımlılık güncellemeleri hakkında düşünme şeklimi değiştirdi.

Pinning güvenlik değildir, ama sürprizleri ortadan kaldırır

Önemli olan her şey için, açık uçlu bir upgrade aralığı yerine kesin bir versiyonu tercih ederim.

Pin’lenmiş bir versiyon garanti güvenli olduğu için değil. Değil.

Sadece, bir build paket yayınlandıktan sonra çalıştığı için yarının release’inin production’a girmesini engelliyor.

Ayrıca kritik bir bağımlılığı bir release çıkar çıkmaz güncelleme ihtiyacı hissetmiyorum. “En yeni” ve “en güvenli” farklı özellikler.

Daha küçük bağımlılık ağaçları hakkında akıl yürütmek daha kolay

Bu, kendi projelerimde opsiyonel bağımlılık gruplarına karşı daha agresif olmamın sebeplerinden biri.

Bir API imajının evaluation araçlarına, test framework’lerine ya da ingestion paketlerine ihtiyacı yoksa, onları o imajda istemiyorum.

Bu karar imaj boyutuna yardımcı oluyor, ama aynı zamanda production credential’larıyla çalışan üçüncü parti kod miktarını da azaltıyor.

Artık bir paket eklemeden önce birkaç sıkıcı soru soruyorum:

Buna gerçekten ihtiyacım var mı?
Bakımı yapılıyor mu?
Transitif olarak neyi beraberinde getiriyor?
Bunu zaten bağımlı olduğum bir şeyle yapabilir miyim?

Bu soruların hiçbiri sofistike değil. Ama faydalılar.

Secret’ların da kendi sınırına ihtiyacı var

Private bir repository’i bir secret manager gibi görmüyorum.

Local .env dosyaları Git’in dışında kalır. CI secret’ları CI secret store’unda yaşar. Kubernetes workload’ları credential’ları hard-code edilmiş Python sabitleri yerine Kubernetes mekanizmaları üzerinden alır.

Ajanlar için de izinleri, uygulamanın toplam kapasitesinden daha dar tutmaya çalışıyorum.

Bir tool sadece read erişimine ihtiyaç duyuyorsa, arkasındaki credential’ın “ne olur ne olmaz” diye write erişimine sahip olmasını istemiyorum.

Aynısı yüksek etkili aksiyonlar için de geçerli. E-posta göndermek, veri silmek, shell komutu çalıştırmak ya da altyapıyı değiştirmek, bir LLM bir tool çağırabiliyor diye otomatik hale gelmemeli.

AI destekli geliştirme, başka bir SDK, başka bir provider, başka bir entegrasyon, başka bir ajan eklemeyi çok kolaylaştırıyor.

Bu hız faydalı.

Ama aynı zamanda security review’ün, mimari zaten güven ilişkileriyle dolduktan sonra başlayamayacağı anlamına da geliyor.

Benim için en küçük ama en faydalı zihinsel değişim şu oldu:

pip install bir kurulum değildir. Bir izindir.