DevSecOps คืออะไร? หลักการ, กระบวนการทำงาน, และแนวปฏิบัติที่ดีที่สุด

DevSecOps ผสานแนวปฏิบัติด้านความปลอดภัยเข้าไปในขั้นตอนการวางแผนซอฟต์แวร์ การพัฒนา การส่งมอบ และการดำเนินงาน จุดมุ่งหมายไม่ได้เพียงเพิ่มประตูตรวจสอบความปลอดภัยขั้นสุดท้ายให้กับ DevOps แต่เพื่อทำให้ค่าเริ่มต้นที่ปลอดภัย การตอบกลับอย่างรวดเร็ว หลักฐาน และความรับผิดชอบร่วมเป็นส่วนหนึ่งของระบบการส่งมอบ

เครื่องมือเป็นเพียงชั้นหนึ่งเท่านั้น DevSecOps ที่มีประสิทธิภาพยังต้องการข้อกำหนดที่อิงจากภัยคุกคาม ทีมที่ได้รับการฝึกฝน คลังสินค้าซอฟต์แวร์ที่ได้รับการบำรุงรักษา โครงสร้างพื้นฐานการสร้างที่ได้รับการปกป้อง การตรวจสอบตามความเสี่ยง การตอบสนองต่อช่องโหว่ และเมตริกที่เชื่อมโยงกับผลลัพธ์จริง

ประเด็นสำคัญ

• กำหนดข้อกำหนดด้านความปลอดภัยและสมมติฐานภัยคุกคามก่อนการดำเนินการ
• มอบการตอบกลับที่รวดเร็วและนำไปปฏิบัติได้แก่ผู้พัฒนาในเครื่องมือที่พวกเขาใช้อยู่แล้ว
• ปกป้องซอร์สโค้ด, การพึ่งพา, การสร้าง, ผลงาน, ข้อมูลรับรอง และอัตลักษณ์การปรับใช้เป็นห่วงโซ่อุปทานเดียว
• ใช้ระบบอัตโนมัติเพื่อบังคับใช้นโยบายอย่างสม่ำเสมอ พร้อมการตรวจสอบจากผู้เชี่ยวชาญสำหรับความเสี่ยงที่ขึ้นกับบริบท

ย้ายการตรวจสอบไปซ้ายและดำเนินการให้ถูกต้อง

การตรวจสอบการออกแบบตั้งแต่ต้น, การทำโมเดลภัยคุกคาม, มาตรฐานการเขียนโค้ดที่ปลอดภัย, และการทดสอบช่วยลดการทำงานซ้ำที่มีค่าใช้จ่ายสูง สิ่งนี้มักเรียกว่าการย้ายการตรวจสอบไปซ้าย การดำเนินการให้ถูกต้องเสริมด้วยการกำหนดค่าการผลิต, การเก็บข้อมูลการทำงาน, การป้องกันขณะทำงาน, การตอบสนองต่อเหตุการณ์, และการเรียนรู้จากความล้มเหลวจริง

งานด้านความปลอดภัยควรสอดคล้องกับความเสี่ยง บริการตรวจสอบตัวตนที่เปิดให้เข้าถึงจากอินเทอร์เน็ตต้องการการควบคุมที่แตกต่างจากหน้าเว็บภายในที่เป็นแบบคงที่ Cybersecurity ผู้เชี่ยวชาญด้านความปลอดภัยไซเบอร์ช่วยทีมตีความผลการสแกน แทนที่จะทำให้คำเตือนจากสแกนเนอร์ทุกข้อกลายเป็นงานที่มีความสำคัญเท่ากัน

สายการผลิตการส่งมอบที่ปลอดภัย

สายการผลิตทั่วไปจะตรวจสอบการเปลี่ยนแปลงของซอร์สโค้ด, ความลับ, การพึ่งพา, โค้ดโครงสร้างพื้นฐาน, คอนเทนเนอร์, และพฤติกรรมของแอปพลิเคชัน การสร้างควรสามารถทำซ้ำได้เมื่อเป็นไปได้ ผลงานต้องมีลายเซ็น, บันทึกแหล่งที่มาของซอฟต์แวร์, และสภาพแวดล้อมการปรับใช้ต้องแยกจากกันด้วยอัตลักษณ์ที่กำหนดขอบเขต

