Verifikasi komponen yang masuk ke rilis

Tanyakan apakah dependensi diperlukan

Agen dapat menyarankan paket yang tampaknya menyelesaikan masalah. Saran tersebut merupakan usulan, bukan bukti bahwa paket ada atau sesuai. Verifikasi registry, penerbit, nama paket, dan versi yang tepat sebelum instalasi.

Untuk ekspor CSV fiktif, runtime mungkin sudah menyediakan perilaku yang diperlukan. Paket baru tetap dapat sesuai, tetapi menambah pemeliharaan dan jalur eksekusi. Bandingkan upaya implementasi dengan tanggung jawab dependensi yang berkelanjutan.

Tinjau lisensi dan runtime yang didukung. Periksa aktivitas pemeliharaan dan advisori yang relevan. Nama yang dikenal dapat merujuk pada paket berbeda di registry lain. Instalasi yang berhasil hanya menunjukkan bahwa instalasi selesai.

Periksa perilaku instalasi dan build

Dependensi dapat menjalankan kode selama instalasi atau build. Batasi kredensial dan akses jaringan di lingkungan ini. Jangan membuka secret produksi kepada job yang memproses pull request tidak tepercaya.

Gunakan lockfile yang masuk ke commit jika ekosistem mendukungnya. Wajibkan build mengikuti file tersebut. Tinjau perubahan lockfile bersama perubahan kode sumber, termasuk paket transitif yang tidak diharapkan. Penguncian versi meningkatkan reproduktibilitas, tetapi tidak membuat versi rentan menjadi aman.

SSDF NIST mencakup perlindungan perangkat lunak dan praktik pengembangan sepanjang siklus hidup. Gunakan perspektif lebih luas itu saat merancang lingkungan build. Baca kerangkanya.

Bedakan inventaris dari provenance

Software bill of materials, atau SBOM, mencatat komponen dalam perangkat lunak. SBOM membantu mengidentifikasi rilis terdampak ketika suatu komponen menjadi perhatian. SBOM tidak secara independen membuktikan bahwa komponen aman.

Provenance menjelaskan cara artefak dihasilkan. SLSA menentukan format provenance untuk informasi tentang build dan inputnya. Verifikasi harus menghubungkan informasi tersebut dengan pembuat yang tepercaya dan artefak yang akan digunakan. File bernama “provenance” tidak cukup. Provenance SLSA.

Untuk layanan ekspor, catat rantai yang dapat diperiksa:

1. Commit yang ditinjau mengidentifikasi kode sumber yang diterima.
2. Build mengidentifikasi input dan lingkungan eksekusinya.
3. Artefak memiliki digest yang stabil.
4. Pemeriksaan mengidentifikasi artefak atau kode sumber yang diperiksanya.
5. Deployment mencatat artefak yang ditempatkan dalam lingkungan target.

Hindari melakukan build ulang dengan cara berbeda setelah persetujuan tanpa proses verifikasi yang ditentukan. Tag yang dapat berubah seperti latest dapat merujuk pada image berbeda di kemudian hari.

Tentukan makna temuan

Temuan kerentanan memerlukan konteks: versi terdampak, apakah perilaku yang rentan dapat dijalankan, paparan, perbaikan yang tersedia, dan dampak. Catat bukti yang mendasari setiap pengecualian sementara. Tetapkan penanggung jawab, masa berlaku, dan pemicu peninjauan.

Jangan menonaktifkan seluruh pemindai karena satu temuan tidak berlaku. Jangan mengklaim hasil bersih ketika pemindaian gagal diselesaikan. Timeout, paket yang tidak didukung, atau feed advisori yang tidak tersedia berarti ada bukti yang belum tersedia.

Terakhir, rencanakan pembaruan setelah rilis. Advisori baru dapat memengaruhi artefak yang diterima kemarin. Penanggung jawab layanan memerlukan inventaris, proses respons, dan kapasitas untuk menghasilkan rilis yang diperbaiki.

Lanjutkan ke pengelolaan kerentanan berkelanjutan untuk menghubungkan pemindaian berulang dengan perbaikan produksi yang terverifikasi.