Software Bill of Materials (SBOM) คืออะไร และเหตุใดจึงมีความสำคัญ?

Software Bill of Materials (SBOM) คือรายการบัญชีแจกแจงอย่างเป็นทางการในรูปแบบที่เครื่องคอมพิวเตอร์สามารถอ่านได้ (machine-readable) ซึ่งระบุรายละเอียดทุกส่วนประกอบ ไลบรารีของบุคคลที่สาม (third-party library) ดีเพนเดนซีแบบสืบทอด (transitive dependency) ตลอดจนองค์ประกอบข้อมูลเมทาดาตาที่ประกอบขึ้นเป็นแอปพลิเคชันซอฟต์แวร์ เมื่อวิศวกรรมซอฟต์แวร์ยุคใหม่เปลี่ยนผ่านไปสู่สถาปัตยกรรมแบบแยกส่วนประกอบได้ (composable architecture) SBOM จึงทำหน้าที่เป็นรากฐานสำคัญในการสร้างการมองเห็นห่วงโซ่อุปทานขององค์กร การกำกับดูแลความเสี่ยง และการปฏิบัติตามข้อกำหนดและกฎระเบียบ

การทำความเข้าใจว่า Software Bill of Materials (SBOM) คืออะไร และเหตุใดจึงมีความสำคัญ ได้กลายมาเป็นสิ่งจำเป็นเชิงปฏิบัติการสำหรับประธานเจ้าหน้าที่ฝ่ายความมั่นคงปลอดภัยสารสนเทศ (CISO) หัวหน้าทีมวิศวกรรม และเจ้าหน้าที่บริหารความเสี่ยงระดับองค์กร แอปพลิเคชันร่วมสมัยแทบไม่ได้ประกอบด้วยโค้ดกรรมสิทธิ์เฉพาะ (proprietary code) เพียงอย่างเดียวอีกต่อไป ทว่ารหัสต้นฉบับ (codebase) ของซอฟต์แวร์สมัยใหม่มากถึง 90% กลับถูกประกอบขึ้นจากแพ็กเกจโอเพนซอร์ส เฟรมเวิร์กของบุคคลที่สาม และดีเพนเดนซีต้นน้ำ คู่มือฉบับสมบูรณ์นี้จะแจกแจงรายละเอียดโครงสร้างทางเทคนิคของ SBOM วิเคราะห์เหตุผลที่ความโปร่งใสในห่วงโซ่อุปทานซอฟต์แวร์เป็นสิ่งที่ไม่สามารถต่อรองได้ในโครงสร้างพื้นฐานยุคปัจจุบัน แยกแยะข้อบังคับทางกฎหมายระดับสากล และวางกรอบการทำงานที่นำไปปฏิบัติได้จริงสำหรับการสร้าง การจัดการ และการนำ SBOM ไปใช้งานจริงตลอดไปป์ไลน์การรวมโค้ดและการส่งมอบอย่างต่อเนื่อง (CI/CD)

ทำความเข้าใจ Software Bill of Materials (SBOM)

โดยแก่นแท้แล้ว Software Bill of Materials (SBOM) ทำหน้าที่เป็นรายการสำแดง (manifest) แบบซ้อนทับที่เชื่อถือได้ขององค์ประกอบย่อยต่างๆ ภายในผลงานซอฟต์แวร์ที่ส่งมอบ เช่นเดียวกับรายการแจกแจงวัสดุ (Bill of Materials) ในภาคการผลิตเชิงกายภาพที่ระบุรายละเอียดของสกรู วัตถุดิบ และชิ้นส่วนประกอบย่อยทุกชิ้นที่จำเป็นต่อการผลิตชิ้นงานทางกายภาพ SBOM จะแจกแจงรายการสินทรัพย์ซอฟต์แวร์ที่ประกอบกันเป็นไบนารีของแอปพลิเคชัน อิมเมจคอนเทนเนอร์ บิลด์เฟิร์มแวร์ หรือแพลตฟอร์มซอฟต์แวร์แบบบริการ (SaaS)

ในการจัดซื้อจัดจ้างด้านไอทีและการพัฒนาภายในองค์กรแบบดั้งเดิม ในอดีตแอปพลิเคชันมักถูกปฏิบัติเหมือนเป็นกล่องดำแบบโมโนลิทิก (monolithic black box) การประเมินความปลอดภัยมุ่งเน้นเกือบทั้งหมดไปที่การป้องกันแนวขอบเขต (perimeter defense) การทดสอบความมั่นคงปลอดภัยของแอปพลิเคชันแบบสถิต (SAST) ของโค้ดกรรมสิทธิ์เฉพาะ และการทดสอบการเจาะระบบแบบไดนามิกเป็นระยะ อย่างไรก็ตาม เมื่อวิศวกรรมซอฟต์แวร์พัฒนาไปสู่แนวทางปฏิบัติของการรวมโค้ดและการส่งมอบอย่างต่อเนื่อง (CI/CD) แบบอัตโนมัติ การนำโค้ดกลับมาใช้ใหม่ก็เพิ่มขึ้นอย่างรวดเร็ว การพัฒนาในปัจจุบันพึ่งพาแหล่งเก็บแพ็กเกจ (package registry) เป็นอย่างมาก เช่น npm, PyPI, Maven Central, RubyGems และ NuGet แม้ว่าระบบนิเวศนี้จะช่วยเร่งความเร็วในการพัฒนาฟีเจอร์ แต่ก็ก่อให้เกิดโครงข่ายดีเพนเดนซีย่อยที่ซ้อนทับกันอย่างซับซ้อนและคลุมเครือ

SBOM ขจัดความคลุมเครือนี้ด้วยการบันทึกชื่อส่วนประกอบ สตริงเวอร์ชัน ค่าแฮชของไฟล์ที่ได้รับการตรวจสอบยืนยันความถูกต้องด้วยการเข้ารหัส ตัวระบุเฉพาะ เช่น Package URL (purl) และ Common Platform Enumeration (CPE) ข้อมูลผู้จัดหา ตลอดจนข้อมูลสัญญาอนุญาต (licensing data) อย่างเป็นระบบ เมื่อสร้างขึ้นอย่างถูกต้องแม่นยำ SBOM จะให้ข้อมูลแหล่งกำเนิด (provenance) ที่เครื่องคอมพิวเตอร์สามารถอ่านได้ ซึ่งช่วยให้ทั้งผู้ปฏิบัติงานที่เป็นมนุษย์และเครื่องมือสแกนความเสี่ยงอัตโนมัติสามารถตรวจสอบได้ว่าชิ้นงานซอฟต์แวร์ (software artifact) เฉพาะรายการนั้นๆ มีโค้ดที่มีช่องโหว่ มุ่งร้าย หรือไม่ปฏิบัติตามข้อกำหนดทางกฎหมายหรือไม่

"รายการส่วนผสม" ของแอปพลิเคชันสมัยใหม่

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

ในระบบซอฟต์แวร์ ช่องโหว่ด้านความมั่นคงปลอดภัย เช่น ข้อบกพร่องร้ายแรงระดับการรันโค้ดจากระยะไกล (RCE) ในไลบรารีการแยกวิเคราะห์ระดับต่ำ (low-level parsing library) ถือเป็นอันตรายต่อห่วงโซ่อุปทานในลักษณะเดียวกัน หากไม่มี SBOM การจะระบุว่าไลบรารีดังกล่าวมีอยู่ลึกภายในสแต็กซอฟต์แวร์ขององค์กรหรือไม่นั้น จำเป็นต้องค้นหารหัสต้นฉบับด้วยตนเอง ทำวิศวกรรมย้อนกลับแบบเจาะลึกกับไบนารีที่คอมไพล์แล้ว หรือรอการเปิดเผยข้อมูลจากผู้จำหน่าย แต่ SBOM จะเปลี่ยนการตรวจสอบเชิงรับนี้ให้กลายเป็นการสอบถามฐานข้อมูลในทันที ด้วยการตรวจสอบรายการสำแดงที่มีโครงสร้าง องค์กรสามารถยืนยันได้ภายในไม่กี่วินาทีว่าเวอร์ชันของไลบรารีที่ได้รับผลกระทบถูกฝังอยู่ในสภาพแวดล้อมการทำงานจริง (production) หรือไม่

ยิ่งไปกว่านั้น SBOM ยังบันทึกความสัมพันธ์ตามลำดับชั้น ดีเพนเดนซีของซอฟต์แวร์มักไม่ค่อยอยู่แยกจากกันโดยลำพัง ดีเพนเดนซีโดยตรงมักนำเข้ามาซึ่งดีเพนเดนซีแบบสืบทอด (ทางอ้อม) อีกหลายสิบรายการ นักพัฒนาอาจนำเข้าไลบรารีเพียงตัวเดียวเพื่อจัดการกับคำขอ HTTP โดยไม่รู้ว่าไลบรารีนี้จะดึงแพ็กเกจตัวช่วยอื่นอีก 12 รายการเข้ามาด้วย ซึ่งแพ็กเกจเหล่านั้นก็ดึงตัวจัดรูปแบบข้อมูลรุ่นเก่าอีกหลายตัวตามมา SBOM จะบันทึกแผนผังความสัมพันธ์ระหว่างแม่และลูก (parent-child relationship tree) ที่สมบูรณ์นี้ เพื่อให้มั่นใจว่าจะไม่มีส่วนประกอบย่อยใดรอดพ้นจากการตรวจสอบ