ประตูอัตโนมัติต้องมีข้อยกเว้นที่บันทึกเป็นเอกสารและวันหมดอายุ การบล็อกตามกฎที่มีเสียงรบกวนทำให้เกิดวิธีแก้ชั่วคราว; การละเลยผลการตรวจพบทำให้เกิดหนี้สินที่ซ่อนอยู่ ปรับนโยบายให้สอดคล้องกับความสามารถในการโจมตี, ความเสี่ยง, มูลค่าทรัพย์สิน, และการบรรเทาที่มีอยู่

การควบคุมห่วงโซ่อุปทานซอฟต์แวร์

รักษาคลังสินค้าของส่วนประกอบโดยตรงและส่วนประกอบที่เป็นผลต่อเนื่อง, ตรวจสอบคำแนะนำ, ยืนยันแหล่งที่มา, กำหนดการพึ่งพาที่สำคัญ, และสร้างบิลรายการซอฟต์แวร์เมื่อจำเป็นต่อความต้องการของลูกค้าหรือการตอบสนอง ปกป้องบริการการสร้างเนื่องจากมันสามารถเปลี่ยนแปลงผลงานทุกชิ้นที่ตามมา

โค้ดจากบุคคลที่สามไม่ได้โอนความรับผิดชอบ ทีมต้องมีกระบวนการประเมิน, อัปเดต, แยกหรือแทนที่การพึ่งพา การดำเนินงาน IT และการพัฒนาควรแบ่งความเป็นเจ้าของสำหรับเวอร์ชันที่สนับสนุนและแพตช์ฉุกเฉิน

คน, หลักฐาน, และการปรับปรุง

ผู้สนับสนุนด้านความปลอดภัยสามารถเชื่อมต่อความเชี่ยวชาญศูนย์กลางกับบริบทของผลิตภัณฑ์ได้ แต่พวกเขาต้องการเวลาและอำนาจ การฝึกอบรมควรใช้เทคโนโลยีจริงขององค์กรและประวัติเหตุการณ์ ผู้บริหารต้องจัดสรรงบประมาณสำหรับการแก้ไขแทนที่จะวัดทีมเพียงความเร็วในการปล่อย

ติดตามระยะเวลานำสำหรับการแก้ไขสำคัญ, การเกิดซ้ำ, ช่องโหว่ที่หลุดรอด, การครอบคลุมของส่วนประกอบที่มีความเสี่ยงสูง, อายุของข้อยกเว้น, ความสมบูรณ์ของการสร้าง, และผลกระทบของเหตุการณ์ การนับผลจากสแกนเนอร์เพียงอย่างเดียวให้รางวัลกับกิจกรรม ไม่ได้ทำให้ซอฟต์แวร์ปลอดภัยขึ้น

การทำโมเดลภัยคุกคามและการออกแบบที่ปลอดภัย

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

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

สำหรับซอฟต์แวร์ที่ใช้ AI ต้องรวมถึงการฉีดคำสั่ง, ผลลัพธ์โมเดลที่ไม่เชื่อถือ, การปนเปื้อนข้อมูล, แหล่งที่มาของโมเดลและชุดข้อมูล, การใช้เครื่องมือที่ไม่ปลอดภัย, การเปิดเผยข้อมูลที่ละเอียดอ่อน, และการทำงานอิสระเกินควร โมเดลเป็นหนึ่งการพึ่งพาภายในพื้นผิวการโจมตีที่ใหญ่กว่า; การอนุญาตของแอปพลิเคชันต้องคงความเป็นอำนาจ

การควบคุมสายการผลิตและหลักฐาน

ปกป้องที่เก็บรหัสต้นทางด้วยการตรวจสอบการเปลี่ยนแปลง, การควบคุมสาขา, คอมมิตที่ลงลายเซ็นเมื่อเหมาะสม, และการเข้าถึงของผู้ดูแลที่ได้รับการตรวจสอบ งานสร้างควรเป็นแบบชั่วคราวหรือเสริมความแข็งแรง, แยกจากข้อมูลรับรองการผลิต, และสามารถดึงการพึ่งพาที่ได้รับการอนุมัติเท่านั้น แยกอำนาจการเปลี่ยนแปลงซอร์สจากอำนาจการปรับใช้

