Her paket yöneticisinin (npm, Yarn, Cargo, Bundler vb.) kendine özgü bir kilit dosyası formatı (package-lock.json, yarn.lock, Cargo.lock, Gemfile.lock gibi) bulunmaktadır. Bu dosyalar, hangi paketlerin, hangi sürümlerle, hangi sağlama toplamlarıyla ve nereden kurulduğuna dair benzer bilgileri kaydeder. Temelinde, bu kilit dosyaları zaten birer Yazılım Malzeme Listesi (SBOM - Software Bill of Materials) işlevi görmektedir, ancak her biri kendi özel formatında.
Güvenlik dünyası, yazılım bileşenlerini tanımlamak için CycloneDX ve SPDX gibi standartlaştırılmış SBOM formatlarını teşvik ederken, açık kaynak projelerindeki benimseme henüz düşük seviyededir. Ancak AB'nin Siber Dayanıklılık Yasası gibi düzenlemeler, tedarikçileri SBOM sağlamaya itecek ve bu baskı yukarı yönlü akacaktır. Mevcut iş akışı genellikle bir kilit dosyasından (örneğin Syft veya Trivy gibi araçlarla) bir SBOM oluşturmayı içerir ki bu dönüştürme işlemi bazen bilgi kaybına yol açabilir.
Peki ya bu ara adımı ortadan kaldırıp, paket yöneticileri doğrudan SBOM'ları kendi kilit dosyası formatları olarak yazsaydı? Makale, bunun büyük ölçüde mümkün olduğunu, ancak bazı zorlukları olduğunu belirtiyor. Kilit dosyaları genellikle paket kimliği (ad, sürüm, kaynak), bütünlük (sağlama toplamları), bağımlılıklar, kapsam (geliştirme veya üretim bağımlılığı) ve meta veriler (araç/çalışma zamanı sürümleri) gibi bilgileri içerir. Bu bilgiler, standart bir SBOM'un gerektirdiği temel bileşenlerdir ve mevcut kilit dosyalarının büyük çoğunluğu bu verileri zaten barındırmaktadır.
Paket yöneticilerinin kilit dosyalarını doğrudan standart SBOM formatlarında üretmesi, yazılım tedarik zinciri güvenliğini artırarak bilgi kaybını önleyebilir ve uyumluluk süreçlerini basitleştirebilir.