ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์
ตรวจสอบไลบรารีจากภายนอกด้วยเครื่องมือ SCA บังคับตรึงเวอร์ชันของสิ่งที่พึ่งพา และผสานการแจ้งเตือนช่องโหว่อัตโนมัติเข้ากับไปป์ไลน์ CI/CD
ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์ เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
ความเสี่ยงจาก dependencies แบบโอเพนซอร์ส
แอปพลิเคชันสมัยใหม่ประกอบขึ้นจาก ไลบรารีและเฟรมเวิร์กโอเพนซอร์สของบุคคลที่สาม เป็นส่วนใหญ่ แอปพลิเคชัน Node.js ทั่วไปอาจมี dependencies แบบส่งต่อมากกว่า 1,000 รายการ ส่วนโครงการ Java อาจดึงอาร์ติแฟกต์ Maven เข้ามาหลายร้อยรายการ แต่ละ dependency เป็นพื้นผิวการโจมตีที่อาจเกิดขึ้นได้ ช่องโหว่ Log4Shell (CVE-2021-44228) ในไลบรารี Log4j แสดงให้เห็นว่า dependency เพียงรายการเดียวอาจทำให้แอปพลิเคชันหลายล้านรายการทั่วโลกถูกโจมตีได้ทันทีภายในไม่กี่วันหลังการเปิดเผย
การวิเคราะห์องค์ประกอบซอฟต์แวร์คืออะไร
เครื่องมือ การวิเคราะห์องค์ประกอบซอฟต์แวร์ (SCA) จะจัดทำรายการส่วนประกอบโอเพนซอร์สทั้งหมดในแอปพลิเคชันโดยอัตโนมัติ รวมถึง dependencies แบบส่งต่อ (dependencies ของ dependencies ของคุณ) และตรวจสอบอย่างต่อเนื่องกับฐานข้อมูลช่องโหว่เพื่อค้นหา CVE ที่ทราบแล้ว SCA จะสร้าง รายการส่วนประกอบซอฟต์แวร์ (SBOM) ซึ่งแสดงส่วนประกอบและเวอร์ชันทั้งหมด ทำให้ระบุระบบที่ได้รับผลกระทบได้อย่างรวดเร็วเมื่อมีการเปิดเผยช่องโหว่ใหม่
# SCA tool usage examples:
# npm audit (Node.js):
# npm audit
# -> Reports vulnerabilities in package.json dependencies
# -> Shows severity, CVE ID, affected package, fix version
# OWASP Dependency-Check (Java/Python/etc.):
# dependency-check --project 'MyApp' --scan ./lib/
# -> Generates HTML/XML report with CVE findings
# Snyk scan:
# snyk test
# -> Reports vulns + 'snyk fix' applies patches automaticallyDependencies แบบส่งต่อ: ความเสี่ยงที่ซ่อนอยู่
Dependencies แบบส่งต่อ คือไลบรารีที่ dependencies โดยตรงของคุณใช้งานต่ออีกทอดหนึ่ง ซึ่งคุณไม่ได้เลือกไว้โดยตรง คุณอาจใช้งาน Package A โดยตรง ซึ่งขึ้นอยู่กับ Package B (เวอร์ชัน 1.2) และ Package B ขึ้นอยู่กับ Package C (เวอร์ชัน 3.0 ซึ่งเป็นเวอร์ชันที่มีช่องโหว่) คุณไม่ทราบว่ามี Package C อยู่ แต่แอปพลิเคชันของคุณเรียกใช้งานมัน เครื่องมือ SCA จะไล่ตรวจสอบโครงสร้าง dependencies ทั้งหมดเพื่อเปิดเผยช่องโหว่ที่ซ่อนอยู่เหล่านี้ ซึ่งนักพัฒนาไม่สามารถมองเห็นได้โดยตรง
# Dependency tree example:
# Your package.json:
# 'express': '^4.18.0' (direct dependency)
# 'lodash': '^4.17.21' (direct dependency)
# Transitive dependencies (you didn't choose these):
# express -> 'qs' 6.11.0 (URL parsing)
# express -> 'body-parser' 1.20 -> 'qs' 6.11.0
# lodash (self-contained in this case)
# If 'qs' 6.10.x had a prototype pollution CVE,
# you are vulnerable via express even though
# you never directly imported 'qs'.รายการส่วนประกอบซอฟต์แวร์ (SBOM)
รายการส่วนประกอบซอฟต์แวร์ (SBOM) คือรายการส่วนประกอบทั้งหมดในผลิตภัณฑ์ซอฟต์แวร์ที่มีรูปแบบเป็นทางการและเครื่องสามารถอ่านได้ คล้ายกับรายการส่วนผสมอาหาร รูปแบบของ SBOM ได้แก่ SPDX (Linux Foundation) และ CycloneDX (OWASP) คำสั่งฝ่ายบริหารของ US ฉบับที่ 14028 (2021) กำหนดให้ซอฟต์แวร์ที่จำหน่ายแก่รัฐบาลกลางต้องมี SBOM เมื่อมี SBOM ทีมรักษาความปลอดภัยสามารถค้นหาได้ทันทีว่า “ผลิตภัณฑ์ใดของเรามี Log4j อยู่บ้าง” และได้คำตอบภายในไม่กี่นาที แทนที่จะต้องค้นหาด้วยตนเองเป็นเวลาหลายวัน
# Generate SBOM with syft:
# syft packages . -o spdx-json > sbom.spdx.json
# SBOM content example (SPDX JSON):
# {
# 'packages': [
# { 'name': 'express', 'version': '4.18.2', 'license': 'MIT' },
# { 'name': 'lodash', 'version': '4.17.21','license': 'MIT' },
# { 'name': 'log4j-core','version': '2.14.0','license': 'Apache-2.0'}
# ]
# }
# When Log4Shell announced, query SBOM:
# grep -i 'log4j-core' sbom.spdx.json -> FOUND in 3 projectsการตรึงเวอร์ชัน Dependencies และไฟล์ล็อก
การตรึงเวอร์ชัน dependencies จะระบุเวอร์ชันที่แน่นอนของ dependencies แทนช่วงเวอร์ชันที่ยืดหยุ่น (^1.2.3 หรือ *) ไฟล์ล็อก (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) จะบันทึกเวอร์ชันที่แก้ไขแล้วอย่างแน่นอนของ dependency ทุกตัวขณะติดตั้ง ควร ส่งไฟล์เหล่านี้เข้าไปในการควบคุมซอร์สโค้ด เพื่อให้สมาชิกทีมทุกคนและไปป์ไลน์ CI/CD ใช้เวอร์ชัน dependencies เดียวกัน ป้องกันการโจมตีห่วงโซ่อุปทานที่ทำให้เวอร์ชันแพ็กเกจเป็นอันตรายระหว่างการติดตั้งแต่ละครั้ง
# Version range vs pinned versions:
# FLEXIBLE (can pull different versions each install):
# 'express': '^4.0.0' -> installs latest 4.x.x
# 'lodash': '*' -> installs any version!
# PINNED (always same version):
# 'express': '4.18.2' -> always exactly 4.18.2
# Lock file (package-lock.json):
# Records EXACT resolved version of every transitive dep.
# Commit this file! It ensures reproducible builds.
# Never .gitignore lock files (security anti-pattern).การโจมตีห่วงโซ่อุปทาน: การปลอมชื่อให้คล้ายและความสับสนของ Dependencies
การโจมตีห่วงโซ่อุปทานมุ่งเป้าไปที่ระบบนิเวศของ dependencies การปลอมชื่อให้คล้าย คือการเผยแพร่แพ็กเกจอันตรายที่มีชื่อคล้ายแพ็กเกจยอดนิยม (เช่น lodahs แทน lodash) โดยหวังว่านักพัฒนาจะพิมพ์ชื่อผิด การโจมตีด้วยความสับสนของ dependency ใช้ประโยชน์จากลำดับที่ตัวจัดการแพ็กเกจค้นหารีจิสทรี ผู้โจมตีเผยแพร่แพ็กเกจอันตรายที่มีชื่อเดียวกับแพ็กเกจส่วนตัวภายใน แต่มีหมายเลขเวอร์ชันสูงกว่า ทำให้ตัวจัดการแพ็กเกจติดตั้งเวอร์ชันสาธารณะที่เป็นอันตรายแทน
# Dependency Confusion Attack (Alex Birsan 2021):
# Company uses internal package 'company-utils' v1.0.0
# Hosted on: internal.registry.company.com
# Attacker publishes 'company-utils' v9.9.9 to npmjs.com
# (public registry with higher version number)
# npm install resolves: 'find highest version across ALL registries'
# -> Installs v9.9.9 from public npm (attacker's malicious package!)
# -> Instead of v1.0.0 from internal registry
# Defense: use namespace scoping (@company/utils)
# or configure npm to ONLY use internal registry for private packagesเครื่องมือ SCA ในตลาด
มีการใช้เครื่องมือ SCA หลายรายการอย่างแพร่หลายในอุตสาหกรรม Snyk ให้บริการสแกน dependencies ที่ใช้งานง่ายสำหรับนักพัฒนา พร้อมคำขอรวมเพื่อแก้ไขโดยอัตโนมัติ การตรวจสอบ Dependencies ของ OWASP เป็นเครื่องมือฟรีที่ได้รับการยอมรับอย่างกว้างขวางสำหรับ Java, .NET, Python และ Ruby GitHub Dependabot จะเปิดคำขอรวมโดยอัตโนมัติเพื่ออัปเดต dependencies ที่มีช่องโหว่ในคลัง GitHub JFrog Xray และ Sonatype Nexus IQ ผสาน SCA เข้ากับคลังอาร์ติแฟกต์เพื่อบล็อกการสร้างที่มีช่องโหว่ไม่ให้เข้าสู่ระบบจริง
การผสาน SCA เข้ากับไปป์ไลน์ CI/CD
SCA มีประสิทธิภาพสูงสุดเมื่อผสานเป็น ด่านตรวจคุณภาพในไปป์ไลน์ CI/CD ในทุกคำขอรวมและการสร้าง ไปป์ไลน์จะเรียกใช้เครื่องมือ SCA และทำให้การสร้างไม่ผ่านหากพบ CVE ระดับวิกฤตหรือสูง ใน dependencies แนวทาง “เลื่อนการรักษาความปลอดภัยไปทางซ้าย” นี้ตรวจพบ dependencies ที่มีช่องโหว่ก่อนเข้าสู่ระบบจริง ไม่ใช่หลายเดือนต่อมาระหว่างการตรวจสอบความปลอดภัยด้วยตนเองหรือหลังเกิดการรั่วไหล ทีมควรกำหนดเกณฑ์ความรุนแรงของช่องโหว่ที่ชัดเจน เพื่อระบุว่าระดับใดต้องบล็อกการนำไปใช้งาน และระดับใดเพียงสร้างคำเตือน
# GitHub Actions SCA pipeline step:
# - name: Run Snyk SCA scan
# uses: snyk/actions/node@master
# env:
# SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
# with:
# args: --severity-threshold=high
# --fail-on=upgradable
# # Build fails if any HIGH or CRITICAL vuln found
# # that has an available fix (--fail-on=upgradable)
# # No fix available? Generates warning, doesn't block
# # (acknowledging risk explicitly is better than blocking forever)การประเมินความสมบูรณ์ของแพ็กเกจโอเพนซอร์ส
ก่อนเพิ่ม dependency ให้ประเมินสถานะด้านความปลอดภัยโดยใช้สัญญาณหลายด้าน กิจกรรมการดูแลรักษา: โครงการได้รับการดูแลอย่างต่อเนื่องหรือไม่ มีการส่งการเปลี่ยนแปลงและออกรุ่นครั้งล่าสุดเมื่อใด ประวัติช่องโหว่ที่ทราบ: เคยมี CVE กี่รายการ และแก้ไขได้รวดเร็วเพียงใด ปริมาณการดาวน์โหลด: แพ็กเกจที่มีผู้ใช้งานอย่างแพร่หลายจะได้รับการตรวจสอบด้านความปลอดภัยมากกว่า จำนวน dependencies: แพ็กเกจที่มี dependencies น้อยกว่าจะก่อให้เกิดความเสี่ยงแบบส่งต่อน้อยกว่า OpenSSF Scorecard ให้คะแนนแนวปฏิบัติด้านความปลอดภัยของโครงการโอเพนซอร์สโดยอัตโนมัติ
กลยุทธ์การแก้ไขช่องโหว่
เมื่อ SCA ระบุ dependency ที่มีช่องโหว่ จะมีกลยุทธ์การแก้ไขหลายรูปแบบ อัปเกรด เป็นเวอร์ชันที่แก้ไขแล้ว ซึ่งเป็นตัวเลือกที่แนะนำเมื่อมีให้ใช้ การแก้ไขเสมือน ผ่านกฎของ WAF สามารถลดผลกระทบจากช่องทางการโจมตีที่ทราบแล้วระหว่างเตรียมการอัปเกรด นำออก หากไม่จำเป็นต้องใช้ dependency นั้นอีกต่อไป ยอมรับความเสี่ยง พร้อมเหตุผลที่บันทึกไว้ หากช่องโหว่นั้นไม่สามารถใช้โจมตีได้ในบริบทการใช้งานเฉพาะ (เช่น ช่องโหว่ฝั่งเซิร์ฟเวอร์ในไลบรารีฝั่งไคลเอ็นต์) ห้ามปล่อยช่องโหว่ระดับวิกฤตไว้โดยไม่แก้ไขหรือไม่มีการยอมรับความเสี่ยงที่บันทึกไว้
การปฏิบัติตามใบอนุญาตใน Dependencies
เครื่องมือ SCA มีจุดประสงค์สองด้าน: ระบุช่องโหว่ด้านความปลอดภัย และ แจ้งปัญหาการปฏิบัติตามใบอนุญาตใน dependencies แบบโอเพนซอร์ส ใบอนุญาตที่มักก่อปัญหา ได้แก่ GPL v2/v3 (ลิขสิทธิ์แบบแพร่ต่อ ซึ่งกำหนดให้ผลิตภัณฑ์ของคุณต้องเปิดซอร์สด้วยหากมีการแจกจ่าย) AGPL (ขยาย GPL ไปยังบริการเครือข่าย) และ SSPL การใช้ไลบรารีที่มีใบอนุญาต GPL ในซอฟต์แวร์เชิงพาณิชย์แบบกรรมสิทธิ์โดยไม่มีใบอนุญาตเชิงพาณิชย์อาจก่อให้เกิดความรับผิดทางกฎหมายอย่างร้ายแรง เครื่องมือ SCA อย่าง FOSSA, Black Duck และ WhiteSource ทำให้การสแกนใบอนุญาตทำงานโดยอัตโนมัติควบคู่กับการตรวจหาช่องโหว่ เพื่อให้ปฏิบัติตามภาระผูกพันของโอเพนซอร์ส
# License compliance risk levels:
# PERMISSIVE (low risk for commercial use):
# MIT, Apache 2.0, BSD 2/3-Clause
# -> Can use in proprietary code, just keep attribution
# WEAK COPYLEFT (medium risk - check usage):
# LGPL -> can link dynamically without open-sourcing your code
# MPL 2.0 -> modifications to MPL files must be open-sourced
# STRONG COPYLEFT (high risk for proprietary products):
# GPL v2, GPL v3 -> if you distribute code using GPL library,
# your entire product must also be GPL
# AGPL -> extends GPL to SaaS/network services
# SCA policy: block AGPL/GPL in commercial product
# -> Review any exception requests manuallyตรวจสอบอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า เครื่องมือ SCA สแกนโครงสร้าง dependencies ทั้งหมด รวมถึง dependencies แบบส่งต่อเพื่อค้นหา CVE ที่ทราบแล้ว SBOM ให้รายการส่วนประกอบที่เครื่องอ่านได้ ซึ่งช่วยให้ตอบสนองได้อย่างรวดเร็วเมื่อมีการเปิดเผยช่องโหว่ใหม่ และ การผสาน SCA เป็นด่านตรวจคุณภาพของ CI/CD จะตรวจจับ dependencies ที่มีช่องโหว่ก่อนเข้าสู่ระบบจริง ต่อไปเราจะเรียนรู้ DevSecOps และวิธีเลื่อนการควบคุมความปลอดภัยไปทางซ้ายเข้าสู่ไปป์ไลน์ CI/CD ทั้งหมด
คำถามที่พบบ่อย
บทเรียน “ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์”
ตรวจสอบไลบรารีจากภายนอกด้วยเครื่องมือ SCA บังคับตรึงเวอร์ชันของสิ่งที่พึ่งพา และผสานการแจ้งเตือนช่องโหว่อัตโนมัติเข้ากับไปป์ไลน์ CI/CD คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน
บทเรียน “ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม
ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การตรวจสอบข้อมูลนำเข้าและการเข้ารหัสข้อมูลส่งออก
- การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม
- ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์
- DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์