การวิเคราะห์แบบสแตติกตรวจสอบโค้ดโดยไม่ต้องรัน; การทดสอบแบบไดนามิกสังเกตแอปพลิเคชันที่กำลังทำงาน; การวิเคราะห์การประกอบซอฟต์แวร์ติดตามการพึ่งพา; สแกนเนอร์โครงสร้างพื้นฐานและคอนเทนเนอร์ตรวจสอบผลงานการปรับใช้ ผลการตรวจพบควรระบุตำแหน่ง, กฎ, ความรุนแรง, ความมั่นใจ, ความเป็นเจ้าของ, และเส้นทางการแก้ไข การยกเว้นต้องมีเหตุผลและวันหมดอายุ

แหล่งที่มาของผลงานบันทึกว่าซอฟต์แวร์สร้างอย่างไร, ที่ไหน, และจากอินพุตใด ผลลัพธ์ การลงลายเซ็นและการรับรองช่วยให้นโยบายการปรับใช้ตรวจสอบแหล่งที่มาที่คาดหวัง แต่ไม่ได้พิสูจน์ว่าโค้ดปลอดภัย ดังนั้นแหล่งที่มาจึงเป็นส่วนเสริมให้กับการทดสอบ, การตรวจสอบ, และการควบคุมขณะทำงาน

การตอบสนองต่อช่องโหว่และเหตุการณ์

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

สัญญาณความปลอดภัยของการผลิตควรเชื่อมต่อกับความเป็นเจ้าของบริการและระบบอัตโนมัติของเหตุการณ์ รักษาหลักฐาน, หมุนเวียนข้อมูลรับรองที่ถูกคุกคาม, แพตช์หรือบรรเทา, ตรวจสอบการกู้คืน, และค้นหาความอ่อนแอที่เกี่ยวข้อง การดำเนินการหลังเหตุการณ์ควรเปลี่ยนการออกแบบ, การทดสอบ, ค่าเริ่มต้น, และการฝึกอบรม แทนการโทษผู้ที่ทำให้เกิดข้อบกพร่องสุดท้ายเท่านั้น

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

ตัวอย่างการทำงาน: การรักษาความปลอดภัยของเส้นทางการส่งมอบบริการแบบคอนเทนเนอร์

นักพัฒนาจะเริ่มจากเทมเพลตที่ได้รับการอนุมัติของที่เก็บรหัสที่มีการปกป้องสาขา, นโยบายการพึ่งพา, การสแกนความลับ, และอิมเมจฐานที่เล็กที่สุด คำขอรวม (pull request) จะรันการทดสอบ, การวิเคราะห์แบบสแตติก, การตรวจสอบโครงสร้างพื้นฐาน, และการวิเคราะห์การประกอบซอฟต์แวร์ การสร้างเกิดขึ้นในรันเนอร์ที่แยกออก, ผลิตผลงานที่ไม่เปลี่ยนแปลง, ลงลายเซ็น, สร้าง SBOM และการรับรองแหล่งที่มา, และผลักดันไปยังรีจิสทรีที่ควบคุมเท่านั้น ความลับจะถูกฉีดในขณะทำงาน, ไม่ได้คัดลอกเข้าไปในโค้ด, อิมเมจ, หรือบันทึก CI

นโยบายการยอมรับตรวจสอบลายเซ็น, แหล่งที่มา, รีจิสทรีที่อนุญาต, ข้อยกเว้นของช่องโหว่, การตั้งค่าการให้สิทธิ์ขั้นต่ำ, และข้อจำกัดของสภาพแวดล้อมก่อนการปรับใช้ การควบคุมขณะทำงานจำกัดการเข้าถึงเครือข่ายและระบบไฟล์, ในขณะที่การสังเกตเชื่อมโยงการเปลี่ยนแปลงกับพฤติกรรมของบริการ ช่องโหว่สำคัญจะกระตุ้นการประเมินตามการเข้าถึง, ความสามารถในการโจมตี, ความเสี่ยง, และการควบคุมชดเชย ไม่ใช่การหยุดการผลิตอัตโนมัติเจมจากคะแนนสแกนเนอร์เท่านั้น การเปลี่ยนแปลงฉุกเฉินใช้การอนุมัติที่มีเวลาจำกัดและจะได้รับการตรวจสอบภายหลัง