ดีเพนเดนซีแบบสแตติกและไดนามิกในซอฟต์แวร์

ข้อแตกต่างทางเทคนิคที่สำคัญในสถาปัตยกรรม SBOM คือความแตกต่างในการทำงานระหว่างดีเพนเดนซีแบบสแตติก (Static Dependencies) และแบบไดนามิก (Dynamic Dependencies) การติดตามทั้งสองประเภทอย่างแม่นยำมีความจำเป็นอย่างยิ่งต่อการวิเคราะห์ความปลอดภัยอย่างครอบคลุมและการจัดการความเสี่ยงในการปฏิบัติงาน

ดีเพนเดนซีแบบสแตติกคือไลบรารีและโมดูลที่ถูกคอมไพล์หรือแพ็กรวมเข้ากับอาร์ทิแฟกต์ขั้นสุดท้ายที่นำไปแจกจ่ายโดยตรง ในภาษาอย่าง Go, Rust หรือ C/C++ ที่ลิงก์แบบสแตติก ทูลเชนของคอมไพเลอร์จะรวมฟังก์ชันภายนอกเข้าไว้ในไบนารีที่รันได้โดยตรง ในสภาพแวดล้อมแบบคอนเทนเนอร์ (เช่น อิมเมจ Docker หรือ OCI) แพ็กเกจระบบปฏิบัติการพื้นฐาน ไลบรารีที่ใช้ร่วมกัน (https://example.com/page-aหรือhttps://example.com/page-bไฟล์) ตลอดจนยูทิลิตีระบบที่ติดตั้งในระหว่างขั้นตอนการบิลด์คอนเทนเนอร์ ล้วนเป็นส่วนประกอบแบบสแตติกของสภาพแวดล้อมนั้น SBOM ที่สร้างขึ้น ณ เวลาบิลด์จะต้องเก็บข้อมูลส่วนประกอบในระดับคอมไพล์ไทม์และเลเยอร์ของอิมเมจเหล่านี้ เพื่อรับประกันความสามารถในการตรวจสอบย้อนกลับได้อย่างสมบูรณ์

ในทางกลับกัน ดีเพนเดนซีแบบไดนามิกจะถูกค้นหาและโหลดขึ้นมาขณะรันไทม์ (Runtime) ซึ่งรวมถึงไลบรารีระบบที่ใช้ร่วมกันซึ่งถูกลิงก์แบบไดนามิกโดยระบบปฏิบัติการของโฮสต์ ปลั๊กอินเฉพาะสำหรับสภาพแวดล้อมนั้นๆ หรือโมดูลภายนอกที่ดึงผ่านเครือข่ายระหว่างการเริ่มต้นการทำงานของแอปพลิเคชัน (Bootstrap) ในขณะที่เครื่องมือวิเคราะห์แบบสแตติกจะตรวจสอบที่เก็บซอร์สโค้ดหรือไปป์ไลน์การบิลด์ เครื่องมือวิเคราะห์แบบไดนามิกจะเฝ้าติดตามโพรเซสที่กำลังทำงานอยู่เพื่อตรวจหาส่วนประกอบที่ถูกโหลดขึ้นมาระหว่างรันไทม์ กลยุทธ์ SBOM ที่ครอบคลุมจึงต้องรักษาไฟล์กำกับ (Manifest) พื้นฐานจากการบิลด์ ควบคู่ไปกับการตรวจสอบความถูกต้องของดีเพนเดนซีระหว่างรันไทม์ เพื่อให้มั่นใจว่าจะไม่มีแพ็กเกจที่ถูกดึงเข้ามาใหม่นำพาช่องโหว่และภัยคุกคามทั่วไป (CVEs) ที่ไม่ผ่านการตรวจสอบเข้ามา

เวกเตอร์ภัยคุกคามที่เพิ่มขึ้น: ทำไม SBOM จึงมีความสำคัญอย่างยิ่งในปัจจุบัน

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

ด้วยการแทรกแซงไลบรารีโอเพนซอร์ส เฟรมเวิร์กซอฟต์แวร์ หรือทูลเชนการรวมโค้ดอย่างต่อเนื่อง (Continuous Integration) ที่มีการใช้งานอย่างแพร่หลายเพียงแห่งเดียว ผู้โจมตีสามารถกระจายเพย์โหลดที่เป็นอันตรายหรือสร้างช่องโหว่ซีโร่เดย์ (Zero-day) ไปยังสภาพแวดล้อมระดับองค์กรปลายน้ำหลายพันแห่งได้พร้อมกันอย่างแนบเนียน ความไม่สมมาตรขั้นพื้นฐานของการโจมตีห่วงโซ่อุปทานทำให้การโจมตีนี้มีประสิทธิภาพสูงมากสำหรับผู้ไม่ประสงค์ดี และสร้างความเสียหายร้ายแรงต่อองค์กรที่ไม่มีการเตรียมพร้อม

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

ความเป็นจริงของการโจมตีห่วงโซ่อุปทานซอฟต์แวร์

การบุกรุกห่วงโซ่อุปทานซอฟต์แวร์มักเกิดขึ้นใน 3 รูปแบบหลัก ได้แก่ การวางยาซอร์สโค้ด (Source Code Poisoning), ความสับสนของดีเพนเดนซี/การพิมพ์ชื่อผิดโดยเจตนา (Dependency Confusion / Typosquatting) หรือสภาพแวดล้อมการบิลด์ถูกบุกรุก ในกรณีของการวางยาซอร์สโค้ด ผู้โจมตีจะเข้าถึงสิทธิ์การคอมมิต (Commit) ของที่เก็บซอร์สโค้ดโอเพนซอร์สที่ถูกต้องโดยไม่ได้รับอนุญาต หรือขโมยข้อมูลประจำตัวของผู้ดูแล จากนั้นจึงเผยแพร่เวอร์ชันที่มีการฝังประตูหลัง (Backdoor) ไปยังตัวจัดการแพ็กเกจสาธารณะ ส่งผลให้ไปป์ไลน์การบิลด์อัตโนมัติที่ปลายน้ำดึงการอัปเดตที่เป็นอันตรายนั้นไปใช้งานทันที เว้นแต่จะมีการบังคับใช้การตรวจสอบแฮชเข้ารหัส (Cryptographic Hashing) และการล็อกเวอร์ชันดีเพนเดนซี (Dependency Pinning) อย่างเข้มงวด

Dependency Confusion เกิดขึ้นเมื่อตัวจัดการแพ็กเกจแบบอัตโนมัติจัดลำดับความสำคัญของที่เก็บแพ็กเกจสาธารณะสูงกว่ารีจิสทรีส่วนตัวภายในองค์กรเนื่องจากมีรูปแบบการตั้งชื่อที่เหมือนกัน ทำให้ดึงแพ็กเกจแปลกปลอมเข้ามาในบิลด์ภายในโดยตรง ส่วน Typosquatting อาศัยความผิดพลาดของมนุษย์ โดยผู้โจมตีจะลงทะเบียนแพ็กเกจที่มีชื่อคล้ายคลึงกับเฟรมเวิร์กที่ถูกต้องอย่างมาก (เช่นmicros0ft.comแทนที่จะเป็นmicrosoft.com).

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

บทเรียนที่ได้รับจาก Log4j และ SolarWinds

ความสำคัญเชิงระบบของ SBOM เป็นที่ประจักษ์ชัดเจนในระดับสากล ภายหลังเกิดวิกฤตความมั่นคงปลอดภัยไซเบอร์ระดับโลกที่ตกเป็นข่าวดัง โดยเฉพาะอย่างยิ่งกรณีการละเมิดระบบ SolarWinds Orion และการค้นพบช่องโหว่ Log4j (Log4Shell)

ในช่วงปลายปี 2020 ผู้โจมตีสามารถเจาะโครงสร้างพื้นฐานสำหรับบิลด์ซอฟต์แวร์ของ SolarWinds ได้สำเร็จ และแทรกโค้ดอันตราย (Sunburst) เข้าไปในไฟล์อัปเดตที่มีการลงลายมือชื่อดิจิทัลโดยตรง ซึ่งถูกแจกจ่ายไปยังลูกค้าประมาณ 18,000 ราย รวมถึงหน่วยงานภาครัฐและองค์กรธุรกิจขนาดใหญ่ เนื่องจากโค้ดอันตรายดังกล่าวฝังตัวอยู่ภายในไฟล์ปฏิบัติการ (executable) ที่ถูกต้องและมีการลงลายมือชื่อจากผู้ขาย ทำให้ระบบป้องกันระดับปริมณฑลและเอเจนต์ตรวจจับบนอุปกรณ์ปลายทางไม่สามารถตรวจจับความผิดปกติของอัปเดตดังกล่าวได้ ข้อกำหนด SBOM ด้านความถูกต้องสมบูรณ์ทางวิทยาการเข้ารหัสและการตรวจสอบความถูกต้องของคอมโพเนนต์อย่างเป็นอิสระในทุกขั้นตอนการบิลด์ จึงกลายเป็นบทเรียนทางเทคนิคที่สำคัญที่สุดจากเหตุการณ์นี้

+-------------------------------------------------------------------+
|               UPSTREAM VULNERABILITY PROPAGATION                  |
|                                                                   |
|   [ Open-Source Library ] ---> ( CVE-2021-44228 Log4j Flaw )      |
|              |                                                    |
|              v                                                    |
|   [ Direct Dependency A ] ---> ( Enterprise Web Framework )       |
|              |                                                    |
|              v                                                    |
|   [ Transitive Dep. B ]   ---> ( Microservice Backend API )       |
|              |                                                    |
|              v                                                    |
|   [ Production Artifact ] ---> ( Unmonitored Business System )    |
+-------------------------------------------------------------------+

ในเดือนธันวาคม 2021 การเปิดเผยช่องโหว่ CVE-2021-44228 ในไลบรารี Apache Log4j ได้เผยให้เห็นถึงการขาดการมองเห็นอย่างร้ายแรงภายในฐานโค้ดขององค์กร Log4j ไม่ได้ถูกฝังอยู่เพียงในแอปพลิเคชันหลักเท่านั้น แต่ยังซ่อนลึกอยู่หลายชั้นภายในซอฟต์แวร์สำเร็จรูปเชิงพาณิชย์ (COTS), อุปกรณ์ของบุคคลที่สาม, มิดเดิลแวร์ขององค์กร และบริการคลาวด์ องค์กรต่างๆ ต้องใช้เวลาหลายร้อยชั่วโมงในการสแกนระบบไฟล์ภายใน และรอการยืนยันทางอีเมลจากผู้ขายเพียงเพื่อจะระบุว่ามี Log4j อยู่ในสภาพแวดล้อมระบบของตนหรือไม่ ในทางตรงกันข้าม องค์กรที่มีคลังจัดเก็บ SBOM แบบอัตโนมัติและพร้อมใช้งาน สามารถสืบค้นฐานข้อมูลส่วนกลางและระบุอินสแตนซ์ที่มีช่องโหว่ได้ภายในไม่กี่นาที ซึ่งตอกย้ำถึงความแตกต่างด้านประสิทธิภาพการดำเนินงานอย่างมหาศาลในแง่ของวุฒิภาวะการตอบสนองต่อเหตุการณ์ความมั่นคงปลอดภัย

ความเสี่ยงที่ซ่อนอยู่ในคอมโพเนนต์โอเพนซอร์ส

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

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

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

• ช่องโหว่แบบส่งต่อ (Transitive Vulnerabilities):มากกว่า 70% ของช่องโหว่ที่พบในแอปพลิเคชันซอฟต์แวร์ไม่ได้อยู่ในดีเพนเดนซีโดยตรง แต่อยู่ในดีเพนเดนซีย่อยแบบส่งต่อในระดับลึก ซึ่งนักพัฒนาไม่เคยประกาศเรียกใช้อย่างชัดเจน

• การขาดการตรึงเวอร์ชัน (Lack of Version Pinning):การกำหนดค่าบิลด์ที่พึ่งพาการระบุเวอร์ชันแบบไดนามิก (เช่นexample.comหรือuser_id) ทำให้ไปป์ไลน์เสี่ยงต่อการเปลี่ยนแปลงที่ทำให้ระบบทำงานไม่ได้ (breaking changes) และเสี่ยงต่อการปล่อยโค้ดต้นน้ำที่ไม่ผ่านการตรวจสอบโดยปราศจากการกำกับดูแลอย่างชัดเจนของนักพัฒนา

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

คุณค่าทางธุรกิจ: ก้าวไปไกลกว่าความมั่นคงปลอดภัยขั้นพื้นฐาน

แม้ผู้เชี่ยวชาญด้านความมั่นคงปลอดภัยมักประเมิน SBOM ผ่านมุมมองของการป้องกันภัยคุกคามและการจัดการช่องโหว่ แต่คุณค่าทางธุรกิจเชิงกลยุทธ์ของ SBOM ยังครอบคลุมไปถึงประสิทธิภาพการจัดซื้อจัดจ้าง การจัดการสินทรัพย์ซอฟต์แวร์ การตรวจสอบสถานะเพื่อการควบรวมและเข้าซื้อกิจการ (M&A) ตลอดจนการบรรเทาความเสี่ยงทางกฎหมายโดยตรง

การนำโปรแกรม SBOM มาใช้ทั่วทั้งองค์กรช่วยเปลี่ยนการจัดการดีเพนเดนซีจากภาระทางวิศวกรรมที่ไม่สามารถคาดเดาได้ ให้กลายเป็นเวิร์กโฟลว์การดำเนินงานที่เป็นไปโดยอัตโนมัติและโปร่งใส องค์กรที่ปฏิบัติต่อข้อมูล SBOM เสมือนเป็นสินทรัพย์เชิงกลยุทธ์ขององค์กร จะสามารถลดระยะเวลาในการนำซอฟต์แวร์ออกสู่ตลาด (time-to-market) เพิ่มความคล่องตัวให้วงจรการขายระดับองค์กรด้วยการมอบความโปร่งใสแก่ว่าที่ลูกค้า และลดอุปสรรคในระหว่างการตรวจสอบความมั่นคงปลอดภัยโดยบุคคลที่สาม

การเร่งกระบวนการแก้ไขช่องโหว่ (MTTR)

ระยะเวลาเฉลี่ยในการแก้ไขปัญหา (Mean Time to Remediate หรือ MTTR) คือดัชนีชี้วัดผลงานหลัก (KPI) ที่สำคัญสำหรับทั้งงานด้านวิศวกรรมและการปฏิบัติการด้านความมั่นคงปลอดภัย เมื่อมีการเปิดเผย CVE ที่มีความรุนแรงสูง วงจรชีวิตของการแก้ไขจะประกอบด้วย 3 ระยะที่แตกต่างกัน ได้แก่ การระบุปัญหา การคัดกรองและประเมินทางเทคนิค และการปรับใช้แพตช์

ในองค์กรที่ขาดรายการคอมโพเนนต์ที่เครื่องสามารถอ่านได้ (machine-readable) ระยะการระบุปัญหาจะกินเวลาการทำงานของวิศวกรไปเกือบทั้งหมด เนื่องจากทีมงานต้องตรวจสอบคลังโค้ดด้วยตนเอง รันการค้นหาไฟล์บนเซิร์ฟเวอร์โปรดักชันซึ่งใช้ทรัพยากรสูง และต้องประสานงานข้ามทีมพัฒนาแอปพลิเคชันต่างๆ ที่กระจัดกระจายเพื่อประเมินระดับความเสี่ยงที่ระบบได้รับผลกระทบ

TRADITIONAL INCIDENT RESPONSE TIMELINE (WITHOUT SBOM)
[ Discovery of CVE ] ──> [ Manual Code Searches (3-7 Days) ] ──> [ Triage & Patching (2-4 Days) ] ──> [ Deployment ]

OPTIMIZED INCIDENT RESPONSE TIMELINE (WITH AUTOMATED SBOM)
[ Discovery of CVE ] ──> [ SBOM Database Query (< 5 Mins) ] ──> [ Targeted Patching (1-2 Days) ] ──> [ Deployment ]

เมื่อองค์กรผสานรวมการสร้าง SBOM เข้ากับ CI/CD pipeline ของตน และทำดัชนีแจกแจงรายการ (manifests) แบบรวมศูนย์ไว้ภายในแพลตฟอร์มการจัดการช่องโหว่ระดับองค์กร ระยะเวลาในการระบุตัวตนจะลดลงจนแทบเป็นศูนย์ ทีมรักษาความปลอดภัยสามารถสั่งค้นหาด้วยคำสั่งโปรแกรมไปยังฐานข้อมูล SBOM ส่วนกลางเพื่อหาตัวระบุส่วนประกอบที่เจาะจง (เช่นpkg:maven/org.apache.logging.log4j/[email protected]) ซึ่งจะส่งคืนรายการของ container images, เวอร์ชันของแอปพลิเคชัน และสภาพแวดล้อมที่นำไปใช้งาน (deployed environments) ที่ได้รับผลกระทบได้อย่างแม่นยำในทันที ความสามารถนี้ช่วยให้นักพัฒนาข้ามขั้นตอนการค้นหาไปได้ทั้งหมด และสามารถดำเนินการแพตช์พร้อมทั้งลดผลกระทบได้โดยตรง

การเพิ่มประสิทธิภาพการจัดซื้อซอฟต์แวร์และการจัดการความเสี่ยงจากผู้จำหน่าย

การประเมินความเสี่ยงของผู้จำหน่ายภายนอก (third-party vendor) ในปัจจุบันยังคงพึ่งพาแบบสอบถามแบบคงที่ (static questionnaires) ซึ่งให้ความเชื่อมั่นทางเทคนิคได้น้อยมาก ผู้จำหน่ายจะแจ้งมาตรการควบคุมความปลอดภัยของตนผ่านการสำรวจเชิงอัตวิสัย ซึ่งไม่ได้ให้ข้อมูลเชิงลึกแบบเรียลไทม์เกี่ยวกับซอฟต์แวร์จริงที่กำลังส่งมอบเลย

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

นอกจากนี้ ในระหว่างการควบรวมและเข้าซื้อกิจการ (M&A) ผู้ซื้อสามารถใช้ประโยชน์จากการวิเคราะห์ SBOM เพื่อตรวจสอบสถานะทางเทคนิค (technical due diligence) ของสินทรัพย์ซอฟต์แวร์เป้าหมายได้อย่างรวดเร็ว การตรวจสอบ SBOM ช่วยเปิดเผยหนี้ทางเทคนิค (technical debt) ที่แท้จริง การใช้งานส่วนประกอบรุ่นเก่า และความสมบูรณ์ทางสถาปัตยกรรมของแพลตฟอร์มที่เป็นกรรมสิทธิ์ของกิจการเป้าหมายได้ภายในไม่กี่ชั่วโมง จึงช่วยป้องกันค่าใช้จ่ายในการแก้ไขปัญหาที่ไม่คาดคิดหลังการเข้าซื้อกิจการ

การสร้างความมั่นใจในการปฏิบัติตามสัญญาอนุญาตและการหลีกเลี่ยงข้อผิดพลาดทางกฎหมาย

ดีเพนเดนซีของซอฟต์แวร์มีข้อผูกพันทางกฎหมาย สัญญาอนุญาตโอเพนซอร์ส (open-source licenses) มีความหลากหลายครอบคลุมตั้งแต่สัญญาอนุญาตแบบผ่อนปรน (permissive licenses เช่น MIT, Apache 2.0 และ BSD) ไปจนถึงสัญญาอนุญาตแบบ copyleft เข้มงวด (strong copyleft licenses เช่น GNU General Public License (GPL) v2/v3 และ Affero GPL (AGPL))

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

+----------------------------------------------------------------------+
|                     SOFTWARE LICENSING SPECTRUM                      |
|                                                                      |
|  [ PERMISSIVE ]                                     [ COPYLEFT ]     |
|  MIT / Apache 2.0 / BSD                         GPLv2 / GPLv3 / AGPL |
|  ------------------------------------------------------------------  |
|  Commercial friendly                             Source disclosure   |
|  Attribution required                            Derivative sharing  |
|  Low legal risk for proprietary software         High contamination  |
+----------------------------------------------------------------------+

การรวมไลบรารี GPL หรือ AGPL เข้ามาใน SaaS เชิงพาณิชย์ที่เป็นกรรมสิทธิ์หรือผลิตภัณฑ์สำหรับองค์กรที่มีการแจกจ่ายโดยไม่ได้ตั้งใจ ก่อให้เกิดความเสี่ยงร้ายแรงต่อการปนเปื้อนของทรัพย์สินทางปัญญา ซึ่งทำให้องค์กรเสี่ยงต่อการถูกดำเนินคดีจากการละเมิดลิขสิทธิ์ การถูกบังคับให้เปิดเผยซอร์สโค้ดที่เป็นกรรมสิทธิ์ หรือการต้องปรับโครงสร้างโค้ดอย่างเร่งด่วน (emergency code refactoring) จนส่งผลกระทบต่อการทำงาน

SBOM จะจัดทำแคตตาล็อกตัวระบุสัญญาอนุญาตที่ประกาศไว้สำหรับทุกๆ องค์ประกอบและ transitive dependency โดยใช้ประโยชน์จากตัวระบุสัญญาอนุญาตมาตรฐาน SPDX เมื่อผสานการทำงานร่วมกับระบบนโยบายอัตโนมัติ ระบบบิลด์จะสามารถแจ้งเตือนหรือบล็อก pull request ใดๆ ที่นำสัญญาอนุญาตที่ไม่เข้ากันเข้ามาได้ทันที ก่อนที่โค้ดจะเข้าสู่กระบวนการผลิต (production)

การปฏิบัติตามข้อกำหนดภาคบังคับ: ภูมิทัศน์ด้านกฎระเบียบเกี่ยวกับ SBOM

การนำรายการส่วนประกอบซอฟต์แวร์ (Software Bill of Materials) มาใช้ได้เปลี่ยนผ่านจากแนวปฏิบัติที่ดีที่สุดในอุตสาหกรรม (best practice) มาเป็นข้อกำหนดทางกฎหมายและกฎระเบียบที่มีผลบังคับใช้ในหลายเขตอำนาจศาลทั่วโลก โดยรัฐบาล องค์กรกำหนดมาตรฐาน และหน่วยงานกำกับดูแลอุตสาหกรรมต่างตระหนักดีว่า โครงสร้างพื้นฐานสำคัญ ข้อมูลองค์กร และความมั่นคงแห่งชาติ ล้วนขึ้นอยู่กับความสมบูรณ์และปลอดภัยของซอฟต์แวร์ทั้งสิ้น

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

คำสั่งฝ่ายบริหารของสหรัฐฯ 14028 และข้อกำหนดระดับรัฐบาลกลาง

ในเดือนพฤษภาคม ค.ศ. 2021 สหรัฐอเมริกาได้ออกคำสั่งฝ่ายบริหาร (Executive Order หรือ EO) 14028 ในหัวข้อImproving the Nation's Cybersecurity (การยกระดับความมั่นคงปลอดภัยทางไซเบอร์ของชาติ)คำสั่งฝ่ายบริหารฉบับนี้ถือเป็นจุดเปลี่ยนครั้งประวัติศาสตร์สำหรับอุตสาหกรรมซอฟต์แวร์ทั่วโลก โดยกำหนดให้หน่วยงานรัฐบาลกลางต้องยกระดับการป้องกันทางไซเบอร์ให้ทันสมัย และรักษาความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์ของตนอย่างชัดเจน

ภายใต้คำสั่ง EO 14028 ผู้จำหน่ายซอฟต์แวร์ที่ขายโซลูชันให้กับรัฐบาลกลางของสหรัฐฯ จะต้องจัดเตรียม SBOM อย่างเป็นทางการสำหรับแต่ละผลิตภัณฑ์ หรือรับรองว่าซอฟต์แวร์ของตนได้รับการพัฒนาโดยยึดตามแนวปฏิบัติด้านการพัฒนาซอฟต์แวร์อย่างปลอดภัย ตามที่ระบุไว้ในสิ่งพิมพ์พิเศษ National Institute of Standards and Technology (NIST) Special Publication 800-218 (Secure Software Development Framework - SSDF)

แนวทางปฏิบัติที่ตามมาจากสำนักบริหารและงบประมาณ (Office of Management and Budget หรือ OMB Memorandums M-22-18 และ M-23-16) ได้นำข้อกำหนดเหล่านี้ไปสู่การปฏิบัติ โดยสั่งการให้หน่วยงานรัฐบาลกลางขอหนังสือรับรองตนเอง (self-attestation letter) จากผู้ผลิตซอฟต์แวร์เพื่อยืนยันการปฏิบัติตามแนวทางของ NIST และกำหนดให้ต้องส่งมอบ SBOM ในรูปแบบที่เครื่องสามารถอ่านได้เมื่อหน่วยงานร้องขอ ผู้จำหน่ายที่ไม่สามารถปฏิบัติตามมาตรฐานเหล่านี้มีความเสี่ยงที่จะถูกตัดสิทธิ์จากกรอบการจัดซื้อจัดจ้างของรัฐบาลกลาง

องค์ประกอบขั้นต่ำของ NTIA เพื่อ SBOM ที่มีประสิทธิภาพ

เพื่อกำหนดมาตรฐานว่าสิ่งใดคือ SBOM ที่ถูกต้องและนำไปใช้งานได้จริงภายใต้คำสั่ง EO 14028 สำนักงานบริหารการสื่อสารและสารสนเทศแห่งชาติ (National Telecommunications and Information Administration หรือ NTIA) ซึ่งเป็นหน่วยงานในสังกัดกระทรวงพาณิชย์ของสหรัฐฯ จึงได้เผยแพร่เอกสารการกำหนดกรอบความโปร่งใสของส่วนประกอบซอฟต์แวร์: การสร้างรายการส่วนประกอบซอฟต์แวร์ (Software Bill of Materials) ร่วมกัน.

NTIA ได้กำหนดหมวดหมู่หลัก 3 หมวดหมู่ซึ่งประกอบกันเป็น "องค์ประกอบขั้นต่ำ" (Minimum Elements) สำหรับ SBOM ที่มีประสิทธิภาพ:

1. เขตข้อมูล (Data Fields):ข้อมูลพื้นฐานที่จำเป็นในการระบุเอกลักษณ์ของแต่ละส่วนประกอบอย่างเฉพาะเจาะจง:

• ชื่อผู้จัดหา (Supplier Name):นิติบุคคลหรือองค์กรที่สร้างหรือบรรจุแพ็กเกจของส่วนประกอบนั้น

• ชื่อส่วนประกอบ (Component Name):ชื่อที่กำหนดไว้ของไลบรารีหรือโมดูลซอฟต์แวร์

• เวอร์ชันของส่วนประกอบ (Version of the Component):เวอร์ชันที่เผยแพร่หรือตัวระบุคอมมิต (commit identifier) ที่แน่นอน

• ตัวระบุเอกลักษณ์อื่น ๆ (Other Unique Identifiers):ตัวระบุตำแหน่งที่เป็นมาตรฐาน เช่น Package URLs (purl) หรือ Common Platform Enumerations (CPE)

• ความสัมพันธ์ของส่วนประกอบที่ต้องพึ่งพา (Dependency Relationship):การจับคู่ความสัมพันธ์แบบต้นน้ำ-ปลายน้ำ (เช่น "ส่วนประกอบ A มีส่วนประกอบ B อยู่ภายใน")

• ผู้จัดทำข้อมูล SBOM (Author of SBOM Data):นิติบุคคลหรือองค์กรที่สร้างไฟล์แจกแจงรายการ (manifest)

• การประทับเวลา (Timestamp):วันและเวลาที่แน่นอนในการสร้าง SBOM

1. การรองรับระบบอัตโนมัติ (Automation Support):ไฟล์แจกแจงรายการ (manifest) จะต้องเผยแพร่ในรูปแบบข้อมูลมาตรฐานที่เครื่องสามารถอ่านได้ (machine-readable) เพื่อให้สามารถแจงส่วน (parsing) ทำดัชนี และเชื่อมโยงช่องโหว่โดยอัตโนมัติข้ามห่วงโซ่เครื่องมือ (toolchains) ที่หลากหลาย โดย NTIA ได้ให้การยอมรับ SPDX, CycloneDX และแท็ก SWID ให้เป็นรูปแบบที่สอดคล้องตามเกณฑ์

2. แนวทางปฏิบัติและกระบวนการ (Practices and Processes):ข้อกำหนดด้านการปฏิบัติงานที่ควบคุมวงจรชีวิตของ SBOM รวมถึงการสร้างไฟล์แจกแจงรายการใหม่ทุกครั้งที่มีการบิลด์หรือรีลีสซอฟต์แวร์ การอัปเดตบันทึกส่วนประกอบเมื่อมีการติดตั้งแพตช์ และการจัดการความลึกของส่วนประกอบไปจนถึงการพึ่งพาแบบส่งต่อ (transitive dependencies)

ความเคลื่อนไหวระดับโลกสู่ความโปร่งใสของซอฟต์แวร์

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

• พระราชบัญญัติความยืดหยุ่นทางไซเบอร์ของสหภาพยุโรป (European Union Cyber Resilience Act - CRA):CRA ของสหภาพยุโรปกำหนดข้อกำหนดด้านความมั่นคงปลอดภัยไซเบอร์ที่มีผลผูกพันทางกฎหมายสำหรับ "ผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล" ทั้งหมดที่วางจำหน่ายในตลาดเดี่ยวของยุโรป ผู้ผลิตจะต้องจัดทำเอกสารบันทึกส่วนประกอบซอฟต์แวร์ทั้งหมดอย่างเป็นระบบ ดูแลรักษา SBOM ภายในองค์กร และส่งมอบให้แก่หน่วยงานกำกับดูแลตลาดเมื่อได้รับการร้องขอตลอดอายุการใช้งานที่คาดหวังของผลิตภัณฑ์

• กฎระเบียบด้านเครื่องมือแพทย์ (US FDA และ EU MDR):สำนักงานคณะกรรมการอาหารและยาแห่งสหรัฐฯ (FDA) ภายใต้มาตรา 524B แห่ง Federal Food, Drug, and Cosmetic Act กำหนดให้ผู้ผลิตเครื่องมือแพทย์ต้องส่ง SBOM ที่ครอบคลุมสำหรับอุปกรณ์ใด ๆ ที่มีความสามารถในการเชื่อมต่อทางไซเบอร์ เพื่อเป็นเงื่อนไขเบื้องต้นในการขออนุมัติก่อนวางจำหน่ายในตลาด โดยมีแนวทางปฏิบัติที่คล้ายคลึงกันบังคับใช้ภายใต้กฎระเบียบว่าด้วยเครื่องมือแพทย์ของสหภาพยุโรป (EU MDR)

• มาตรฐานยานยนต์ (ISO/SAE 21434):มาตรฐานระดับโลกของภาคยานยนต์สำหรับความมั่นคงปลอดภัยไซเบอร์ของยานพาหนะทางบก กำหนดให้ผู้ผลิตยานยนต์และซัพพลายเออร์หน่วยควบคุมอิเล็กทรอนิกส์ (ECU) ต้องติดตามส่วนประกอบซอฟต์แวร์ของบุคคลที่สามตลอดทั้งห่วงโซ่อุปทานยานยนต์

• มาตรฐานภาคการเงิน (PCI DSS v4.0 และ DORA):ในแวดวงการเงิน มาตรฐานต่าง ๆ เช่น Payment Card Industry Data Security Standard (PCI DSS v4.0) และ Digital Operational Resilience Act (DORA) ของสหภาพยุโรป กำหนดให้มีการติดตามรายการสิ่งของ (inventory tracking) อย่างเข้มงวดสำหรับสคริปต์ของบุคคลที่สาม ไลบรารีโอเพนซอร์ส และผู้ให้บริการเทคโนโลยี เพื่อลดความเสี่ยงจากการหยุดชะงักทางการเงินเชิงระบบ

โครงสร้างของ SBOM ที่เป็นมาตรฐาน: อธิบายรูปแบบหลักต่าง ๆ

เพื่อให้ SBOM ใช้งานได้จริงในเชิงปฏิบัติ จะต้องไม่เป็นเพียงไฟล์ข้อความที่ไม่เป็นทางการ รายการตรวจสอบแบบมาร์กดาวน์ หรือสเปรดชีตที่ไม่มีมาตรฐาน ห่วงโซ่อุปทานซอฟต์แวร์ยุคใหม่ต้องการรูปแบบข้อมูลเชิงโครงสร้างที่เครื่องสามารถอ่านได้ ซึ่งสามารถแจงส่วน (parse) ได้โดยตัวรัน Continuous Integration, โปรแกรมสแกนหาช่องโหว่, คลังจัดการสินทรัพย์ และพอร์ทัลการจัดซื้อจัดจ้าง

ระบบนิเวศความมั่นคงปลอดภัยของซอฟต์แวร์ทั่วโลกได้รวมศูนย์เข้าสู่มาตรฐานเปิดหลักสองมาตรฐาน ได้แก่ SPDX และ CycloneDX โดยยังคงรองรับแท็ก Software Identification (SWID) แบบเดิมในสภาพแวดล้อมระดับองค์กรบางแห่ง

SPDX (Software Package Data Exchange)

Software Package Data Exchange (SPDX) เป็นมาตรฐานสากล (ISO/IEC 5962:2021) ที่ดูแลรักษาโดย Linux Foundation โดยได้รับการพัฒนามากว่าทศวรรษ เดิมที SPDX ถูกสร้างขึ้นเพื่อจัดทำแคตตาล็อกใบอนุญาตซอฟต์แวร์โอเพนซอร์ส ลิขสิทธิ์ของส่วนประกอบ และเมทาดาตาทางกฎหมายอย่างเป็นระบบ

เมื่อความท้าทายด้านความมั่นคงปลอดภัยของห่วงโซ่อุปทานขยายตัวขึ้น SPDX จึงได้พัฒนาเป็นข้อกำหนดเฉพาะด้านความมั่นคงปลอดภัยที่ครอบคลุม โดยเวอร์ชันปัจจุบัน (SPDX 2.3 และ SPDX 3.0) รองรับการติดตามช่องโหว่อย่างละเอียด ความสัมพันธ์ของส่วนประกอบ ผลรวมตรวจสอบการเข้ารหัส (cryptographic checksums) แหล่งที่มาของการบิลด์ (build provenance) และโปรไฟล์การประมวลผล ทั้งนี้ SPDX รองรับรูปแบบการแปลงข้อมูลอนุกรม (serialization formats) ที่หลากหลาย รวมถึง JSON, YAML, XML และข้อความแบบ tag-value

จากจุดกำเนิดดังกล่าว ทำให้ SPDX ยังคงเป็นรูปแบบชั้นนำสำหรับองค์กรที่ให้ความสำคัญกับการกำกับดูแลทางกฎหมายเชิงลึก การตรวจสอบการปฏิบัติตามสัญญาอนุญาตโอเพนซอร์ส และโครงการริเริ่มด้านวิชาการหรือการกำกับดูแลแบบเปิด

CycloneDX

OWASP CycloneDX เป็นมาตรฐานรายการส่วนประกอบ (Bill of Materials) ยุคใหม่ที่มีน้ำหนักเบาและเน้นด้านความปลอดภัย พัฒนาขึ้นโดยเฉพาะเพื่อความปลอดภัยของแอปพลิเคชัน ไปป์ไลน์ DevSecOps แบบอัตโนมัติ และการบริหารจัดการความเสี่ยงในห่วงโซ่อุปทานของซอฟต์แวร์

CycloneDX ได้รับการดูแลโดย Open Web Application Security Project (OWASP) และได้รับการออกแบบมาโดยเฉพาะเพื่อรองรับกรณีการใช้งานรายการส่วนประกอบที่หลากหลาย ซึ่งรวมถึง:

• S-BOM:Software Bill of Materials (ไลบรารี, เฟรมเวิร์ก, แพ็กเกจ)

• SaaS-BOM:Software-as-a-Service Bill of Materials (ส่วนประกอบที่ต้องพึ่งพาของบริการคลาวด์, เอนด์พอยต์, โฟลว์ของข้อมูล)

• HBOM:Hardware Bill of Materials (ไมโครคอนโทรลเลอร์, ชิ้นส่วนวงจร, เฟิร์มแวร์)

• OBOM:Operations Bill of Materials (ส่วนประกอบที่ต้องพึ่งพาขณะรันไทม์, สภาพแวดล้อมการทำงาน)

• AI/ML-BOM:แหล่งที่มาของโมเดลแมชชีนเลิร์นนิง, ชุดข้อมูลที่ใช้ฝึกฝน, ไฮเปอร์พารามิเตอร์ และขั้นตอนในไปป์ไลน์

CycloneDX มีการผสานรวมแบบเนทีฟสำหรับ Vulnerability Exploitability eXchange (VEX) ซึ่งช่วยให้ผู้จัดจำหน่ายไม่เพียงแต่ระบุคอมโพเนนต์ที่มีอยู่ได้เท่านั้น แต่ยังระบุได้ด้วยว่าช่องโหว่ CVE ที่ทราบบนคอมโพเนนต์ย่อยนั้นสามารถถูกโจมตีได้จริงในบริบทการทำงานเฉพาะของแอปพลิเคชันหรือไม่ นอกจากนี้ CycloneDX ยังรองรับสคีมา JSON และ XML ในตัวอีกด้วย

แท็ก SWID (Software Identification)

แท็ก Software Identification (SWID) ได้รับการกำหนดมาตรฐานภายใต้ ISO/IEC 19770-2:2015 พัฒนาขึ้นโดยเน้นการบริหารจัดการสินทรัพย์ซอฟต์แวร์เชิงพาณิชย์ (SAM) และการเพิ่มประสิทธิภาพสัญญาอนุญาตซอฟต์แวร์เป็นหลัก แท็ก SWID ประกอบด้วยไฟล์ XML ที่มีโครงสร้างซึ่งถูกจัดเก็บไว้บนระบบไฟล์ของอุปกรณ์ปลายทางในระหว่างการติดตั้งซอฟต์แวร์

แม้ว่าแท็ก SWID จะช่วยติดตามแอปพลิเคชันเดสก์ท็อปและเซิร์ฟเวอร์เชิงพาณิชย์ที่ติดตั้งทั่วทั้งระบบไอทีระดับองค์กรได้อย่างมีประสิทธิภาพ แต่เมื่อเทียบกับ SPDX และ CycloneDX แล้ว SWID มีการใช้งานน้อยกว่าสำหรับเว็บแอปพลิเคชันสมัยใหม่ ไมโครเซอร์วิส อิมเมจของคอนเทนเนอร์ และอาร์ทิแฟกต์แบบชั่วคราวในระบบ CI/CD อย่างไรก็ตาม SWID ยังคงพบได้ทั่วไปในการจัดการซอฟต์แวร์องค์กรแบบดั้งเดิม และในโปรไฟล์การปฏิบัติตามข้อกำหนดระดับสหพันธรัฐของสถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา (NIST) บางรายการ

การเลือกฟอร์แมตที่เหมาะสมสำหรับองค์กรของคุณ

การเลือกฟอร์แมต SBOM ที่เหมาะสมขึ้นอยู่กับกรณีการใช้งานหลักขององค์กร ความต้องการของลูกค้า และระบบนิเวศของเครื่องมือที่มีอยู่เดิม

หากองค์กรของคุณมุ่งเน้นไปที่ไมโครเซอร์วิสแบบคอนเทนเนอร์ การสแกนหาช่องโหว่ในกระบวนการ CI/CD อย่างรวดเร็ว และสถาปัตยกรรมแบบคลาวด์เนทีฟ (Cloud-native) เป็นหลักOWASP CycloneDXจะช่วยให้การนำไปใช้งานทำได้อย่างคล่องตัว มีเครื่องมือรองรับอย่างครอบคลุม และมีความสามารถด้าน VEX ในตัว

หากองค์กรของคุณต้องปฏิบัติตามแนวทางการจัดซื้อจัดจ้างตามมาตรฐาน ISO อย่างเคร่งครัด ทำงานร่วมกับผู้รับเหมาของหน่วยงานรัฐบาลกลางที่กำหนดให้ต้องปฏิบัติตาม ISO/IEC 5962 หรือมีเวิร์กโฟลว์การตรวจสอบทางกฎหมายที่มุ่งเน้นเรื่องสัญญาอนุญาตโอเพนซอร์สโดยเฉพาะSPDXคือมาตรฐานอุตสาหกรรม

แพลตฟอร์ม Software Composition Analysis (SCA) ระดับองค์กรและระบบจัดการ SBOM (SBOM orchestrator) สมัยใหม่จำนวนมากรองรับการแปลงไปมาระหว่าง SPDX และ CycloneDX ได้ทั้งสองทิศทาง ช่วยให้องค์กรสามารถสร้าง CycloneDX ได้โดยตรงระหว่างการบิลด์ CI/CD พร้อมทั้งสามารถเอ็กซ์พอร์ตไฟล์กำกับ SPDX ออกมาได้เมื่อต้องส่งมอบตามสัญญาการจัดซื้อจัดจ้างของลูกค้า

วิธีนำ SBOM ไปปรับใช้ในไพป์ไลน์ DevSecOps ของคุณ

การสร้าง SBOM ด้วยตนเองหรือมองว่าเป็นเพียงกิจกรรมปฏิบัติตามข้อกำหนดประจำปีนั้นไม่ได้มอบคุณค่าด้านความปลอดภัยในทางปฏิบัติแต่อย่างใด เนื่องจากความขึ้นต่อกัน (Dependencies) ของแอปพลิเคชันมีการอัปเดตอย่างต่อเนื่อง ไม่ว่าจะเป็นการคอมมิตโค้ดตามปกติของนักพัฒนา บอทอัปเดต dependency อัตโนมัติ (เช่น Dependabot, Renovate) และการบิลด์เบสอิมเมจของคอนเทนเนอร์ใหม่ ดังนั้น SBOM จึงต้องถูกสร้างขึ้นโดยอัตโนมัติในฐานะอาร์ติแฟกต์การบิลด์ที่ไม่สามารถเปลี่ยนแปลงได้ (Immutable build artifact) ภายในไพป์ไลน์ DevSecOps

การนำ SBOM ไปใช้งานจริงระดับโปรดักชันอย่างมีประสิทธิภาพจะดำเนินตามวงจรชีวิต 3 ขั้นตอนที่มีโครงสร้างชัดเจน ได้แก่ การสร้าง ณ เวลาบิลด์ (Build-time generation), การตรวจรับและประมวลผลช่องโหว่อย่างต่อเนื่อง (Continuous vulnerability ingestion) และการเผยแพร่อย่างปลอดภัย (Secure distribution)

ขั้นตอนที่ 1: การสร้างแบบอัตโนมัติในระหว่างกระบวนการ CI/CD

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

องค์กรต่างๆ มักใช้ประโยชน์จากเครื่องมือ CLI เฉพาะทาง ทั้งแบบโอเพนซอร์สและเชิงพาณิชย์ ซึ่งผสานรวมเข้ากับตัวรันไพป์ไลน์ (Pipeline runners) โดยตรง (เช่น GitHub Actions, GitLab CI, Jenkins, Tekton):

• เครื่องมือวิเคราะห์ซอร์สโค้ดและไฟล์ Manifest ของแพ็กเกจ:เครื่องมืออย่างเช่นexample.com, user_id, หรือstatusจะตรวจสอบไฟล์ล็อก (เช่นtest.com, data, example.com, Cargo.lock) และอาร์ติแฟกต์ไบนารี เพื่อสร้างกราฟส่วนประกอบ (Component graph) ที่แม่นยำ

• เครื่องมือวิเคราะห์คอนเทนเนอร์และระบบปฏิบัติการ:ในระหว่างการบิลด์คอนเทนเนอร์อิมเมจ เครื่องมือจะสแกนทั้งเลเยอร์ของแอปพลิเคชันและแพ็กเกจของระบบปฏิบัติการที่เป็นรากฐาน (เช่น Alpine APK, Debian APT, Red Hat RPM) เพื่อบันทึกไลบรารีระดับระบบ

• การลงลายมือชื่อเข้ารหัส (Cryptographic Signing):เมื่อ SBOM ถูกสร้างขึ้นในรูปแบบ JSON (SPDX หรือ CycloneDX) แล้ว จะต้องได้รับการลงลายมือชื่อเข้ารหัสโดยใช้เครื่องมืออย่างCosign(จากโครงการ Sigstore) ซึ่งจะสร้างการเชื่อมโยงที่ไม่สามารถแก้ไขและปฏิเสธได้ ระหว่างไพป์ไลน์การบิลด์ อิมเมจคอนเทนเนอร์หรือไบนารีที่ได้ และไฟล์กำกับ SBOM ที่เกี่ยวข้อง

# Example: Generating a CycloneDX SBOM for a container image using Syft
syft packages docker:my-app:v1.2.0 -o cyclonedx-json=sbom.json

# Example: Cryptographically signing the generated SBOM with Cosign
cosign attach sbom --sbom sbom.json my-registry.internal/my-app:v1.2.0
cosign sign --key k8s://cosign-keys/my-key my-registry.internal/my-app:v1.2.0

ขั้นตอนที่ 2: การมอนิเตอร์และการสแกนหาช่องโหว่อย่างต่อเนื่อง

SBOM คือสแนปชอตแบบคงที่ (static snapshot) ของคอมโพเนนต์ต่างๆ ในแอปพลิเคชัน ณ จุดเวลาใดเวลาหนึ่ง อย่างไรก็ตาม ภูมิทัศน์ของภัยคุกคามนั้นมีการเปลี่ยนแปลงอยู่ตลอดเวลา คอมโพเนนต์ที่ถือว่าปลอดภัยอย่างสมบูรณ์เมื่อตอนบิลด์ในวันจันทร์ อาจมีการเปิดเผยช่องโหว่ CVE ร้ายแรงในวันศุกร์ก็เป็นได้

ดังนั้น ไปป์ไลน์จึงต้องนำเข้า SBOM ที่สร้างขึ้นไปยังแพลตฟอร์มการจัดการ SBOM และการจับคู่ช่องโหว่แบบรวมศูนย์ (เช่น OWASP Dependency-Track, Anchore Enterprise, Snyk หรือฐานข้อมูลช่องโหว่ภายในองค์กร)

CONTINUOUS SBOM INGESTION & MATCHING LIFECYCLE
+-----------------------+     +-----------------------+     +------------------------+
| CI/CD Pipeline Build  | --> | Machine-Readable SBOM | --> | Centralized SBOM Repo  |
+-----------------------+     +-----------------------+     +------------------------+
                                                                        |
                                                                        v
+-----------------------+     +-----------------------+     +------------------------+
| Real-time Risk Alerts | <-- | Automated CVE Matcher | <-- | Upstream CVE/NVD Feeds |
+-----------------------+     +-----------------------+     +------------------------+

แพลตฟอร์มเหล่านี้ทำงานโดยการแยกการสแกนช่องโหว่ออกจากคลังโค้ด (code repository) โดยตรง แทนที่จะต้องรันการสแกน SAST หรือ SCA ที่ใช้ทรัพยากรประมวลผลสูงซ้ำๆ บน Git repository ทุกแห่งเป็นประจำทุกวัน ระบบจะเปรียบเทียบคลังรายการส่วนกลางของแฮชคอมโพเนนต์และ Package URL เข้ากับฟีดภัยคุกคามแบบเรียลไทม์อย่างต่อเนื่อง ซึ่งรวมถึง National Vulnerability Database (NVD), GitHub Advisory Database และรายงานความปลอดภัยจากเวนเดอร์ เมื่อมีการบันทึกช่องโหว่ใหม่เข้ามา ระบบจะระบุซอฟต์แวร์อาร์ทิแฟกต์ (software artifact) ทั้งหมดที่ได้รับผลกระทบทั่วทั้งองค์กรได้ทันทีโดยไม่ต้องทำการบิลด์ใหม่

ขั้นตอนที่ 3: การจัดเก็บ การแชร์ และการนำเข้าข้อมูล SBOM อย่างปลอดภัย

เมื่อสร้างและทำดัชนีแล้ว Enterprise SBOM จะต้องได้รับการจัดเก็บและแชร์อย่างปลอดภัยตามการควบคุมการเข้าถึงขององค์กรและข้อตกลงกับลูกค้าภายนอก:

• การจัดเก็บร่วมกันบน Artifact Registry (Artifact Registry Colocation):Container Registry ยุคใหม่ที่เป็นไปตามมาตรฐาน OCI (เช่น Harbor, Amazon ECR, Google Artifact Registry) รองรับการจัดเก็บ SBOM ร่วมกับคอนเทนเนอร์อิมเมจโดยตรง โดยใช้ข้อกำหนด OCI artifact มาตรฐาน

• การควบคุมการเข้าถึงตามบทบาท (Role-Based Access Control: RBAC):ข้อมูล SBOM โดยละเอียดจะเปิดเผยเวอร์ชันของคอมโพเนนต์ภายในและสถาปัตยกรรมของระบบคุณอย่างชัดเจน แม้ว่าการแชร์ SBOM กับลูกค้าองค์กรเป้าหมายจะเป็นแนวทางปฏิบัติมาตรฐาน แต่การเผยแพร่ไฟล์ Manifest ภายในที่ไม่ได้ปิดบังข้อมูลสำคัญสู่สาธารณะ ควรได้รับการกำกับดูแลอย่างรอบคอบด้วยนโยบาย RBAC เพื่อป้องกันไม่ให้ผู้โจมตีล่วงรู้แผนผังสถาปัตยกรรมของระบบภายใน

• การผสานการทำงานกับ Vulnerability Exploitability eXchange (VEX):เพื่อป้องกันไม่ให้ลูกค้าหรือทีมรักษาความปลอดภัยภายในต้องแบกรับภาระการแจ้งเตือนช่องโหว่ในคอมโพเนนต์ย่อยที่ไม่สามารถเข้าถึงได้หรือไม่สามารถถูกโจมตีได้ (non-exploitable) มากเกินไป องค์กรต่างๆ จึงเผยแพร่เอกสาร VEX ควบคู่ไปกับ SBOM ของตน ข้อความระบุสถานะ VEX จะสื่อสารอย่างเป็นทางการว่า CVE ใดส่งผลกระทบต่อผลิตภัณฑ์หรือไม่ (เช่น "ไม่ได้รับผลกระทบ: โค้ดส่วนที่มีช่องโหว่ในไลบรารี X ไม่เคยถูกเรียกใช้งานโดยแอปพลิเคชันของเรา")

ความท้าทายทั่วไปในการจัดการ SBOM และวิธีเอาชนะ

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

การจัดการกับแอปพลิเคชันระบบเก่า (Legacy Applications)

แอปพลิเคชันแบบ Cloud-Native สมัยใหม่ที่เขียนด้วยภาษาที่มีตัวจัดการแพ็กเกจ (package manager) ซึ่งเป็นมาตรฐาน (เช่น Node.js, Go หรือ Python) นั้นสามารถจัดทำแค็ตตาล็อกได้อย่างตรงไปตรงมา ในทางตรงกันข้าม แอปพลิเคชันระบบเก่า แพลตฟอร์มระดับองค์กรแบบโมโนลิธิก (monolithic enterprise platforms), เฟิร์มแวร์ฝังตัว (embedded firmware) และโค้ดเบสภาษา C/C++ มักก่อให้เกิดความท้าทายที่แตกต่างกัน:

1. ไบนารีที่ได้รับจากเวนเดอร์ (Vendor Dropped Binaries):ระบบเก่ามักประกอบด้วยไฟล์คอมไพล์ของบุคคลภายนอกexample.comหรือuser_idแบบไบนารี ซึ่งไม่มีซอร์สโค้ด ไฟล์ล็อก หรือบิลด์ Manifest ดั้งเดิมหลงเหลืออยู่

2. ซอร์สโค้ดภายในที่ไม่มีการจัดการ (Unmanaged In-Tree Source Code):ในอดีต ทีมวิศวกรรมมักคัดลอกไฟล์ซอร์สโค้ดภายนอกมาไว้ใน Repository ภายในของตนเองโดยตรง โดยไม่มีข้อมูลเมทาดาตาของเวอร์ชันหรือแพ็กเกจเฮดเดอร์

กลยุทธ์การบรรเทาปัญหา:เพื่อจัดการกับโค้ดเบสระบบเก่า องค์กรต่างๆ จึงนำเครื่องมือวิเคราะห์องค์ประกอบไบนารี (Binary Composition Analysis: BCA) มาใช้ โซลูชัน BCA จะตรวจสอบแมชชีนโค้ดที่คอมไพล์แล้ว ตารางสัญลักษณ์ (symbol tables) และลายเซ็นไบนารี เพื่อสร้างชื่อคอมโพเนนต์และหมายเลขเวอร์ชันที่เป็นไปได้ของไลบรารีที่ฝังอยู่ขึ้นมาใหม่ แม้ว่า BCA จะมีลักษณะเป็นการคาดคะเน (heuristic) และมีความแน่นอนน้อยกว่าการแยกวิเคราะห์ไฟล์ล็อกในขั้นตอนบิลด์เล็กน้อย แต่ก็ช่วยให้ได้คลังรายการพื้นฐานที่จำเป็นสำหรับทรัพย์สินระบบเก่าที่สำคัญ จนกว่าจะสามารถปรับปรุงให้ทันสมัยหรือปรับโครงสร้างใหม่ได้

ปัญหา "สัญญาณรบกวน" (Noise): การจัดการผลบวกลวงในแผนภูมิลำดับชั้นของ Dependency (Dependency Trees)

ความท้าทายด้านการดำเนินงานที่ใหญ่ที่สุดประการเดียวซึ่งศูนย์ปฏิบัติการความปลอดภัย (SOC) และทีมพัฒนาที่นำ SBOM มาใช้ต้องเผชิญ คือภาวะล้าจากการแจ้งเตือนช่องโหว่ (Vulnerability alert fatigue) หรือที่เรียกกันทั่วไปว่าปัญหา "สัญญาณรบกวน" (Noise)

เมื่อ SBOM ทำการแจกแจงรายการ transitive sub-dependencies นับพันรายการในไมโครเซอร์วิสหลายร้อยตัว เครื่องมือสแกนช่องโหว่อัตโนมัติจะตรวจพบและแจ้งเตือน CVE ที่รู้จักนับร้อยรายการอย่างหลีกเลี่ยงไม่ได้ อย่างไรก็ตาม การศึกษาทั้งในเชิงวิชาการและในภาคอุตสาหกรรมแสดงให้เห็นว่ามากกว่า 80% ของช่องโหว่ที่มีอยู่ใน third-party dependencies นั้น ในทางโครงสร้างแล้วไม่สามารถเข้าถึงได้ (Structurally unreachable) เนื่องจากแอปพลิเคชันไม่เคยเรียกใช้หรือประมวลผลฟังก์ชันที่มีช่องโหว่นั้นภายในไลบรารีภายนอกเลย

+-------------------------------------------------------------------------+
|                  VULNERABILITY REACHABILITY ANALYSIS                    |
|                                                                         |
|  [ Full Software Package ] ───────────────────────────────────────────  |
|  └── [ Included Dependency: 100 Methods Available ]                    |
|       ├── Method A (Invoked by App)                                     |
|       ├── Method B (Invoked by App)                                     |
|       └── Method C (Contains Critical CVE - NEVER INVOKED / UNREACHABLE)|
|                                                                         |
|  VEX Assessment: "NOT_AFFECTED" (No code execution path to vulnerable method)
+-------------------------------------------------------------------------+

หากทุก CVE ที่ถูกแจ้งเตือนกลายเป็น Jira ticket ที่บล็อกการทำงานของนักพัฒนา ความเร็วในการส่งมอบงานด้านวิศวกรรม (Engineering velocity) จะลดฮวบลง และแรงต่อต้านของนักพัฒนาต่อนโยบายความปลอดภัยจะพุ่งสูงขึ้นทันที

กลยุทธ์การบรรเทาปัญหา:องค์กรจำเป็นต้องนำการสแกนความปลอดภัยที่คำนึงถึงบริบท (Context-aware security scanning) และกระบวนการทำงาน Vulnerability Exploitability eXchange (VEX) มาปรับใช้ โดยเครื่องมือวิเคราะห์โค้ดทั้งแบบ static และ dynamic ที่เข้าใจบริบทจะติดตาม call graphs จากโค้ดเฉพาะขององค์กรผ่านไปยังไลบรารีภายนอกเพื่อยืนยันความสามารถในการเข้าถึงฟังก์ชัน (Reachability) หากฟังก์ชันที่มีช่องโหว่ไม่เคยถูกเรียกใช้งานเลย ระบบจะสร้างข้อความยืนยัน VEX ในรูปแบบที่เครื่องอ่านได้โดยอัตโนมัติ ซึ่งระบุสถานะช่องโหว่ดังกล่าวว่าเป็นuser_idพร้อมเหตุผลประกอบ เช่นcreated_atสิ่งนี้จะช่วยระงับการแจ้งเตือนที่ไม่จำเป็นต้องดำเนินการใดๆ และช่วยให้นักพัฒนามุ่งเน้นการแก้ไขไปที่ความเสี่ยงด้านความปลอดภัยที่สามารถถูกโจมตีได้จริงเท่านั้น

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

S1: วัตถุประสงค์หลักของ SBOM คืออะไร?
C1: วัตถุประสงค์หลักของ Software Bill of Materials (SBOM) คือการจัดทำรายการคอมโพเนนต์ซอฟต์แวร์, ไลบรารีภายนอก (Third-party libraries) และ dependencies ทั้งหมดภายในแอปพลิเคชันอย่างแม่นยำในรูปแบบที่เครื่องอ่านได้ ความโปร่งใสนี้ช่วยให้สามารถติดตามช่องโหว่ได้แบบอัตโนมัติ ตรวจสอบการปฏิบัติตามสัญญาอนุญาตสิทธิ์ (Licensing compliance) และตอบสนองต่อเหตุการณ์ความมั่นคงปลอดภัยได้อย่างรวดเร็วเมื่อเกิดการโจมตีซัพพลายเชน

S2: ใครเป็นผู้รับผิดชอบในการสร้าง SBOM?
C2: ผู้ผลิตซอฟต์แวร์และทีมวิศวกรรมมีหน้าที่หลักในการสร้าง SBOM ในระหว่างกระบวนการบิลด์อัตโนมัติของ CI/CD ทั้งนี้ ในบริบทการจัดซื้อจัดจ้างระดับองค์กร ฝ่ายจัดซื้ออาจใช้เครื่องมือ Software Composition Analysis (SCA) และเครื่องมือวิเคราะห์ไฟล์ไบนารี เพื่อสร้างหรือตรวจสอบความถูกต้องของ SBOM สำหรับซอฟต์แวร์เชิงพาณิชย์ของบุคคลที่สามด้วยเช่นกัน

S3: บริษัททุกแห่งมีข้อบังคับทางกฎหมายให้ต้องมี SBOM หรือไม่?
C3: แม้ว่าจะยังไม่มีผลบังคับใช้ครอบคลุมทุกแอปพลิเคชันเชิงพาณิชย์ของภาคเอกชน แต่ SBOM เป็นข้อบังคับทางกฎหมายสำหรับผู้ขายที่จำหน่ายซอฟต์แวร์ให้แก่รัฐบาลกลางสหรัฐฯ ภายใต้คำสั่งประธานาธิบดีที่ 14028 (Executive Order 14028), สำหรับผู้ผลิตเครื่องมือแพทย์ภายใต้ข้อกำหนดของ FDA และภายใต้กรอบการกำกับดูแลที่กำลังเกิดขึ้นใหม่อย่าง Cyber Resilience Act ของสหภาพยุโรป

S4: SBOM สามารถป้องกันการโจมตีแบบ Zero-Day ได้หรือไม่?
C4: SBOM ไม่สามารถยับยั้งการโจมตีแบบ Zero-Day ที่ไม่เคยรู้จักมาก่อนได้โดยตรง เนื่องจากช่องโหว่นั้นยังไม่ได้รับการระบุหรือบันทึกไว้ในระบบ อย่างไรก็ตาม เมื่อมีการเปิดเผยช่องโหว่ Zero-Day สู่สาธารณะแล้ว SBOM จะช่วยลดระยะเวลาที่ต้องใช้ในการค้นหาและแก้ไขคอมโพเนนต์ที่ได้รับผลกระทบจากหลายสัปดาห์ให้เหลือเพียงไม่กี่นาที

S5: ควรปรับปรุง SBOM บ่อยเพียงใด?
C5: ควรสร้าง SBOM ใหม่อย่างเป็นอัตโนมัติในทุกๆ บิลด์ใหม่, ทุกเวอร์ชันที่ปล่อย หรือทุกการดีพลอยคอนเทนเนอร์ภายใน CI/CD pipeline เนื่องจาก dependencies, แพตช์ และโค้ดเบสมีการเปลี่ยนแปลงอย่างต่อเนื่อง SBOM ที่ล้าสมัยจึงไม่สามารถสะท้อนสถานะความปลอดภัยที่แท้จริงของแอปพลิเคชันที่กำลังทำงานอยู่ได้

S6: ข้อแตกต่างระหว่าง SBOM กับเครื่องมือ SCA คืออะไร?
C6: SBOM คือไฟล์กำกับข้อมูล (Data manifest) ที่มีมาตรฐานและเครื่องสามารถอ่านได้ ซึ่งแจกแจงรายการคอมโพเนนต์ เวอร์ชัน และสัญญาอนุญาตสิทธิ์ ส่วนเครื่องมือ Software Composition Analysis (SCA) คือเอ็นจินการสแกนอัตโนมัติที่วิเคราะห์โค้ดเบสเพื่อสร้าง SBOM, ตรวจหาช่องโหว่ที่ทราบแล้ว และบังคับใช้นโยบายสัญญาอนุญาตสิทธิ์

S7: เอกสาร VEX คืออะไร และเกี่ยวข้องกับ SBOM อย่างไร?
C7: Vulnerability Exploitability eXchange (VEX) คือเอกสารความปลอดภัยประกอบที่ระบุยืนยันว่าช่องโหว่เฉพาะรายการใดรายการหนึ่งที่ระบุไว้ใน SBOM นั้น สามารถถูกโจมตีได้จริงในบริบทการทำงานขณะรันไทม์ของผลิตภัณฑ์หรือไม่ VEX ช่วยป้องกันผลบวกลวง (False positives) โดยการยืนยันเมื่อซับรูทีนที่มีช่องโหว่นั้นไม่สามารถเข้าถึงได้จากภายนอก

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