Secure Build รับประกันอะไร
Secure Build คือชุดฟีเจอร์ Build Security ที่ตรวจสิ่งที่คุณบิลด์ก่อนที่ Loha จะถือว่าพร้อม release หน้านี้ระบุเฉพาะสิ่งที่แพลตฟอร์มบังคับใช้จริง และบอก ตรง ๆ ว่าขอบเขตสิ้นสุดตรงไหน แต่ละฟีเจอร์เปิดใช้เป็นราย workspace สอบถามผู้ติดต่อของ Loha ได้ว่า workspace ของคุณเปิดฟีเจอร์ใดไว้บ้าง
Loha ทำอะไรกับแต่ละบิลด์
| ขั้นตอน | สิ่งที่เกิดขึ้น | รายละเอียด |
|---|---|---|
| สแกน | Loha สแกนซอร์สโค้ดและอิมเมจที่บิลด์แล้วเอง ใน job ของ Loha นอก pipeline ของคุณ ผลสแกนเก็บเป็นหลักฐานของบิลด์นั้น | Build Security |
| ตัดสิน | นโยบายของ workspace (Off, Observe หรือ Enforce) กำหนดว่าผลสแกนที่ถึงหรือเกินเกณฑ์จะมีผลกับบิลด์อย่างไร | Build Security |
| ติดตาม | ปัญหาเดียวกันที่พบในหลายบิลด์นับเป็นปัญหาความปลอดภัยเดียว มีสถานะ ผู้รับผิดชอบ และกำหนดแก้ไข | ปัญหาความปลอดภัย |
| ยกเว้น | ผลสแกนที่ทราบอยู่แล้วผ่านด่านได้ชั่วคราว โดยต้องมีเหตุผลและผู้อนุมัติอีกคน | ข้อยกเว้นด้านความปลอดภัย |
| ลงลายมือชื่อ | อิมเมจที่ผ่านด่านในโหมด Enforce จะถูกลงลายมือชื่อด้วยคีย์ของ workspace พร้อมแนบ SLSA provenance และ SBOM ไว้ใน registry ของคุณ | การลงลายมือชื่ออิมเมจ |
| แก้ไข | Loha เปิด pull request แก้ dependency ของ npm หรือ pnpm ที่มีช่องโหว่ หรือ pin digest ของ base image ใหม่ได้ | Pull request แก้ไขช่องโหว่ |
| เฝ้าดู push | ทุกการ push ไปยัง repository ที่เชื่อมต่อจะถูกสแกนหา secret และได้ check loha/secret-scan | สแกน secret ตอน push |
Loha รับประกันอะไร
บิลด์และ release (Enforce)
- บิลด์ที่ไม่ผ่านนโยบายจะถูกบันทึกว่าล้มเหลว ไม่มี Release และ Loha Delivery จะไม่นำไป deploy ทั้งนี้ Delivery ตรวจนโยบายที่ใช้อยู่ซ้ำก่อน rollout ทุกครั้ง
- บน branch ที่ป้องกันไว้ ระบบจะปฏิเสธ pipeline ที่ใช้ deploy task ของ Loha ให้ deploy ผ่าน Loha Delivery แทน
- credential สำหรับ deploy ของ Loha เอง (SSH key ของ target, token ของ GitOps connection) จะไม่ถูกเปิดให้โค้ดใน pipeline ของคุณเข้าถึง มีเทสต์อัตโนมัติคุมเรื่องนี้
- บน branch ที่นโยบายป้องกันไว้ บิลด์ของ commit ที่มีปัญหา secret เปิดค้างอยู่ จะถูกปฏิเสธก่อนเริ่มทำงาน พร้อมลิงก์ไปยังปัญหานั้น ข้อยกเว้นเดียวคือบิลด์ที่เริ่ม จากการ push ครั้งเดียวกับที่ทำให้ secret รั่ว เพราะผลสแกนมาถึงหลังจากวางแผน บิลด์นั้นไปแล้ว
คนและการอนุมัติ
- ข้อยกเว้นทุกรายการต้องมีเหตุผล วันหมดอายุ และผู้อนุมัติที่ไม่ใช่คนขอ ข้อยกเว้นแบบข้ามบิลด์มีอายุไม่เกิน 30 วัน สิ้นสุดทันทีเมื่อปัญหาถูกแก้ และไม่ครอบคลุม secret
- การยอมรับความเสี่ยงของปัญหา CRITICAL หรือการคัดกรอง secret ใด ๆ ต้องใช้ ผู้ดูแลระบบคนที่สอง การผ่อนนโยบาย Enforce ก็ต้องใช้ผู้ดูแลระบบคนที่สองเช่นกัน
- คำขอ การอนุมัติ และการเพิกถอนข้อยกเว้นทุกครั้งถูกบันทึกใน audit log ของ workspace และการคัดกรองทุกครั้งถูกบันทึกในประวัติของปัญหา
ปัญหาความปลอดภัย
- ปัญหาจะถูกปิดเป็น "แก้แล้ว" ได้ก็ต่อเมื่อการสแกน branch ที่ติดตามเสร็จสมบูรณ์ และครอบคลุมผลสแกนประเภทนั้นเท่านั้น การสแกนที่ล้มเหลวหรือไม่ครบจะไม่ปิดปัญหา
- ปัญหายังอยู่แม้รายงานการสแกนที่เป็นต้นทางจะหมดอายุ และจะถูกลบเมื่อลบ workspace
- ข้อความทางอีเมลและ Teams ระบุ CVE หรือกฎ แพ็กเกจ และระดับความรุนแรง ไม่มีเนื้อหาไฟล์หรือค่า secret
อิมเมจ
- อิมเมจที่ด่านบล็อกจะไม่ถูกลงลายมือชื่อเลย
- ใครก็ตามที่มี public key ของ workspace ตรวจลายมือชื่อและ provenance ได้ด้วย
cosignมาตรฐาน โดยไม่ต้องพึ่ง Loha - private key สำหรับลงลายมือชื่อถูกเก็บแบบเข้ารหัส และใช้เฉพาะใน job ลงลายมือชื่อ ไม่มีการแสดงหรือให้ดาวน์โหลด
Pull request แก้ไขช่องโหว่
- Loha ไม่ commit ลง default branch ไม่ force-push และไม่ merge แทนคุณ
- ไม่อัปเกรด dependency ข้าม major version
- lockfile ถูกสร้างใหม่โดยปิด install script ใน job ที่ไม่มี credential ของ Git
Loha ไม่รับประกันอะไร
- ผลสแกนที่สะอาดไม่ได้พิสูจน์ว่าไม่มีช่องโหว่ หมายความเพียงว่าเครื่องมือสแกน ไม่พบอะไรที่ถึงหรือเกินเกณฑ์ ตามข้อมูลช่องโหว่ที่มีในขณะนั้น
- Observe ไม่บล็อกและไม่ลงลายมือชื่อ มีเพียง Enforce ที่เปลี่ยนผลของบิลด์
- Enforce ตัดสินหลังจาก step ใน pipeline ทำงานเสร็จแล้ว จึงหยุด step
ไม่ให้ติดต่อระบบภายนอกด้วย credential ที่คุณใส่เองไม่ได้ และไม่ได้ระงับการ push
image ถ้า target ดึง tag ที่เปลี่ยนได้ เช่น
:latestก็ยังอาจได้ image ที่ถูกบล็อกไป - Loha ไม่ได้หยุด cluster ไม่ให้รันอิมเมจที่ไม่มีลายมือชื่อ ให้ใช้ admission controller กับ public key ของ workspace แทน อิมเมจที่ push ไปยัง registry ที่ Loha ไม่ได้สแกน หรือไม่มี registry credential ใน Loha จะไม่ถูกลงลายมือชื่อ
- การสแกน secret ไม่ได้ปฏิเสธการ push สแกนเฉพาะ commit ล่าสุดของแต่ละ push และไม่ได้หมุนเวียนหรือเพิ กถอน secret ให้
- Pull request แก้ไขช่องโหว่รองรับเฉพาะ npm, pnpm และ base image ใน Dockerfile ไม่รองรับ npm registry ส่วนตัวและการอัปเกรดข้าม major version
สิ่งที่ยังเป็นหน้าที่ของคุณ
- Deploy ผ่าน Loha Delivery หรือด้วย digest ของอิมเมจ หากพึ่ง Enforce อย่าเก็บ credential สำหรับ deploy ไว้เป็น secret ของ pipeline
- หมุนเวียน secret ที่รั่วก่อนเสมอ การลบออกจากโค้ดไม่ได้ทำให้การรั่วหายไป
- แก้ปัญหาให้ทันกำหนด ค่าเริ่มต้นคือ CRITICAL 7 วัน, HIGH 30 วัน และ MEDIUM 90 วัน
- ตรวจและ merge pull request แก้ไขช่องโหว่ เหมือนการเปลี่ยนแปลงอื่น ๆ
- บังคับตรวจลายมือชื่อในที่ที่อิมเมจรันอยู่ หากต้องการให้ cluster รันเฉพาะ อิมเมจที่มีลายมือชื่อ