ห่วงโซ่อุปทานซอฟต์แวร์ (supply chain) คือทุกขั้นตอนและทุกส่วนประกอบที่เกี่ยวข้องก่อนซอฟต์แวร์ไปถึงผู้ใช้ ตั้งแต่ซอร์สโค้ด (โค้ดต้นฉบับ) ไลบรารีจากภายนอก (ชุดโค้ดสำเร็จรูปที่นำมาใช้ต่อ) เครื่องมือ build (เครื่องมือที่ประกอบโค้ดให้เป็นซอฟต์แวร์ที่ใช้งานได้) ไปจนถึงช่องทางส่งมอบ SBOM (software bill of materials คือรายการส่วนประกอบของซอฟต์แวร์ เหมือนรายการวัตถุดิบบนฉลากอาหาร) บอกว่าซอฟต์แวร์ชิ้นหนึ่งประกอบด้วยอะไร เวอร์ชันไหน และใครเป็นผู้ผลิต บทความนี้อธิบายว่าทำไม SBOM จึงเป็นพื้นฐานของความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์ ข้อมูลขั้นต่ำที่ SBOM ควรมี รูปแบบไฟล์ SBOM ที่ใช้กัน 2 แบบ คือ CycloneDX (รูปแบบมาตรฐานของ OWASP) และ SPDX (รูปแบบมาตรฐานสากลอีกแบบ) และกรอบ SLSA (แนวปฏิบัติป้องกันการแก้ไขซอฟต์แวร์ระหว่างการสร้าง)
ห่วงโซ่อุปทานซอฟต์แวร์เสี่ยงตรงไหน
ซอฟต์แวร์สมัยนี้ใช้โค้ดที่ทีมเขียนเองเพียงบางส่วน ส่วนที่เหลือส่วนใหญ่เป็นไลบรารีโอเพนซอร์ส ส่วนประกอบจากผู้ขาย และเครื่องมือที่ใช้สร้างซอฟต์แวร์ ช่องโหว่หรือโค้ดอันตรายที่แฝงอยู่ในส่วนใดส่วนหนึ่ง จะตามส่วนนั้นไปอยู่ในทุกผลิตภัณฑ์ที่ใช้ส่วนนั้น
- ส่วนประกอบจากภายนอก: ไลบรารีอาจมีช่องโหว่ หรือถูกผู้ไม่หวังดีแก้ไข
- ระบบ build: ถ้าผู้โจมตีเข้าถึงระบบที่สร้างซอฟต์แวร์ได้ ก็แก้ผลลัพธ์ได้ แม้ซอร์สโค้ดต้นทางไม่เปลี่ยน
- การส่งมอบ: ไฟล์ที่ผู้ใช้ได้รับอาจไม่ตรงกับไฟล์ที่ผู้พัฒนาสร้างจริง
- จุดเชื่อมต่อใหม่ ๆ: เซิร์ฟเวอร์และเครื่องมือภายนอกที่นำมาต่อกับระบบ เช่น เซิร์ฟเวอร์ MCP (โปรโตคอลที่ให้ AI เรียกใช้เครื่องมือภายนอก) ก็เป็นส่วนประกอบจากภายนอกอีกประเภทหนึ่ง ดู MCP คืออะไร: สถาปัตยกรรม ความเสี่ยง และวิธีรับมือเชิงเทคนิค
SBOM คืออะไร และใช้ทำอะไร
CISA อธิบาย SBOM ว่าเป็นรายการที่ซ้อนกันเป็นชั้น (nested inventory) ซอฟต์แวร์ประกอบด้วยส่วนประกอบหลายส่วน แต่ละส่วนอาจมีส่วนย่อย และส่วนย่อยก็อาจมีส่วนย่อยลงไปอีก ส่วนประกอบอาจมาจากฝ่ายแรก คือผู้เขียน SBOM เอง หรือมาจากบุคคลที่สามก็ได้
ประโยชน์ที่ชัดที่สุดเกิดขึ้นเมื่อมีช่องโหว่ใหม่ประกาศออกมา องค์กรค้นใน SBOM แล้วรู้ได้ทันทีว่าซอฟต์แวร์ตัวไหนใช้ส่วนประกอบที่ได้รับผลอยู่ ไม่ต้องไล่ถามผู้ขายทีละราย CISA ระบุว่าข้อมูลนี้ช่วยตัดสินใจเรื่องช่องโหว่ที่รู้แล้วและที่เพิ่งค้นพบ และนำไปเทียบกับประกาศความปลอดภัย (security advisory) หรือรายการซอฟต์แวร์ที่องค์กรอนุมัติให้ใช้ได้
SBOM ไม่ได้แก้ปัญหาความปลอดภัยของซอฟต์แวร์ได้ทั้งหมด CISA ระบุว่า SBOM เป็นก้าวที่จำเป็นสู่การตัดสินใจโดยอาศัยข้อมูลความเสี่ยง เมื่อรู้ว่าส่วนประกอบใดมีช่องโหว่แล้ว องค์กรยังต้องจัดลำดับความสำคัญและแก้ไขต่อ ดู โปรแกรมบริหารจัดการช่องโหว่
ข้อมูลขั้นต่ำที่ SBOM ควรมี
ปี 2021 NTIA (หน่วยงานของสหรัฐฯ ด้านนโยบายโทรคมนาคมและสารสนเทศ) เผยแพร่ข้อมูลขั้นต่ำของ SBOM โดยกำหนดข้อมูล 7 อย่างต่อส่วนประกอบหนึ่งรายการ ได้แก่ ชื่อผู้จัดหา ชื่อส่วนประกอบ เวอร์ชัน ตัวระบุอื่นที่ใช้ค้นหา ความสัมพันธ์การพึ่งพากัน ผู้เขียนข้อมูล SBOM และเวลาที่จัดทำ
วันที่ 29 กรกฎาคม 2026 CISA ร่วมกับ NSA FBI และหน่วยงานพันธมิตรจากหลายประเทศ เผยแพร่เอกสาร 2026 Minimum Elements for a Software Bill of Materials (เวอร์ชัน 2.1 ของเอกสาร) เอกสารนี้ปรับปรุงและมาแทนฉบับ NTIA ปี 2021 ฉบับร่างออกเมื่อ 22 สิงหาคม 2025 และเปิดรับความเห็นถึง 3 ตุลาคม 2025 ฉบับใหม่กำหนดข้อมูล 17 อย่าง แบ่งเป็นข้อมูลของตัว SBOM (SBOM Metadata) และข้อมูลของแต่ละส่วนประกอบ (Component Data) และยังเพิ่มชุดแนวปฏิบัติ (Practices and Processes) เข้ามาด้วย
รายการต่อไปนี้แสดงข้อมูลที่เพิ่มใหม่จากฉบับ 2021 รวม 10 อย่าง รายการมี 7 ข้อ แต่นับได้ 10 อย่าง เพราะ 3 ข้อรวมข้อมูล 2 อย่างไว้ด้วยกัน
- ลายเซ็นของผู้เขียน SBOM (SBOM Author Signature): ลายเซ็นดิจิทัลที่ระบุว่าใครเป็นผู้เขียน
- ชื่อและเวอร์ชันของรูปแบบข้อมูล (SBOM Data Format Name และ Version): เช่น CycloneDX หรือ SPDX และเวอร์ชันของรูปแบบนั้น
- ชื่อและเวอร์ชันของเครื่องมือ (SBOM Tool Name และ Tool Version): เครื่องมือที่ใช้สร้างหรือแก้ไข SBOM
- บริบทการสร้าง (SBOM Generation Context): SBOM ถูกสร้างในช่วงไหนของวงจรซอฟต์แวร์ เช่น ก่อน build หรือหลัง build
- เวอร์ชันของ SBOM (SBOM Version): ตัวระบุว่าเอกสาร SBOM นี้เป็นฉบับแก้ไขครั้งที่เท่าไร
- ค่าแฮชและอัลกอริทึม (Component Hash Value และ Hash Algorithm): ค่าแฮช (hash) คือค่าที่คำนวณจากเนื้อไฟล์ ถ้าไฟล์เปลี่ยน ค่านี้ก็เปลี่ยนตาม จึงใช้ตรวจได้ว่าไฟล์ตรงกับที่บันทึกไว้หรือไม่
- สัญญาอนุญาตของส่วนประกอบ (Component License): สัญญาอนุญาต (license) ที่ระบุว่าส่วนประกอบนั้นใช้ได้ภายใต้เงื่อนไขแบบใด
ส่วนแนวปฏิบัติมี 6 ข้อ ได้แก่ ขอบเขตการครอบคลุม (coverage) ความถี่ในการปรับปรุง (frequency) การแจกจ่ายและส่งมอบ (distribution and delivery) ข้อมูลที่เครื่องอ่านและประมวลผลได้ (machine-processable data) การรองรับการแก้ไขข้อมูล SBOM (accommodation of updates) และการระบุให้ชัดเจนว่าข้อมูลใดยังไม่ทราบ (explicitly identifying unknown information) เอกสารของ CISA ระบุว่าไม่ได้สร้างข้อกำหนดใหม่ แต่ปรับแนวทางว่าองค์กรควรสร้างและขอ SBOM อย่างไร
เอกสารนี้ใช้กับ SBOM ของซอฟต์แวร์ทุกชนิด รวมถึงโอเพนซอร์ส ซอฟต์แวร์ AI และ SaaS (ซอฟต์แวร์ที่ให้บริการผ่านคลาวด์) ซอฟต์แวร์ AI และ SaaS อาจต้องมีข้อมูลเพิ่ม ซึ่งอยู่นอกขอบเขตของเอกสารนี้ เชิงอรรถของเอกสารระบุว่า CISA และพันธมิตรกลุ่ม G7 ออกแนวทางแยกอีกฉบับ ชื่อ Software Bill of Materials for AI – Minimum Elements เมื่อพฤษภาคม 2026
รูปแบบ SBOM: CycloneDX และ SPDX
SBOM ต้องเก็บในรูปแบบที่โปรแกรมอ่านได้ เครื่องมือจึงจะค้นและวิเคราะห์ข้อมูลจำนวนมากได้ รูปแบบมาตรฐานที่ใช้กันมี 2 แบบ
- CycloneDX: พัฒนาโดย OWASP Foundation และ Ecma International เผยแพร่เป็นมาตรฐาน ECMA-424 ฉบับที่ 2 (ธันวาคม 2025) ซึ่งกำหนด CycloneDX v1.7 เก็บไฟล์ได้ทั้งแบบ JSON XML (รูปแบบข้อมูลแบบมีแท็ก) และ Protocol Buffers (รูปแบบข้อมูลแบบไบนารี) และรองรับ VEX (เอกสารที่บอกว่าช่องโหว่ที่ประกาศแล้วมีผลกับผลิตภัณฑ์นี้จริงหรือไม่)
- SPDX: spdx.dev อธิบายว่าเป็นมาตรฐานเปิดระดับสากล (อ้างถึง ISO/IEC 5962:2021) หน้าเว็บแสดง SPDX 3.0 เป็นเวอร์ชันปัจจุบัน และไม่ได้ระบุว่ามาตรฐาน ISO ครอบคลุมเวอร์ชันใด
ใช้รูปแบบใดก็ได้ สิ่งที่ควรตรวจมี 2 เรื่อง คือเครื่องมือที่ใช้อยู่สร้างข้อมูลขั้นต่ำข้างต้นได้ครบหรือไม่ และเครื่องมือของฝั่งผู้รับอ่านรูปแบบนั้นได้หรือไม่
SLSA: ทำให้ซอฟต์แวร์ที่สร้างออกมาเชื่อถือได้
SLSA (Supply-chain Levels for Software Artifacts) คือชุดแนวปฏิบัติที่นำไปใช้ได้ทีละขั้น เพื่อป้องกันการแก้ไขซอฟต์แวร์ในทุกขั้นตอน ตั้งแต่ซอร์สโค้ดถึงไฟล์ที่ส่งมอบ ตัวอย่างการแก้ไขที่ต้องป้องกัน เช่น การแก้โค้ดโดยไม่ได้รับอนุญาต ไฟล์ที่ไม่ได้สร้างจากแพลตฟอร์ม CI/CD (ระบบอัตโนมัติที่สร้างและปล่อยซอฟต์แวร์) ตามที่คาดไว้ และการโจมตีแพลตฟอร์มที่ใช้ build ผู้ผลิตใช้ SLSA เสริมความแข็งแรงของห่วงโซ่อุปทานของตน ส่วนผู้ใช้ใช้ตัดสินว่าจะเชื่อถือแพ็กเกจหนึ่งหรือไม่ ตามเว็บไซต์ slsa.dev เวอร์ชันปัจจุบันคือ 1.2 มี Build Track (ระดับ L1 ถึง L3) และ Source Track (เน้นการสร้างและตรวจสอบซอร์สโค้ด)
หัวใจของ Build Track คือ provenance (หลักฐานการสร้าง: ข้อมูลที่ระบุไฟล์ผลลัพธ์ด้วยค่าแฮช และบอกว่าไฟล์นั้นถูกสร้างมาอย่างไร) ระดับ Build มี 3 ขั้น
- L1 มีหลักฐานการสร้าง: ระบบ build สร้างหลักฐานให้ แต่ยังไม่รับประกันว่าแท้หรือถูกต้อง
- L2 หลักฐานตรวจความแท้ได้: ผู้รับตรวจลายเซ็นของหลักฐานได้ และ build รันบนบริการที่มีผู้ให้บริการดูแล ไม่ใช่เครื่องของบุคคล
- L3 หลักฐานปลอมไม่ได้: การ build แต่ละครั้งแยกจากกัน และเข้าถึงความลับของระบบ build ไม่ได้ ผู้ใช้ระบบ build จึงปลอมหลักฐานไม่ได้
L3 ช่วยให้มั่นใจว่า build ที่ผู้ผลิตตั้งใจทำอย่างถูกต้องจะรันอย่างปลอดภัย แต่ไม่ได้ห้ามผู้ผลิตสั่ง build ที่เสี่ยงเอง ซอฟต์แวร์ที่ยังไม่ถึงระดับใดเลยเรียกว่า SLSA 0
ใช้ SBOM และ SLSA ในองค์กรอย่างไร
CISA สรุปสิ่งที่ควรทำไว้ 3 ข้อ คือ ขอ SBOM ที่ตรงตามข้อมูลขั้นต่ำฉบับปรับปรุงใหม่ ใช้เครื่องมือสร้าง นำเข้า และวิเคราะห์ข้อมูล SBOM และสร้าง SBOM ที่ตรงตามข้อมูลขั้นต่ำเอง ในทางปฏิบัติแบ่งตามลักษณะงานได้ดังนี้
- ซอฟต์แวร์ที่องค์กรซื้อหรือจ้างพัฒนา: ใส่ข้อกำหนดให้ส่ง SBOM ไว้ในสัญญาและเกณฑ์จัดซื้อ ระบุรูปแบบและรอบการส่งมอบ และตรวจว่าเครื่องมือของเราอ่านรูปแบบนั้นได้
- ซอฟต์แวร์ที่องค์กรพัฒนาเอง: สร้าง SBOM จากสายงาน build ทุกครั้งที่ปล่อยเวอร์ชันใหม่ และเก็บไว้คู่กับไฟล์ที่ปล่อย เครื่องมือ SCA (ตรวจไลบรารีของบุคคลที่สามว่ามีช่องโหว่หรือไม่) ต้องรู้ว่าซอฟต์แวร์ใช้ส่วนประกอบอะไร ซึ่งเป็นข้อมูลประเภทเดียวกับที่อยู่ใน SBOM ดู DevSecOps: SAST, DAST และ SCA ใช้อย่างไร
- การเก็บและการค้นหา: เก็บ SBOM ทุกชิ้นไว้ในที่เดียวที่ค้นหาได้ เพื่อค้นได้ทันทีเมื่อมีช่องโหว่ใหม่ แล้วส่งเรื่องเข้าสู่ขั้นตอนแพตช์ตามปกติ ดู Patch Management ที่ทำได้จริง
ข้อผิดพลาดที่พบบ่อย
- คิดว่ามี SBOM แล้วจะปลอดภัย: SBOM เป็นแค่รายการข้อมูล ถ้าไม่มีใครนำไปเทียบกับช่องโหว่ใหม่ ก็ไม่ได้ลดความเสี่ยง
- สร้าง SBOM ครั้งเดียวแล้วไม่ปรับปรุง: ซอฟต์แวร์เปลี่ยนไปทุกเวอร์ชัน SBOM เก่าจึงไม่ตรงกับของที่ใช้อยู่จริง
- รับ SBOM มาโดยไม่ตรวจว่าข้อมูลครบ: ข้อมูลบางช่อง เช่น ชื่อผู้ผลิตหรือเวอร์ชัน ขาดหรือคลุมเครือ จนค้นหาส่วนประกอบนั้นไม่ได้
- นับเฉพาะไลบรารีโอเพนซอร์ส: ลืมส่วนประกอบที่ผู้ขายฝังมาให้ เฟิร์มแวร์ และบริการ SaaS ที่ใช้อยู่
- เก็บ SBOM ไว้กับทีมพัฒนาเท่านั้น: ทีมความปลอดภัยเข้าถึงไม่ได้ในวันที่เกิดเหตุ
- ใช้ SBOM แทนการป้องกันระบบ build: SBOM บอกว่ามีอะไรอยู่ข้างใน แต่ไม่ได้บอกว่าถูกแก้ระหว่างการสร้างหรือไม่ จึงต้องมีแนวปฏิบัติแบบ SLSA ควบคู่กันไป
ขั้นแรกที่ทำได้ทันที
- ทำรายการซอฟต์แวร์สำคัญ: เริ่มจากระบบที่เชื่อมต่ออินเทอร์เน็ตหรือเก็บข้อมูลสำคัญ
- ขอ SBOM จากผู้ขายรายสำคัญ: เริ่มจากผู้ขายสองสามราย แล้วดูว่าข้อมูลครบตามข้อมูลขั้นต่ำ 17 อย่างหรือไม่
- ลองสร้าง SBOM ของระบบที่พัฒนาเอง 1 ระบบ: ใช้เครื่องมือที่รองรับ CycloneDX หรือ SPDX แล้วเทียบผลกับข้อมูลขั้นต่ำ
- ลองค้นหาส่วนประกอบ 1 ตัว: เลือกไลบรารี 1 ตัว แล้วหาว่าระบบใดใช้อยู่บ้าง และจับเวลาเพื่อรู้ว่าตอบได้เร็วแค่ไหน
- ประเมินระดับ SLSA Build ของสายงาน build หลัก: ว่าอยู่ที่ SLSA 0 หรือ L1 ถึง L3
- จำกัดสิทธิ์เข้าถึงระบบ build: ให้เฉพาะผู้ที่จำเป็น และเก็บความลับของระบบไว้ห่างจากขั้นตอนที่ผู้ใช้ทั่วไปแก้ไขได้
หากต้องการทราบว่าการจัดการซอฟต์แวร์และผู้ขายขององค์กรอยู่ในระดับใด ลองใช้ แบบประเมินตนเอง
ขอบเขตและความถูกต้อง
รายละเอียดของ 2026 Minimum Elements มาจากไฟล์ PDF ฉบับเต็มและหน้าประกาศของ CISA ซึ่งอ่านเมื่อวันที่ 27 ตุลาคม 2026 ส่วนเวอร์ชันของ CycloneDX SPDX และ SLSA มาจากเว็บไซต์ทางการของแต่ละโครงการในวันเดียวกัน เวอร์ชันและข้อกำหนดเหล่านี้เปลี่ยนแปลงได้ ควรตรวจฉบับล่าสุดก่อนนำไปเขียนเป็นข้อกำหนดในสัญญา เอกสารของ CISA เองระบุว่าไม่ใช่คำแนะนำด้านกฎหมาย หรือด้านการปฏิบัติตามกฎระเบียบ
แหล่งอ้างอิงและข้อมูลเพิ่มเติม
- CISA: 2026 Minimum Elements for a Software Bill of Materials: หน้าประกาศของเอกสาร
- CISA: 2026 Minimum Elements (PDF): ตารางข้อมูล 17 อย่างและแนวปฏิบัติ
- CISA: SBOM: ทรัพยากรด้าน SBOM ของ CISA
- NTIA: Minimum Elements for an SBOM (2021): ข้อมูลขั้นต่ำ 7 อย่างฉบับเดิม
- SLSA: About: SLSA คืออะไร และมี Track อะไรบ้าง
- SLSA: Build requirements: ข้อกำหนดของ Build L1 ถึง L3
- CycloneDX: Specification overview: เวอร์ชันและรูปแบบข้อมูล
- Ecma International: ECMA-424: CycloneDX ในฐานะมาตรฐาน Ecma
- SPDX: Specifications: เวอร์ชันของ SPDX และสถานะมาตรฐาน ISO