ตรวจสอบสิ่งที่เข้าสู่ release

ถามว่าจำเป็นต้องใช้ dependency หรือไม่

Agent อาจเสนอ package ที่ดูเหมือนแก้ปัญหาได้ คำแนะนำเป็นข้อเสนอ ไม่ใช่หลักฐานว่า package มีอยู่หรือเหมาะสม ตรวจสอบ registry ผู้เผยแพร่ ชื่อ package และเวอร์ชันที่แน่นอนก่อนติดตั้ง

สำหรับ CSV export สมมติ runtime อาจมีพฤติกรรมที่ต้องการอยู่แล้ว Package ใหม่ยังอาจเหมาะสม แต่เพิ่มงานบำรุงรักษาและเส้นทางรันโค้ด เปรียบเทียบแรงงานที่ใช้พัฒนากับความรับผิดชอบต่อเนื่องของ dependency

ตรวจทาน license และ runtime ที่รองรับ ตรวจดูกิจกรรมบำรุงรักษาและประกาศความปลอดภัยที่เกี่ยวข้อง ชื่อที่คุ้นเคยอาจหมายถึง package คนละตัวใน registry อื่น การติดตั้งสำเร็จแสดงเพียงว่าติดตั้งเสร็จ

ตรวจดูพฤติกรรมติดตั้งและ build

Dependency รันโค้ดระหว่างติดตั้งหรือ build ได้ จำกัดข้อมูลรับรองและสิทธิ์เครือข่ายในสภาพแวดล้อมเหล่านี้ อย่าเปิดเผย secret ของ production ให้ job ที่ประมวลผล pull request ที่ยังไม่น่าเชื่อถือ

ใช้ lockfile ที่ commit ไว้เมื่อระบบนิเวศรองรับ บังคับให้ build ใช้ตามไฟล์นั้น ตรวจทานการเปลี่ยน lockfile พร้อมการเปลี่ยน source รวมถึง package ทางอ้อมที่ไม่คาดคิด การ pin เวอร์ชันช่วยให้ทำซ้ำได้ แต่ไม่ได้ทำให้เวอร์ชันที่มีช่องโหว่ปลอดภัย

SSDF ของ NIST ครอบคลุมการปกป้องซอฟต์แวร์และแนวปฏิบัติการพัฒนาตลอดวงจรชีวิต ใช้มุมมองที่กว้างขึ้นนี้เมื่อออกแบบสภาพแวดล้อม build อ่าน framework

แยกบัญชีรายการออกจากหลักฐานที่มา

Software bill of materials หรือ SBOM บันทึกคอมโพเนนต์ในซอฟต์แวร์ ช่วยระบุ release ที่ได้รับผลกระทบเมื่อคอมโพเนนต์หนึ่งเป็นประเด็นกังวล แต่ไม่ได้พิสูจน์ด้วยตัวมันเองว่าคอมโพเนนต์ปลอดภัย

Provenance อธิบายว่า artifact ถูกผลิตอย่างไร SLSA กำหนดรูปแบบ provenance สำหรับข้อมูลเกี่ยวกับ build และ input ของมัน การตรวจสอบต้องเชื่อมข้อมูลนี้กับผู้ผลิตที่เชื่อถือได้และ artifact ที่ตั้งใจใช้ ไฟล์ที่ชื่อ “provenance” อย่างเดียวไม่เพียงพอ ดู SLSA provenance

สำหรับบริการ export ให้บันทึกลำดับหลักฐานที่ตรวจดูได้

1. Commit ที่ตรวจทานแล้วระบุ source ที่ยอมรับ
2. Build ระบุ input และสภาพแวดล้อมรันงาน
3. Artifact มีค่า digest ที่คงที่
4. การตรวจสอบระบุ artifact หรือ source ที่ตรวจ
5. Deployment บันทึก artifact ที่นำไปวางในสภาพแวดล้อมเป้าหมาย

หลีกเลี่ยงการ build ใหม่ด้วยวิธีต่างไปหลังอนุมัติ โดยไม่มีกระบวนการตรวจสอบที่กำหนดไว้ Tag ที่เปลี่ยนค่าได้ เช่น latest อาจอ้างถึง image อื่นในภายหลัง

ตัดสินใจว่าข้อค้นพบหมายถึงอะไร

ข้อค้นพบช่องโหว่ต้องมีบริบท ได้แก่ เวอร์ชันที่ได้รับผลกระทบ พฤติกรรมที่รันไปถึงได้ การเปิดรับภัย วิธีแก้ที่มี และผลกระทบ บันทึกหลักฐานรองรับข้อยกเว้นชั่วคราวทุกข้อ กำหนดผู้รับผิดชอบ วันหมดอายุ และเงื่อนไขให้ทบทวน

อย่าปิด scanner ทั้งตัวเพียงเพราะข้อค้นพบหนึ่งไม่เกี่ยวข้อง อย่าอ้างว่าไม่พบปัญหาเมื่อการสแกนไม่สำเร็จ การหมดเวลา package ที่ไม่รองรับ หรือแหล่งประกาศช่องโหว่ที่เข้าถึงไม่ได้คือหลักฐานที่ขาด

สุดท้าย วางแผนอัปเดตหลังออก release ประกาศใหม่อาจกระทบ artifact ที่เพิ่งยอมรับเมื่อวาน ผู้รับผิดชอบบริการต้องมีบัญชีรายการ กระบวนการตอบสนอง และกำลังที่จะสร้าง release ที่แก้ไขแล้ว

เรียนต่อเรื่อง การจัดการช่องโหว่อย่างต่อเนื่อง เพื่อเชื่อมการสแกนซ้ำกับการแก้ไข production ที่ตรวจสอบแล้ว