SBOM คืออะไร? เมื่อซอฟต์แวร์หนึ่งตัวไม่ได้มีแค่โค้ดที่เรามองเห็น แต่ประกอบด้วยส่วนต่างๆ มากมาย ถ้าหากส่วนประกอบเหล่านี้มีช่องโหว่ องค์กรจะรู้ได้อย่างไรว่าซอฟต์แวร์ของตัวเองได้รับผลกระทบหรือไม่?
ในโลกที่ซอฟต์แวร์หนึ่งตัวไม่ได้ถูกสร้างขึ้นจากโค้ดของบริษัทเพียงอย่างเดียว แต่ประกอบขึ้นจาก Open Source Library, Framework, Package และ Component จากผู้พัฒนาหลายราย ความเสี่ยงด้านความปลอดภัยจึงไม่ได้อยู่เฉพาะในโค้ดที่องค์กรเขียนเอง แต่อาจซ่อนอยู่ในส่วนประกอบที่ถูกนำเข้ามาจากภายนอกด้วย นี่คือเหตุผลที่ Software Bill of Materials หรือ SBOM กลายเป็นเครื่องมือสำคัญในการเพิ่มความโปร่งใสให้กับ Software Supply Chain โดย CISA ระบุว่า SBOM เป็นหนึ่งในองค์ประกอบสำคัญของการรักษาความปลอดภัยซอฟต์แวร์และการบริหารความเสี่ยงของห่วงโซ่อุปทานซอฟต์แวร์
SBOM คืออะไร?
SBOM หรือ Software Bill of Materials คือบัญชีรายการส่วนประกอบและความสัมพันธ์ของส่วนประกอบต่าง ๆ ที่ถูกนำมาใช้สร้างซอฟต์แวร์ เปรียบเสมือน “ฉลากส่วนผสม” ที่บอกว่าสินค้าซอฟต์แวร์หนึ่งตัวประกอบด้วย Open Source, Library, Package และ Dependency อะไรบ้าง รวมถึงข้อมูลที่ช่วยระบุ Component เหล่านั้นได้อย่างชัดเจน
จุดสำคัญคือ SBOM ทำให้องค์กรมองเห็นโครงสร้างภายในของซอฟต์แวร์และ Software Supply Chain ได้มากขึ้น เมื่อเกิดช่องโหว่ใน Component ใด องค์กรจึงสามารถตรวจสอบได้รวดเร็วว่าซอฟต์แวร์ของตนมีส่วนประกอบนั้นอยู่หรือไม่ และช่วยประเมินความเสี่ยงเพื่อจัดการหรือแก้ไขได้อย่างตรงจุด
มีอะไรอยู่ข้างใน SBOM
หัวใจของ SBOM คือข้อมูลที่ช่วยระบุ Component แต่ละตัวให้ได้อย่างชัดเจน เพื่อให้สามารถติดตาม ตรวจสอบ และเชื่อมโยงข้อมูลกับแหล่งข้อมูลด้านความปลอดภัยอื่น ๆ ได้ แนวทาง 2025 CISA Minimum Elements กำหนดข้อมูลสำคัญหลายรายการ เช่น ผู้จัดทำ SBOM ผู้ผลิตซอฟต์แวร์ ชื่อและเวอร์ชันของ Component, Software Identifier, Component Hash, License, ความสัมพันธ์ของ Dependency, เครื่องมือที่ใช้สร้าง SBOM, Timestamp และบริบทของการสร้าง SBOM
นอกจากนี้ยังให้ความสำคัญกับเรื่อง Automation, ความถี่ในการอัปเดต, ขอบเขตของ Component ที่ครอบคลุม และการระบุ “Known Unknowns” หรือสิ่งที่ยังไม่สามารถระบุได้ ข้อมูลเหล่านี้ทำให้ SBOM มีคุณค่ามากกว่าการเป็นเพียงรายชื่อ Library เพราะสามารถใช้ระบุตัว Component เดียวกันข้ามระบบและนำไปเชื่อมกับข้อมูลช่องโหว่หรือข้อมูล License ได้ เมื่อเกิดเหตุการณ์ด้านความปลอดภัย องค์กรจึงสามารถย้อนกลับไปตรวจสอบได้ว่า Component ที่มีปัญหาถูกใช้อยู่ที่ใดบ้าง
SBOM ช่วยแก้ปัญหาอะไร?
หนึ่งในเหตุผลที่ SBOM มีความสำคัญขึ้นอย่างมากคือ องค์กรอาจไม่ได้ถูกโจมตีผ่านซอฟต์แวร์ที่ตัวเองเขียน แต่ผ่าน Component ที่ซอฟต์แวร์นั้นพึ่งพาอยู่ หาก Library ตัวหนึ่งมีช่องโหว่ การค้นหาว่าระบบใดได้รับผลกระทบโดยไม่มีข้อมูล Component ที่เป็นระบบอาจต้องใช้เวลามาก แต่หากมี SBOM องค์กรสามารถนำข้อมูลดังกล่าวไปเปรียบเทียบกับ Security Advisory หรือฐานข้อมูลช่องโหว่ เพื่อค้นหาว่าซอฟต์แวร์ใดมี Component ที่ตรงกับปัญหา CISA ระบุถึงการนำ SBOM ไป Correlate กับ Security Advisories เพื่อช่วยให้เกิดประโยชน์ด้านการจัดการความเสี่ยงมากขึ้น แนวทางร่วมที่ CISA, NSA และหน่วยงานความมั่นคงไซเบอร์จากหลายประเทศเผยแพร่ในเดือนกันยายน 2025 ก็เน้นให้ผู้ผลิต ผู้เลือกซื้อ และผู้ใช้งานซอฟต์แวร์นำการสร้าง วิเคราะห์ และแบ่งปัน SBOM เข้าไปเป็นส่วนหนึ่งของกระบวนการรักษาความปลอดภัยที่มีอยู่แล้ว ดังนั้น เมื่อเกิดช่องโหว่ SBOM ไม่ได้ทำหน้าที่ “ป้องกันการโจมตี” โดยตรง แต่ช่วยให้องค์กรตอบคำถามสำคัญได้เร็วขึ้นว่า “เราได้รับผลกระทบหรือไม่ และต้องแก้ตรงไหน?”
SBOM ทำงานอย่างไร?
SBOM จะมีประโยชน์ก็ต่อเมื่อถูกนำเข้าสู่กระบวนการทำงานจริง ไม่ใช่สร้างไฟล์ขึ้นมาแล้วเก็บไว้เฉย ๆ กระบวนการสามารถเริ่มตั้งแต่การสร้าง SBOM ระหว่างการพัฒนาและ Build ซอฟต์แวร์ จากนั้นส่งต่อให้ผู้ใช้งานหรือทีมรักษาความปลอดภัยนำไปวิเคราะห์ ตรวจสอบ Dependency และเชื่อมโยงกับข้อมูลช่องโหว่ เมื่อ Component มีการเปลี่ยนแปลง SBOM ก็ควรถูกปรับปรุงให้สอดคล้องกับซอฟต์แวร์เวอร์ชันใหม่ โดย CISA ให้ความสำคัญกับ Automation Support, Frequency, Coverage, Distribution and Delivery และการรองรับการอัปเดตข้อมูล SBOM ในด้านรูปแบบข้อมูลก็มีมาตรฐานที่ช่วยให้เครื่องมือสามารถแลกเปลี่ยนและประมวลผลข้อมูลได้ เช่น SPDX และ CycloneDX ซึ่ง NIST ระบุเป็นรูปแบบที่ใช้สำหรับ SBOM ขณะที่ CycloneDX ปัจจุบันเป็นมาตรฐาน ECMA-424 เป้าหมายสำคัญจึงไม่ใช่แค่ “มี SBOM” แต่คือการทำให้ข้อมูลสามารถถูกสร้าง ส่งต่อ อ่าน วิเคราะห์ และเชื่อมเข้ากับระบบ Security Toolchain ได้โดยอัตโนมัติ
จาก “บัญชีส่วนประกอบ” สู่ระบบบริหารความเสี่ยง
ทิศทางของ SBOM กำลังเปลี่ยนจากการเป็นเอกสารที่ใช้บอกว่า “ซอฟต์แวร์ประกอบด้วยอะไร” ไปสู่การเป็นข้อมูลพื้นฐานสำหรับ Software Supply Chain Risk Management ในระดับองค์กรและอุตสาหกรรม แนวทาง CISA ฉบับปี 2025 ขยายขอบเขตการพูดถึง SBOM ไปถึง SaaS ใน Cloud Environment และ AI Software Systems พร้อมทั้งให้ความสำคัญกับการตรวจสอบความถูกต้องและการเชื่อมโยง SBOM กับ Security Advisory ขณะเดียวกัน แนวทาง “A Shared Vision of Software Bill of Materials for Cybersecurity” ที่เผยแพร่ร่วมโดย CISA, NSA และหน่วยงานจากหลายประเทศ สะท้อนให้เห็นว่า SBOM กำลังถูกผลักดันให้เป็นแนวทางร่วมระดับนานาชาติในการเพิ่มความโปร่งใสของ Software Supply Chain เมื่อซอฟต์แวร์มีความซับซ้อนมากขึ้น ตั้งแต่ Cloud, Open Source ไปจนถึง AI การรู้ว่า “เราใช้ซอฟต์แวร์อะไร” จึงไม่เพียงพออีกต่อไป แต่ต้องรู้ด้วยว่า ซอฟต์แวร์นั้นสร้างจากอะไร มาจากไหน เชื่อมโยงกับอะไร และมีความเสี่ยงตรงจุดใด และนี่คือบทบาทที่ทำให้ SBOM มีแนวโน้มกลายเป็นหนึ่งในโครงสร้างพื้นฐานสำคัญของ Cybersecurity ในยุค Software Supply Chain
อ้างอิง nsa.gov https://media.defense.gov cisa.gov และ cover iT24Hrs
อ่านบทความและข่าวอื่นๆเพิ่มเติมได้ที่ it24hrs.com
SBOM คืออะไร? กุญแจสำคัญสู่ความปลอดภัยของ Software Supply Chain
อย่าลืมกดติดตามอัพเดตข่าวสาร ทิปเทคนิคดีๆกันนะคะ Please follow us
Youtube it24hrs
Twitter it24hrs
Tiktok it24hrs
facebook it24hrs
ติดต่อโฆษณา [email protected] โทร 080234502
