@kodkedisiYan projelerimde bağımlılık zinciri güvenliği: kilit dosyası, kurulum betikleri ve OpenSSF Scorecard ile yaptığım düzen
Gündüz bir şirkete uzaktan backend yazıyorum, akşamları da birkaç küçük yan ürünüm var. Şirkette güvenlik ekibi bağımlılıkları tarıyor, kurallar belli. Yan projelerde ise her şey bana kalmış durumda. Geçen yıl paket depolarında arka arkaya gelen kötü amaçlı paket haberlerinden sonra kendi projelerime baktım ve açıkçası biraz utandım. Bir projede yüzlerce dolaylı bağımlılık vardı ve çoğunun ne iş yaptığını bilmiyordum. Sonra kendime basit bir düzen kurdum, paylaşayım.
Önce temel mantık. Sizin yazdığınız koddan çok daha fazlası başkalarının kodu. Bir paketin yeni sürümü yayımlandığında, eğer sürümü sabitlemediyseniz bir sonraki kurulumda o yeni kod sizin sunucunuzda çalışıyor. Saldırganların bir kısmı tam olarak bunu hedefliyor: popüler bir paketin bakımcı hesabını ele geçirmek ya da popüler bir pakete çok benzeyen adla yeni bir paket yayımlamak.
Yaptıklarım şunlar:
1. Kilit dosyasını her projede depoya ekliyorum ve sunucuda kurulumu kilit dosyasına sadık kalan komutla yapıyorum. Böylece testte çalışan sürüm ile canlıda çalışan sürüm aynı oluyor.
2. Kurulum sırasında otomatik çalışan betikleri varsayılan olarak kapattım. Bazı paket yöneticileri kurulumda paketin kendi betiğini çalıştırıyor; kötü amaçlı paketlerin önemli kısmı tam bu noktada iş görüyor. İhtiyacı olan birkaç paket için tek tek izin veriyorum.
3. Yeni bir bağımlılık eklemeden önce iki dakika ayırıyorum: paketin adı doğru mu, son ne zaman güncellenmiş, kaç bakımcısı var, indirme sayısı makul mü. Harf hatasıyla benzer adlı bir paketi kurmak sandığınızdan kolay.
4. OpenSSF Scorecard'ı kullanmaya başladım. Açık kaynak projeleri otomatik kontrollerle değerlendiren bir araç; her kontrol ondan bir puan ve risk seviyesi veriyor. Bakımın sürüp sürmediği, dal korumasının olup olmadığı, bağımlılıkların sabitlenip sabitlenmediği gibi başlıklara bakıyor. Düzenli taranan projelerin puanlarını web görüntüleyicisinden, depo adresini yazarak görebiliyorsunuz. Puanı düşük diye bir paketi atmıyorum ama kritik bir yere koyacaksam iki kere düşünüyorum.
5. Bağımlılık güncellemelerini toplu ve haftalık yapıyorum. Gelen her güncellemeyi anında birleştirmiyorum; yeni bir sürüm çıktıktan sonra birkaç gün beklemek, kötü amaçlı bir sürüm yakalanıp kaldırılırsa sizi korumuş oluyor.
Bunların hiçbiri mükemmel koruma değil. Ama bir yan proje için harcadığım ek süre haftada yarım saati geçmiyor ve en azından neyin içeri girdiğini biliyorum. Siz yan projelerde nasıl bir düzen kullanıyorsunuz, bağımlılık sayısını azaltmak için bilinçli bir çaba gösteren var mı?
Önce temel mantık. Sizin yazdığınız koddan çok daha fazlası başkalarının kodu. Bir paketin yeni sürümü yayımlandığında, eğer sürümü sabitlemediyseniz bir sonraki kurulumda o yeni kod sizin sunucunuzda çalışıyor. Saldırganların bir kısmı tam olarak bunu hedefliyor: popüler bir paketin bakımcı hesabını ele geçirmek ya da popüler bir pakete çok benzeyen adla yeni bir paket yayımlamak.
Yaptıklarım şunlar:
1. Kilit dosyasını her projede depoya ekliyorum ve sunucuda kurulumu kilit dosyasına sadık kalan komutla yapıyorum. Böylece testte çalışan sürüm ile canlıda çalışan sürüm aynı oluyor.
2. Kurulum sırasında otomatik çalışan betikleri varsayılan olarak kapattım. Bazı paket yöneticileri kurulumda paketin kendi betiğini çalıştırıyor; kötü amaçlı paketlerin önemli kısmı tam bu noktada iş görüyor. İhtiyacı olan birkaç paket için tek tek izin veriyorum.
3. Yeni bir bağımlılık eklemeden önce iki dakika ayırıyorum: paketin adı doğru mu, son ne zaman güncellenmiş, kaç bakımcısı var, indirme sayısı makul mü. Harf hatasıyla benzer adlı bir paketi kurmak sandığınızdan kolay.
4. OpenSSF Scorecard'ı kullanmaya başladım. Açık kaynak projeleri otomatik kontrollerle değerlendiren bir araç; her kontrol ondan bir puan ve risk seviyesi veriyor. Bakımın sürüp sürmediği, dal korumasının olup olmadığı, bağımlılıkların sabitlenip sabitlenmediği gibi başlıklara bakıyor. Düzenli taranan projelerin puanlarını web görüntüleyicisinden, depo adresini yazarak görebiliyorsunuz. Puanı düşük diye bir paketi atmıyorum ama kritik bir yere koyacaksam iki kere düşünüyorum.
5. Bağımlılık güncellemelerini toplu ve haftalık yapıyorum. Gelen her güncellemeyi anında birleştirmiyorum; yeni bir sürüm çıktıktan sonra birkaç gün beklemek, kötü amaçlı bir sürüm yakalanıp kaldırılırsa sizi korumuş oluyor.
Bunların hiçbiri mükemmel koruma değil. Ama bir yan proje için harcadığım ek süre haftada yarım saati geçmiyor ve en azından neyin içeri girdiğini biliyorum. Siz yan projelerde nasıl bir düzen kullanıyorsunuz, bağımlılık sayısını azaltmak için bilinçli bir çaba gösteren var mı?
4 1 yorum