วัดระยะเวลาการแก้ไข, การเปิดเผยที่เป็นช่องโหว่, เหตุการณ์ความลับ, การข้ามนโยบาย, ความสดของการพึ่งพา, การครอบคลุมของผลงานที่ลงลายเซ็น, และเวลารอของนักพัฒนา ทดสอบสายการผลิตต่อการพึ่งพาที่ถูกคุกคาม, ข้อมูลรับรองที่ถูกขโมย, ผลงานที่ถูกดัดแปลง, และสแกนเนอร์ที่ไม่พร้อมใช้งาน DevSecOps จะประสบความสำเร็จเมื่อการส่งมอบที่ปลอดภัยสามารถทำซ้ำได้และเร็วพอที่จะนำไปใช้; ชุดของเครื่องมือบล็อกที่ไม่มีความเป็นเจ้าของ, การทำโมเดลภัยคุกคาม, และการตอบกลับ เพียงย้ายความเสี่ยงไปยังข้อยกเว้นและกระบวนการทำงานเงา

การกำกับดูแลการปล่อยควรกำหนดว่าใครสามารถอนุมัติข้อยกเว้นความเสี่ยง, หลักฐานใดที่จำเป็น, ข้อยกเว้นจะมีอายุเท่าใด, และวิธีการเพิกถอน ควรแยกอัตลักษณ์ของการพัฒนา, การสร้าง, และการผลิตออกจากกัน, หมุนเวียนวัสดุการลงลายเซ็น, และตรวจสอบการเปลี่ยนแปลงที่มีสิทธิพิเศษของสายการผลิต สำรองการกำหนดค่าที่สำคัญและตรวจสอบการกู้คืนของระบบการส่งมอบเอง แผนควบคุม CI/CD ที่ถูกคุกคามสามารถกระจายผลงานที่เป็นอันตรายที่เชื่อถือได้เร็วกว่าการบุกรุกเซิร์ฟเวอร์แบบดั้งเดิม ดังนั้นจึงต้องอยู่ในโมเดลภัยคุกคามและแผนเหตุการณ์

รายการตรวจสอบการนำไปใช้เชิงปฏิบัติ

เปลี่ยนแนวคิดให้เป็นกระบวนการทำงานที่มีขอบเขตและสามารถทดสอบได้: วางแผน → ออกแบบ → เขียนโค้ด → สร้าง → ปรับใช้ → ดำเนินการ กำหนดเจ้าของที่รับผิดชอบ, บันทึกข้อมูลและการพึ่งพา, สร้างฐานข้อมูลพื้นฐานอย่างง่าย, ตั้งเกณฑ์การยอมรับและการหยุด, ทดสอบความล้มเหลวที่เป็นตัวแทน, และกำหนดการเฝ้าระวัง, การย้อนกลับ, และการตรวจสอบก่อนขยายขอบเขต บันทึกเวอร์ชันและสมมติฐานเพื่อให้ทีมอื่นสามารถทำซ้ำผลลัพธ์และเข้าใจการเปลี่ยนแปลง

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

• คน: การเป็นเจ้าของร่วมกับการสนับสนุนจากผู้เชี่ยวชาญ.
• สายการผลิต: การตรวจสอบที่รวดเร็วและผลงานที่ตรวจสอบได้.
• การดำเนินงาน: เฝ้าระวัง, ตอบสนอง, แพตช์, และเรียนรู้.

คำถามที่พบบ่อย

DevSecOps เป็นผลิตภัณฑ์หรือชุดเครื่องมือ?

ไม่ เครื่องมือช่วยสนับสนุนได้ แต่ DevSecOps เป็นแนวทางการดำเนินงานที่เชื่อมโยงคน, กระบวนการ, เทคโนโลยี, หลักฐาน, และความรับผิดชอบตลอดวงจรชีวิตของซอฟต์แวร์

การย้ายการตรวจสอบด้านความปลอดภัยไปซ้ายแทนที่ความปลอดภัยขณะทำงานหรือไม่?

ไม่ การควบคุมการออกแบบและการสร้างช่วยป้องกันปัญหาหลายอย่าง; การเฝ้าระวังการผลิต, การตอบสนอง, การแพตช์, และการกู้คืนยังคงเป็นสิ่งสำคัญ

เอกสารอ้างอิงหลัก

• NIST SP 800-218: Secure Software Development Framework
• NIST NCCoE: DevSecOps Practices
• CISA: Secure by Design