บทที่ 8: Secure Software Supply Chain

บทนี้ปิดวงจร CSSLP ด้วยการติดตาม software, service, build tool และ supplier จาก แหล่งกำเนิดไปจนถึงการใช้งานจริง การเปลี่ยนแปลง และการออกจากระบบ คุณจะได้แยก inventory, Software Bill of Materials (SBOM), integrity, authenticity, provenance, pedigree, supplier assurance และ contractual remedy ออกจากกัน เพราะหลักฐานแต่ละชนิด ตอบคนละคำถามและไม่มีชิ้นใดรับประกันว่า third-party software “ปลอดภัย” โดยตัวเอง

[!IMPORTANT] คู่มือนี้เป็นเอกสารเตรียมสอบที่จัดทำขึ้นเอง ไม่ใช่ official ISC2 material, ไม่ได้รับการรับรองจาก ISC2 และไม่มี exam dump คำถามท้ายบทเป็น “ข้อฝึก” ที่ สร้างขึ้นเพื่อทบทวนเหตุผลเท่านั้น

ขอบเขตเริ่มตั้งแต่การกำหนด software supply chain risk management (SCRM), การระบุ และคัดเลือก component, การประเมิน third-party software, การพิสูจน์ pedigree และ provenance, การกำหนด acquisition requirements ไปจนถึง contract, support และ exit เมื่อ production พบ component ใหม่ ช่องโหว่ เหตุการณ์ หรือความล่าช้าจาก supplier ข้อมูลต้องย้อนกลับสู่ lifecycle governance, requirements, architecture, implementation, testing และ operations เป็น closed loop ไม่ใช่จบที่ procurement approval

วัตถุประสงค์การเรียนรู้และ exam outline mapping

เมื่อเรียนบทนี้จบ คุณต้องอธิบายได้ว่าควรถามคำถามใดต่อ component, supplier, delivery path และ contract และต้องเลือก evidence กับ treatment ตาม risk ของบริบทได้ ตารางต่อไปนี้ map เนื้อหากับ objective ของ Domain 8 ตาม master outline

Objective	สิ่งที่คุณต้องทำได้	ประเด็นที่บทนี้ครอบคลุม
8.1 Implement software supply chain risk management	สร้างวงจร SCRM ที่เชื่อม governance กับ effective inventory	ISO/NIST context, component identification/selection, risk treatment, SBOM, inventory, continuous change และ vulnerability monitoring
8.2 Analyze security of third-party software	ประเมิน software ตาม fitness และ evidence ไม่ใช่ชื่อเสียง	certification, assessment report, origin, maintenance/support, privilege, vulnerability, lifecycle และ exit
8.3 Verify pedigree and provenance	พิสูจน์ที่มาและเส้นทางของ source/component/artifact ตาม policy	pedigree, provenance, secure transfer, chain of custody, interconnection, repository/build security, hash, signature และ right to audit
8.4 Ensure and verify supplier security requirements in acquisition	แปลง risk เป็นข้อกำหนดที่วัดและตรวจได้ตลอดสัญญา	supplier SSDLC, audit, incident/vulnerability notification, response/coordination/reporting, support model, licensing, track record, test scope, shared responsibility และ SIEM log integration
8.5 Support contractual requirements	เชื่อม control objective กับ enforceable allocation และ remedy	intellectual property, code escrow, liability, warranty, EULA, SLA, evidence, change, termination และ transition

การจำชื่อ artifact ไม่พอต่อข้อสอบเชิงสถานการณ์ คุณต้องจับลำดับให้ได้ว่าองค์กรเริ่ม จาก asset/mission และ threat scenario กำหนด requirements เลือกและประเมิน supplier ตรวจ evidence ตัดสิน residual risk แล้วเฝ้าระวัง effective state จนเลิกใช้

แนวคิดหลัก

Supply chain ไม่ใช่แค่รายการ open source libraries แต่เป็นระบบของ people, organizations, source, dependencies, build tools, repositories, signing services, distribution channels, managed services, update authorities และ subcontractors ที่ ร่วมสร้างหรือเปลี่ยน software ที่องค์กรพึ่งพา การ compromise จุดหนึ่งอาจเผยแพร่ผ่าน trust path ที่ถูกต้องในเชิงเทคนิคได้ จึงต้องวิเคราะห์ทั้ง component risk และ systemic risk

8.1 Software supply chain risk management เป็นวงจร

Software SCRM นำ governance และ risk management มาจัดการความไม่แน่นอนที่เกิดจาก สิ่งซึ่งองค์กรไม่ได้ควบคุมทั้งหมด แนวคิดใน ISO risk management และแนวปฏิบัติด้าน cybersecurity supply chain ของ NIST ช่วยจัดโครงคำถาม เช่น context, roles, identification, analysis, treatment, communication, monitoring และ improvement แต่ องค์กรต้องตรวจ standard/version และ obligations ที่ใช้จริงกับ authoritative source ก่อนกำหนด compliance claim

วงจรที่ใช้ได้จริงมีขั้นตอนต่อไปนี้

1. Establish context and governance: กำหนด mission, risk appetite/tolerance, criticality, data, required assurance, roles, authority, supplier tiers และ escalation route
2. Map the supply chain: ระบุ direct/transitive dependencies, services, toolchains, repositories, update channels, subcontractors, privileged access, data flow และ geographic/organizational concentration
3. Identify and analyze scenarios: เชื่อม threat, weakness, exposure, dependency criticality, replaceability, supportability และ impact โดยไม่ใช้ vulnerability count เป็น risk score อัตโนมัติ
4. Select and treat: เลือก component/supplier แล้ว avoid, mitigate, share/transfer หรือ accept risk ผ่าน architecture, technical controls, process, contract และ authorized exception
5. Verify and admit: ตรวจ identity, version, source, evidence, license, policy และ intended use ก่อน component เข้าสู่ approved repository หรือ build
6. Monitor and respond: reconcile effective inventory, รับ advisory/finding, ประเมิน reachability/exposure, ประสาน supplier, patch/replace/isolate และติดตาม fleet closure
7. Learn and exit: นำ incident, support delay, audit result และ lifecycle change กลับไปปรับ requirements, selection, architecture, tests, contract และ exit plan

แผนภาพต่อไปนี้แสดง closed loop ที่เชื่อมทั้งแปด Domain โดย supply-chain governance ไม่ได้เกิดหลัง coding แต่เริ่มจาก lifecycle strategy และ requirements

แผนภาพนี้เน้นว่า procurement record ไม่ใช่ปลายทาง ตัวอย่างเช่น incident ใน production อาจเผยว่า supplier logging ไม่พอ ทีมต้องทำ containment ในบทที่ 7 พร้อม ย้อนมาแก้ acquisition requirement, shared responsibility, test case และ SLA ในบทนี้

การจำแนกสิ่งที่มักถูกใช้แทนกันผิด

ผู้สอบควรแยกคำต่อไปนี้ด้วย “คำถามที่ artifact ตอบ” ไม่ใช่จำว่าชิ้นไหนดีกว่า

แนวคิด	คำถามที่ตอบ	สิ่งที่ไม่พิสูจน์โดยตัวเอง
Inventory	ตอนนี้เรามี/ใช้ component, service หรือ tool ใด ที่ไหน owner ใคร	dependency relation ที่ครบ, origin, integrity หรือความปลอดภัย
SBOM	product/build ที่ระบุประกอบด้วย identity/version/relation ใดตาม scope	effective deployment, absence of omitted component, vulnerability, provenance หรือ license compliance
Integrity	bytes/record เปลี่ยนจาก trusted reference หรือไม่	ใครเป็นผู้สร้าง หรือ reference นั้นดี/ปลอดภัยหรือไม่
Authenticity	identity/origin claim ตรวจได้ตาม credential และ trust policy หรือไม่	process ที่สร้างสิ่งนั้น secure หรือ signer มี authority ต่อ release นี้หรือไม่
Provenance	artifact มาจาก inputs, process, builder และ transformations ใด	source ไม่มี malicious code, test ผ่าน หรือทุก step เชื่อถือได้
Pedigree	ประวัติ/คุณลักษณะของ origin, maintainer, process และ component สนับสนุนความเชื่อระดับใด	current version ปลอดภัย หรือ delivery ครั้งนี้ไม่ถูกสับเปลี่ยน
Supplier assurance	evidence ทำให้เชื่อ supplier controls/claims ใน scope ใด	component ทุก version หรือ customer configuration ได้รับ coverage
Contractual remedy	เมื่อ commitment ไม่เป็นจริง ใครต้องทำอะไรและมี consequence/exit ใด	prevention, detection หรือ technical control effectiveness ก่อน breach

ตัวอย่างที่พบบ่อยคือ checksum จากหน้า download ช่วยตรวจ integrity เมื่อหน้าและไฟล์ ไม่ได้ถูก compromise ร่วมกัน แต่ไม่ยืนยัน author โดยตัวเอง Digital signature เพิ่ม authentication ของ signer ภายใต้ key/trust policy แต่ยังต้องตรวจ authority, purpose, time, revocation และ binding กับ artifact/version การมี valid signature จาก key ที่ถูก ขโมยอาจส่ง malicious artifact ที่ “ตรวจผ่าน” ได้

Component identity และ effective inventory

การจัดการเริ่มจากรู้ว่า “อะไร” ถูกใช้จริง Identity ที่ดีต้องละเอียดพอแยก supplier, namespace/name, version, variant, platform, distribution source, immutable digest, build/configuration และ relation ได้ ชื่อ package อย่างเดียวไม่พอเพราะชื่อคล้ายกัน, namespace takeover, fork และ rebuild อาจให้ bytes ต่างกัน

Inventory และ SBOM มีบทบาทต่างกันแต่ต้อง reconcile กัน

• Source/dependency manifest แสดงสิ่งที่ developer ตั้งใจขอ อาจมี version range
• Resolved lock/build graph แสดง version ที่ resolver เลือก รวม transitive edge
• Build SBOM แสดงสิ่งที่ tool ตรวจพบหรือประกาศใน artifact/build scope นั้น
• Release package bind artifact digest กับ manifest/SBOM, tests, exception และ approval
• Deployment inventory แสดง artifact/service/version ที่ระบบ deploy ตาม record
• Effective runtime inventory ยืนยันสิ่งที่โหลด รัน หรือเรียกใช้จริง รวม plugin, sidecar, runtime download, hosted API และ configuration-dependent dependency

ความต่างระหว่างชั้นเหล่านี้เป็น signal เช่น build SBOM ระบุ library รุ่นหนึ่ง แต่ runtime โหลด plugin อีกแหล่งหนึ่ง หรือ managed service เปลี่ยน backend โดยไม่เปลี่ยน client package ทีมต้องระบุ owner และทำ impact analysis ไม่เติม inventory ให้ตรงกัน เฉย ๆ

แผนภาพนี้แสดง reconciliation ซึ่งทำให้ SBOM เป็น input ของ decision ไม่ใช่ certificate ว่าระบบปลอดภัย

การเก็บ inventory โดยไม่มี cadence, freshness, owner และ coverage ทำให้ทีมตอบเหตุ ไม่ได้ ส่วนการสร้าง SBOM ทุก build แต่ไม่ผูกกับ artifact digest และ effective deployment ทำให้ค้นเจอ component แต่ไม่รู้ว่า production ใดได้รับผล

Component identification, selection และ risk treatment

การเลือก component เริ่มจาก capability และ security requirements ไม่ใช่เริ่มจาก vendor shortlist ทีมต้องเปรียบเทียบทั้ง functional fitness, security properties, integration risk, privilege, data access, failure behavior, assurance, maintainability, support horizon, replaceability, licensing และ total exit cost

เกณฑ์ที่ควรบันทึกใน component decision record มีดังนี้

• intended use, scope, criticality, data classification และ trust boundary ที่ข้าม
• component identity/version/source และเหตุผลที่ variant นี้เหมาะกว่า alternatives
• known/unknown dependencies, default configuration, required privilege และ network interconnections
• secure development, testing, vulnerability handling, release/update และ support evidence ที่ขอและที่ได้รับจริง
• vulnerability/finding ที่ applicable, exploit preconditions, reachability, compensating controls และ residual uncertainty
• maintenance status, supported versions, release cadence, EOL signal, alternate source, migration/rollback และ data portability
• license/EULA constraints, intellectual property (IP) implications และ contract dependencies ที่ผู้มี authority ตรวจแล้ว
• treatment, owner, approval, expiry, monitoring และ triggers ที่ต้อง reassess

Risk treatment ต้องไม่ย่อเหลือ “approve/reject” ตัวเลือกอาจเป็นเลือก component อื่น, ลด privilege, wrap ด้วย PEP, isolate process, pin digest, vendor-fix, internal patch, เพิ่ม verification, จำกัด data/function, transfer บาง consequence ด้วย contract หรือ accept residual risk โดย risk owner การมี insurance/indemnity อาจ share financial impact แต่ไม่ลด exploitability หรือ mission harm

Continuous change and vulnerability monitoring

Supply-chain state เปลี่ยนแม้ application code ไม่เปลี่ยน เพราะ advisory ใหม่, maintainer/key compromise, ownership transfer, yanked package, certificate expiry, support termination, service-side release, subcontractor change หรือ exploit context ทำให้ decision เดิมล้าสมัย Monitoring จึงต้องครอบคลุมหลาย signal และมี route ไปสู่ action

วงจรที่ครบต้องทำสิ่งต่อไปนี้

• ingest supplier advisories, vulnerability sources, repository/signing events, license/support changes, threat intelligence, operational findings และ incidents
• normalize component identity/version และ map ไป dependency graph, artifact digest, workload, environment, owner, supplier และ contract
• validate finding และวิเคราะห์ applicability, reachability, privilege, exposure, compensating controls, business impact และ uncertainty
• เลือก patch, upgrade, downgrade, replace, disable, isolate, accept หรือ exit พร้อม evidence, deadline/trigger และ authority
• test change ตาม risk, rollout แบบควบคุม, verify effective fleet state และอัปเดต inventory/SBOM/exception
• ประเมิน supplier response quality และเปลี่ยน selection, contract, architecture หรือ continuity plan เมื่อเกิด pattern

SCA ช่วยทำ identity-to-known-weakness matching แต่ไม่รู้ทุก runtime path, configuration, zero-day, malicious maintainer หรือ service-side dependency จึงต้องใช้ร่วมกับ threat model, testing, runtime monitoring, supplier communication และ incident feedback

8.2 วิเคราะห์ security ของ third-party software

Third-party software อาจเป็น commercial off-the-shelf (COTS), open source, outsourced custom code, firmware, container/base image, SDK, build plugin, hosted API, Software as a Service (SaaS) หรือ managed platform รูปแบบธุรกิจต่างกัน แต่คำถามหลัก ยังเป็น fitness, origin, assurance, exposure, support, integration และ exit

Certifications และ assessment reports

Certification หรือ independent assessment report เป็น evidence ที่มีประโยชน์เมื่อ scope, criteria, period, tested system/version, assessor independence/competence, exceptions และ reliance conditions ตรงกับ decision ขององค์กร เอกสารเหล่านี้ลดต้นทุน การตรวจซ้ำบางส่วนแต่ไม่ใช่การรับประกัน

ก่อน rely ทีมควรถามว่า

• subject เป็น supplier organization, process, service environment หรือ product version ใด และครอบคลุม subcontractor หรือไม่
• assessment เทียบ criteria ใด เป็น design review, point-in-time test หรือ period-of-operation evidence และมี limitations อะไร
• report มี qualification, excluded control, customer responsibility หรือ finding ใดที่กระทบ intended use
• evidence สดพอหลัง acquisition, merger, key incident, architecture change หรือ service release หรือไม่
• องค์กรมีสิทธิ์เห็น detail, ขอ clarification, audit เพิ่ม หรือรับ notification เมื่อ scope/status เปลี่ยนหรือไม่

การตรวจ logo “certified” บนเว็บไซต์โดยไม่อ่าน scope เป็น common pitfall และการไม่มี certification ก็ไม่พิสูจน์ว่า supplier ไม่ปลอดภัย ทีมต้องเลือก alternative evidence ตาม assurance need เช่น secure development artifacts, targeted test, architecture review, vulnerability process evidence หรือ compensating control

Origin, maintenance และ support

Origin analysis ตรวจว่า component มาจาก project/organization ใด ผ่าน distribution channel ใด ใครควบคุม namespace, repository, build และ signing key และ fork/repackaging เกิดตรงไหน ส่วน maintenance/support analysis มองความสามารถในการรับ issue, triage, แก้, release, communicate และรักษา compatibility ตลอดเวลาที่องค์กรต้องใช้

สัญญาณที่ต้องวิเคราะห์ร่วมกันมี maintainer governance, review model, release history, security contact, disclosure process, supported branch, update mechanism, EOL policy, issue responsiveness, bus/concentration risk, funding/ownership change, license change, customer access to fixes และ exit feasibility “popular” หรือ “มี commit ล่าสุด” เป็น เพียง signal ไม่ใช่ assurance conclusion

8.3 Pedigree และ provenance

Pedigree คือภาพประวัติและคุณลักษณะของ component/origin/process ที่ช่วยประเมินความ น่าเชื่อถือ เช่น ใครพัฒนา ผ่าน review/test แบบใด มีการดูแลและเหตุการณ์อย่างไร Provenance คือ evidence chain ที่อธิบายว่า artifact เฉพาะชิ้นมาจาก inputs และ transformations ใด ใคร/ระบบใดทำ เมื่อใด และภายใต้ policy ใด ทั้งสองเกี่ยวข้องแต่ไม่ แทนกัน: project ที่มี pedigree ดีอาจถูกโจมตีที่ release pipeline และ provenance ที่ ครบอาจแสดงอย่างซื่อสัตย์ว่า artifact ถูกสร้างจาก malicious source

Provenance claim และ verification policy

Provenance ที่ใช้ตัดสินต้อง bind อย่างน้อย artifact identity/digest, source revision, declared/resolved dependencies, build recipe/configuration, builder identity, toolchain/environment, relevant parameters, time/freshness และ attestation/signature จาก authority ที่ policy ยอมรับ Verifier ต้องตรวจทั้ง syntax/cryptography และ semantics เช่น builder นี้อนุญาตสร้าง project นี้จาก repository/ref นี้หรือไม่

แผนภาพต่อไปนี้แยกการสร้างหลักฐานออกจากการตรวจและ admission เพื่อลด TOCTOU

หาก gate ตรวจ tag แล้ว production ดึง tag ภายหลัง attacker อาจสับเปลี่ยน target ระหว่าง check กับ use การ fetch, verify และ promote ด้วย immutable digest ใน controlled boundary ลดช่อง TOCTOU แต่ยังต้องคุ้มครอง verifier, trust roots, policy store และ destination repository ซึ่งเป็น TCB ของ admission

Secure transfer และ chain of custody

Secure transfer ปกป้อง confidentiality/integrity/authentication ของ artifact และ metadata ระหว่าง endpoints แต่ chain of custody บันทึกว่าใครหรือระบบใดได้มา ถือครอง เข้าถึง แปลง ส่งต่อ และเก็บ evidence เมื่อใดภายใต้ control ใด ทั้งสองมี scope ต่างกัน TLS ช่วยปกป้อง channel หนึ่งแต่ไม่พิสูจน์ origin ก่อน upload หรือสิ่งที่เกิดหลัง download

สำหรับ source media, firmware, high-assurance package หรือ forensic evidence องค์กรอาจ ต้องใช้ custody record, tamper-evident packaging, dual control, verified receipt, immutable identifiers, access logs และ protected storage ตาม purpose/authority หากมี ข้อกำหนดด้าน admissibility หรือ jurisdiction ต้องให้ legal authority ยืนยัน [uncertain]

Repository, interconnection และ build security

Repository และ build system เป็น privileged supply-chain control plane การออกแบบต้อง ครอบคลุม identity federation, MFA/strong authentication ตาม risk, least privilege, branch/tag protection, SoD, review, secret/key isolation, network egress, ephemeral worker, dependency proxy, protected logs, backup/recovery, anomaly detection และ emergency revocation

Interconnection ไม่ได้มีแค่ network link แต่รวม trust federation, webhook, package federation, build runner, update API, signing service, support portal และ SIEM feed แต่ละเส้นทางต้องมี interface contract, data classification, authentication, authorization, rate/failure behavior, monitoring, owner และ termination method

              source control
             /       |       \
       webhook    reviewer   deploy key
          |           |          |
          v           v          v
external package -> build worker -> signing service -> artifact repository
       proxy          |                 |                    |
          ^            +---- logs ------+------> SIEM <------+
          |
    advisory feed ---- inventory/SBOM service ---- production inventory

Every arrow is an interconnection and trust decision, not merely data movement.

แผนภาพ ASCII นี้เตือนให้ threat model administrative, telemetry, update และ recovery paths ด้วย หาก build worker ใช้ credential เดียวเขียน source tag, sign และ publish ได้ SoD ล้มเหลวแม้แต่ละ product เปิด security feature ครบ

Hash, signature และ right to audit

Cryptographic hash ให้ immutable identifier และตรวจความต่างจาก reference ได้เมื่อ algorithm/policy เหมาะสม Digital signature bind digest กับ signing identity ภายใต้ key/certificate/trust policy แต่ verifier ยังต้องตรวจ authority, artifact purpose, version, freshness/time, revocation/compromise, algorithm policy และ downgrade behavior Hash หรือ signature ไม่ตรวจ source quality, hidden behavior, vulnerability, license หรือ test outcome

Right to audit เป็นสิทธิ์ตาม agreement ที่ทำให้องค์กรหรือผู้ตรวจที่กำหนดเข้าถึง evidence, people, process, facility/system หรือ subcontractor ตาม scope, notice, frequency, confidentiality, cost และ trigger ที่ตกลง สิทธิ์นี้สนับสนุน verification และ leverage แต่ไม่ใช่ audit ที่ทำแล้วหรือ control effectiveness ทีมต้องกำหนดสิ่งที่จะ ตรวจ เกณฑ์ remediation และ consequence เมื่อ access/evidence ไม่พอ

8.4 Supplier security requirements ใน acquisition

Acquisition เป็น lifecycle ตั้งแต่ make/buy/reuse decision, market research, requirements, solicitation/evaluation, due diligence, selection, negotiation, onboarding, acceptance, performance monitoring, change, renewal จน termination และ transition Security ต้องอยู่ใน evaluation criteria และ agreement ก่อนเกิด leverage gap ไม่ใช่ส่ง questionnaire หลังเซ็นสัญญาแล้ว

จาก risk scenario สู่ข้อกำหนดที่ตรวจได้

Supplier requirement ที่ดีต้องระบุ outcome, scope, responsibility, timing/trigger, evidence, verification, escalation และ lifecycle ไม่ควรใช้ข้อความกว้างว่า “vendor ต้องใช้ industry best practices” โดยไม่มีเกณฑ์ ตัวอย่าง illustrative ต่อไปนี้ไม่ใช่ official requirement และ threshold ต้องมาจาก risk/authority ของระบบจริง

• “Supplier ต้องแจ้ง customer security contact ผ่าน approved channel เมื่อยืนยันว่า vulnerability กระทบ supported product versions ที่ customer ใช้ โดยแจ้ง affected identity/version, known impact, mitigation/workaround, remediation status และ update cadence ตาม trigger/timeline ที่ contract กำหนด [uncertain]”
• “Supplier ต้องส่ง component inventory/SBOM ที่ผูกกับ delivered artifact version, ระบุ format/scope/required fields ที่ตกลง และแจ้ง material dependency change เพื่อให้ customer ทำ impact analysis”
• “Remote support access ต้องใช้ named identity, customer-approved scope, time-bound privilege, protected logging, revocation และ evidence ที่ customer ตรวจได้”
• “Supplier และ customer ต้อง exercise incident coordination path และรักษา contact, evidence-transfer, communication authority และ subcontractor escalation ให้พร้อม”

ถ้อยคำเกี่ยวกับ notification period, privacy, breach, retention, export, audit หรือ liability ขึ้นกับ jurisdiction และ negotiation ผู้เขียน requirement ต้องทำ applicability analysis และให้ legal/compliance/privacy/procurement authority ยืนยัน [uncertain] ไม่ควรแต่งตัวเลขจากความคุ้นเคย

Audit supplier SSDLC policy และ effectiveness

การขอ secure software development life cycle (SSDLC) policy ตอบได้เพียงว่าสupplier ประกาศ intent อะไร Assurance ที่สูงขึ้นต้อง sampling evidence ว่า policy ถูก allocate และ execute ใน product/service scope เช่น training/role, threat model, code review, component admission, build protection, test, finding treatment, exception authority, release approval, vulnerability intake, patch/support และ lessons learned

Audit plan ต้อง risk-based และระบุ criteria, scope, product/version/service, subcontractor, evidence access, sample, assessor role, finding classification, remediation, retest, escalation และ follow-up Document presence, interview, design evidence และ operating evidence ให้ assurance คนละระดับ Audit pass ณ ช่วงหนึ่งไม่ใช่ continuous warranty และ audit ที่ customer ทำเองอาจยังมี skill/scope limitation

Vulnerability และ incident notification, response, coordination, reporting

Vulnerability process เน้น weakness/finding และ candidate remediation ส่วน incident process เน้น event ที่คุกคามหรือ compromise asset/policy ทั้งสองอาจเกี่ยวกันแต่ trigger, urgency, evidence และ communication authority ต่างกัน Acquisition requirement ควร กำหนดอย่างน้อยดังนี้

• security contact และ authenticated channel ที่ทดสอบได้ รวม after-hours/escalation
• trigger/definition ที่ parties ใช้ร่วมกันสำหรับ vulnerability, suspected incident, confirmed incident, affected customer และ material change
• initial notice content, update cadence, supported versions, mitigation/workaround, patch/fix route และ closure evidence ตาม risk/contract
• coordinated disclosure, customer communication, regulator/third-party contact และ public statement authority ซึ่งต้องให้ผู้มีอำนาจยืนยัน [uncertain]
• evidence preservation/transfer, forensic cooperation, access/data minimization, chain of custody และ limitations
• subcontractor flow-down และ supplier obligation ที่จะ coordinate แทนไม่ให้ customer ไล่ตามทุก fourth party เอง
• RCA/corrective action, regression evidence, fleet applicability และ feedback เข้าสู่ requirements/design/test/continuity

Notification ไม่ใช่ response และ response ไม่ใช่ remediation การส่ง email ตรงเวลาอาจ ผ่าน commitment หนึ่งแต่ยังไม่จำกัด harm ขณะที่ customer operations ต้อง triage, contain และ recover ตาม บทที่ 7 โดยไม่รอ supplier เมื่อ mission risk ไม่ยอมให้รอ

Support model, licensing และ track record

Support model ต้อง match operational need เช่น support hours, severity/priority model, named escalation, supported branches, security-fix access, update mechanism, compatibility, EOL notice, emergency workaround, recovery assistance และ knowledge transfer ทีมต้องแยก service target จาก guarantee และตรวจ consequence/exit เมื่อ supplier ทำไม่ได้

Licensing analysis ครอบคลุม right to use, copy, modify, distribute, inspect, test, reverse engineer, create derivative, receive security fix, run after termination และ transfer during exit ตาม agreement/authority ประเด็นเหล่านี้เป็น legal interpretation จึงติด [uncertain] จนผู้มีอำนาจยืนยัน Open source ไม่เท่ากับไม่มี license obligation และ commercial license ไม่รับประกัน support continuity

Track record เป็น historical evidence เช่น response ต่อ disclosed vulnerability, service incident, support delivery, ownership change, missed commitment และ audit remediation แต่ต้อง normalize ตาม scope/time/context ไม่ใช่นับข่าวลบหรือเชื่อ reference โดยไม่ตรวจ A new supplier อาจมี track record จำกัดซึ่งเป็น uncertainty ให้จัดการด้วย pilot, stronger evidence, limited privilege, staged adoption, escrow/exit หรือ alternate source แทนการสรุปว่าปลอดภัยหรือไม่ปลอดภัยทันที

Testing scope และ acceptance

Acquisition ต้องกำหนดว่าใครทดสอบอะไร เมื่อใด ที่ environment/version ใด และได้รับ สิทธิ์/ข้อมูลใด ขอบเขตอาจรวม supplier self-test, independent assessment, customer acceptance/security test, source review, SCA/SAST/DAST, penetration test, interface/failure test, recovery exercise และ remediation retest ตาม risk

ข้อกำหนดควรจัดการ rules of engagement, test account/data, production safety, notification, finding confidentiality, evidence, remediation, retest, release delta และ limitations Supplier test report เป็น input ไม่ใช่ customer acceptance โดยอัตโนมัติ และ customer test ไม่ปลด supplier จาก secure development responsibility

Shared responsibility และ SIEM log integration

Managed/cloud service แบ่ง control ระหว่าง supplier, customer และ subcontractor ความรับผิดชอบต้อง map ต่อ control outcome และ failure path ไม่ใช้คำกว้างว่า “security of cloud” กับ “security in cloud” แทนรายละเอียด

เมทริกซ์ต่อไปนี้เป็นตัวอย่างวิธีหาช่องว่าง โดยต้อง tailor ตาม service จริง

Control outcome	Supplier	Customer	Joint/evidence
Service platform patching	patch supported platform และแจ้ง impact	patch customer-managed agent/config	version/advisory/fleet reconciliation
Identity and access	enforce service-side identity/roles และ support revocation	provision/review/revoke users, protect federation	access review, emergency-access event, failed-auth signal
Data protection	protect service storage/transfer ตาม contract	classify/minimize/configure key/access options	responsibility for backup, restore, deletion และ key incident
Logging/monitoring	generate/export documented security events	ingest, correlate, protect, tune และ respond	schema, time, coverage, retention, outage และ test evidence
Incident response	investigate supplier boundary และ coordinate subcontractor	contain customer account/workload และ decide business action	contact, event/evidence transfer, update, RCA และ exercise
Continuity/exit	operate supplier recovery และ export/transition capability	maintain dependency plan, backup/alternate และ validate restore	RTO/RPO/SLA evidence, portability test และ termination runbook

SIEM integration ไม่ใช่แค่เปิด log feed Requirements ต้องกำหนด event semantics, actor/resource/action/result, tenant scope, source/version, clock/timezone, delivery, integrity, schema/version change, coverage, retention, sensitive-field minimization, access, outage/backfill, test signal, owner และ playbook หาก supplier ส่ง event หลัง เหตุหลายชั่วโมงแต่ customer use case ต้อง containment เร็ว contract/SLO, architecture หรือ compensating telemetry ต้องแก้ gap นั้น

แผนภาพต่อไปนี้แสดง shared responsibility loop จาก supplier signal ไปยัง joint action โดยเน้นว่าการส่ง log ยังไม่เท่ากับ monitoring outcome

Customer ยังต้องตรวจ source coverage และ effective ingestion เพราะ dashboard สีเขียว อาจเกิดจาก feed เงียบ Supplier ยังต้องไม่ส่ง Restricted payload เกิน purpose ความสำเร็จ คือ decision และ response path ทำงาน ไม่ใช่ปริมาณ logs

8.5 Contractual requirements และ remedies

Contract แปลงบาง responsibility และ expectation ให้เป็น commitment ระหว่าง parties แต่ wording และ enforceability ต้องผ่าน legal/procurement authority [uncertain] Security professional ระบุ risk, control objective, evidence, operational dependency และ failure consequence เพื่อให้ผู้มีอำนาจร่างและเจรจาถ้อยคำที่เหมาะสม

Intellectual property และ code escrow

Intellectual property (IP) provisions ต้องจัด ownership และสิทธิ์ต่อ pre-existing IP, custom code, modifications, documentation, test artifacts, data, telemetry, model, configuration และ deliverable รวม right to use/maintain/inspect/transfer หลังเหตุที่ กำหนด ความกำกวมอาจทำให้ customer แก้ vulnerability หรือย้ายระบบไม่ได้

Code escrow ให้ third party เก็บ source และ materials สำหรับ release เมื่อเกิด trigger เช่น supplier failure ตามเงื่อนไขที่ตกลง แต่ escrow ที่มี source เก่าโดยไม่มี build instruction, dependency/toolchain, keys/rights, documentation, test, skilled people และ verification ไม่ช่วย continuity มากนัก Controls ที่มีเหตุผลรวม periodic deposit, immutable identity, completeness check, build/recovery exercise, access protection, release criteria, license to use และ update trigger โดยรายละเอียดต้องยืนยันตามสัญญา [uncertain]

Escrow เป็น recovery/exit control ไม่ใช่ preventive control ต่อ malicious update หรือ guarantee ว่า customer maintain code ได้ จึงต้องใช้คู่กับ architecture replaceability, knowledge transfer, data portability และ alternate plan

Liability, warranty และ EULA

Liability กำหนดการรับผิดและข้อจำกัดต่อความเสียหาย ส่วน indemnity อาจจัดสรรภาระต่อ claim บางชนิด Warranty เป็นคำรับรองหรือ commitment เกี่ยวกับ condition/performance ตามถ้อยคำและเวลา End-User License Agreement (EULA) กำหนดสิทธิ์และข้อจำกัดการใช้ software ประเด็นเหล่านี้ไม่ใช่ technical control และไม่ควรถูกตีความโดยผู้ไม่มี authority [uncertain]

ทีม security ต้องตรวจว่า limitation/disclaimer ขัดกับ risk treatment assumption หรือไม่ เช่น architecture พึ่ง supplier emergency fix แต่ EULA/support term ไม่ให้สิทธิ์หรือ commitment นั้น หรือ testing plan ต้องทำ reverse engineering แต่ license จำกัดการทดสอบ Contractual transfer ไม่ลบ operational impact องค์กรยังต้องมี preventive, detective, response และ continuity controls ตาม mission

SLA, evidence และ remedy ladder

Service-Level Agreement (SLA) ระบุ service commitment, responsibility, reporting หรือ consequence ระหว่าง parties Security-relevant SLA อาจผูก availability, security event delivery, response/notification, vulnerability remediation, evidence access, restore, support และ change notice แต่ทุก SLI ต้องมี definition, scope, source, measurement window, exclusions, dispute route และ data access

Remedy ladder ที่ออกแบบตาม risk อาจประกอบด้วย corrective action plan, increased reporting, retest/audit, service credit, escalation, suspension of privileged access, alternate service, termination assistance หรือ exit right ตาม agreement เพียงรับ service credit ไม่คืน confidentiality, safety หรือ mission time จึงไม่ควรเป็น treatment เดียวของ high-impact risk

Contract lifecycle ต้องครอบคลุม onboarding evidence, periodic review, material change, subcontractor flow-down, renewal, breach/failure, termination, access revocation, data return/disposition, evidence retention, transition support และ post-termination obligation สิ่งที่ contract ระบุแต่ไม่มี owner/monitoring/escalation อาจถูกพบช้าเกินใช้ remedy

แผนภาพนี้แยก contractual enforcement จาก operational containment ออกจากกัน เมื่อ supplier ผิด commitment ทีมอาจต้อง isolate/replace ก่อน dispute จบ และ risk owner ต้อง ตัดสิน residual risk จาก effective state ไม่ใช่จากสิทธิ์ที่จะเรียกร้องภายหลัง

ภัยคุกคาม ช่องโหว่ และความเสี่ยง

การวิเคราะห์ Domain นี้ต้องมองทั้ง malicious action, accidental failure, control gap และ concentration โดยเชื่อม asset/mission → scenario → weakness/exposure → controls → impact → residual risk → authority/monitoring รายการต่อไปนี้เป็น scenario families ไม่ใช่ checklist ที่ครบทุกระบบ

Threat scenarios ตามเส้นทาง supply chain

Threats สำคัญมีดังนี้

• Source/repository compromise: attacker ยึด maintainer account, token, branch, review workflow หรือ namespace แล้วใส่ malicious change หรือสับเปลี่ยน tag
• Dependency confusion/typosquatting: resolver เลือก package จาก namespace/source ที่ไม่ตั้งใจ เพราะ naming, priority, version range หรือ registry policy อ่อน
• Build/toolchain compromise: malicious compiler/plugin/runner หรือ stolen build credential สร้าง artifact ที่ไม่ตรง reviewed source และอาจ sign ได้ตามปกติ
• Distribution/update compromise: repository, mirror, CDN, update manifest, DNS, signing key หรือ customer trust store ถูกใช้ส่ง artifact ที่ไม่อนุมัติ
• Component vulnerability or unsafe default: known/unknown weakness, excessive privilege, hidden feature, insecure configuration หรือ failure propagation ถูก exploit
• Maintainer/supplier failure: project ถูก abandon, ownership transfer, support หยุด, fix ล่าช้า, EOL เร็ว หรือ disclosure/incident coordination ล้มเหลว
• Counterfeit/tampered delivery: component, hardware/firmware media, document หรือ provenance metadata ถูกแทนที่ระหว่าง custody/transfer
• Malicious or opaque service change: SaaS/managed supplier เปลี่ยน code, model, dependency, region, subprocessors หรือ logging โดย customer มองไม่เห็น release
• Subcontractor and concentration failure: suppliers หลายรายพึ่ง cloud, IdP, repository, library, maintainer หรือ signing root เดียว ทำให้ defense/alternate ที่ดู แยกกันล้มพร้อมกัน
• License/IP failure: องค์กรไม่มีสิทธิ์ใช้ แก้ แจกจ่าย ทดสอบ หรือ maintain ตามที่ architecture/continuity assumption ต้องใช้ [uncertain]
• Evidence deception or staleness: SBOM ไม่ครบ, assessment ผิด scope, signature จาก compromised key, provenance replay หรือ report เก่า ทำให้ gate อนุมัติผิด
• Exit/lock-in failure: proprietary format, undocumented interface, withheld key, inaccessible data หรือไม่มี alternate skill ทำให้เปลี่ยน supplier ไม่ทันเหตุ

Risk factors ที่ทำให้ scenario รุนแรงขึ้น

Risk ไม่ได้เท่ากับจำนวน CVE ปัจจัยที่ต้องวิเคราะห์ร่วมกันคือ component criticality, privilege, data sensitivity, internet exposure, reachability, exploit preconditions, deployment population, detectability, replaceability, patch/test/rollout time, supplier responsiveness, support horizon, concentration, recovery dependency, evidence confidence และ business impact

ตัวอย่างเช่น library มี high technical severity แต่ vulnerable function ไม่รวมใน build อาจมี contextual risk ต่ำกว่า unsigned build plugin ที่ไม่มี CVE แต่รันด้วย credential เขียน artifact ได้ ความไม่รู้เรื่อง transitive dependency หรือ supplier ownership คือ uncertainty ไม่ใช่ likelihood ศูนย์

Risk register ที่เชื่อมหลายฝ่าย

Supply-chain risk entry ต้อง bind component/service identity, affected system/version, supplier/subcontractor, scenario, asset/impact, evidence/limitations, controls, responsibilities, contractual dependency, residual risk, owner, treatment, due/expiry, monitoring และ reassessment trigger Link ต้องย้อน SRTM, architecture, build/test, production inventory, incident และ contract version ได้

หาก contract ระบุ supplier แก้ช่องโหว่แต่ operations deploy ไม่ได้เพราะ compatibility gap risk ยังไม่ถูก treat Shared responsibility ต้องมี end-to-end outcome owner และ handoff evidence มิฉะนั้นแต่ละฝ่ายอาจ “ทำส่วนของตนเสร็จ” แต่ exposure ยังคงอยู่

Controls และแนวปฏิบัติที่ดี

Control portfolio ต้องป้องกัน ตรวจจับ ตอบสนอง กู้คืน และให้ leverage ต่อ supplier โดยมี failure modes ต่างกัน การบังคับ signature ทุก package มีประโยชน์แต่ไม่พอหาก attacker ขโมย signing key หรือ approved builder สร้างจาก malicious source ตารางและ หัวข้อต่อไปนี้อธิบาย placement, rationale, evidence และ trade-off ของ controls สำคัญ

Governance, tiering และ ownership

องค์กรควรกำหนด supplier/component tier จาก mission impact, privilege, data, reach, replaceability, concentration และ assurance need แล้ว map due diligence, approval, monitoring, audit และ contract baseline ตาม tier การ tier ลด cost เมื่อเทียบกับตรวจทุก supplier เท่ากัน แต่ taxonomy ที่อาศัย spend หรือ vendor size อย่างเดียวจะพลาด free build plugin ที่มี privilege สูง

ทุก component/service ต้องมี lifecycle owner, technical owner, risk owner, procurement/contract owner และ operational contact ตามที่เหมาะสม หนึ่งคนถือหลาย role ได้เมื่อ risk ยอมรับ แต่ authority ต้องชัดและใช้ SoD กับ decision สำคัญ เช่น proposer ไม่ควร approve exception และ publish artifact ครบวงจรโดยไม่มี independent check

หลักฐานของ control นี้คือ inventory coverage, tier rationale, decision record, exception, review/expiry และ escalation outcome ไม่ใช่เพียง supplier policy

Approved source และ component admission

องค์กรควรให้ developer/build ดึง component ผ่าน approved internal proxy/repository ที่ enforce namespace/source allowlist, immutable digest pinning, quarantine, malware/ SCA/license checks, provenance/signature policy และ promotion gate การรวม control ที่ admission boundary ลดการดึงตรงจากอินเทอร์เน็ตและให้ consistent evidence

Trade-offs คือ repository availability กลายเป็น critical dependency, cache อาจเก่า, emergency fix อาจช้า และ central policy error กระทบทุกทีม จึงต้องมี resilient design, protected administration, tested recovery, monitored bypass และ emergency process ที่ ยังมี authority/evidence ไม่ใช่ปิด gate

Control ต้องตรวจ resolved transitive dependency และ build-time/runtime plugin ด้วย Allowlist ชื่อ package โดยไม่ pin source/digest ยังเปิด namespace confusion และ tag mutation Component ที่เคย approve ต้อง reassess เมื่อ version, use context, maintainer, license, threat หรือ support เปลี่ยน

Build, repository, signing และ provenance protection

Defense in depth สำหรับ source-to-artifact chain มี controls ต่อไปนี้

• protected branch/tag, reviewed change, signed/attributed commit ตาม policy และ independent release approval
• isolated ephemeral build worker, least privilege, controlled network egress, immutable inputs และ clean-state verification
• separated build, attest, sign และ publish authority พร้อม short-lived scoped credential และ protected key/root of trust
• versioned build recipe/toolchain, dependency pinning, reproducibility comparison เมื่อ เหมาะสม และ provenance attestation ที่ bind artifact digest
• quarantine-to-approved repository promotion โดย digest, immutable retention, access/anomaly logs, backup/recovery และ tested revocation
• verifier ที่ตรวจ trust root, signer/builder authority, source/repository, dependency, parameters, freshness, revocation และ policy version ไม่ใช่แค่ cryptographic validity

Reproducible build เพิ่มความสามารถเปรียบเทียบ outputs จาก independent environments แต่ ต้องควบคุม nondeterminism และไม่ได้พิสูจน์ว่า source ปลอดภัย Attestation ให้ structured claim แต่ถ้า attestor เชื่อ compromised builder โดยไม่วัด state claim ก็อาจถูกต้องตาม ข้อมูลเท็จ จึงต้องบันทึก trust assumptions

SBOM และ inventory operations

SBOM control ที่มีคุณค่าต้องกำหนด producer, consumer use case, component depth, identity scheme, relationship, version/artifact binding, format, generation method, validation, access/classification, update cadence และ retention องค์กรต้อง reconcile source/build/release/deployed/runtime views และวัด coverage/freshness โดยระบุ denominator

SBOM อาจเปิดเผย architecture และ vulnerable component information จึงต้องคุม access ตาม classification โดยไม่ปิดกั้น response team ที่จำเป็น การรับ SBOM จาก supplier ต้อง validate schema/identity/completeness ตาม scope และสุ่มเทียบ artifact evidence ไม่ถือว่า supplier declaration ถูกเสมอ

Inventory service ต้องรองรับ query จาก advisory/component ไปยัง affected artifacts, systems, environments, owners, suppliers และ contracts รวม reverse query จาก system ไป dependencies หาก identity mapping ambiguous ทีมต้องเก็บ uncertainty และ escalate ไม่ auto-close finding

Supplier due diligence และ continuing assurance

Due diligence ที่ดีใช้ evidence portfolio ตาม scenario ได้แก่ questionnaire/interview, policy/design artifact, secure development record, assessment/certification report, targeted technical test, architecture review, references/track record, support exercise, financial/continuity information, contract และ pilot operation ไม่มี evidence ชิ้นเดียว แทนทั้งหมด

Controls ที่ลด point-in-time bias ได้แก่ periodic/triggered reassessment, material-change notification, updated report/SBOM, performance SLI, vulnerability/incident exercise, audit/remediation follow-up, privileged access review และ production evidence feedback Trigger ควรรวม merger/acquisition, maintainer/ownership/key change, major architecture, new subprocessors, repeated missed fix, incident, EOL และ material service degradation

Trade-off คือ audit fatigue, duplicated questionnaires, supplier cost และ disclosure ข้อ sensitive information องค์กรควร reuse credible scoped evidence, coordinate reviews, protect supplier data และขอเฉพาะ evidence ที่ผูกกับ decision แต่ห้ามลด assurance เพราะ procurement deadline โดยไม่มี authorized exception

Contract, flow-down และ exit readiness

Security schedule หรือข้อกำหนดที่รวมใน agreement ต้อง trace กลับ risk และมี owner ตรวจ performance ควรกำหนด subcontractor flow-down ให้ supplier รับผิดชอบ control outcome/notification ไม่ให้ fourth party กลายเป็นช่องว่างโดยอัตโนมัติ Customer ต้องรู้ material dependency/concentration เท่าที่จำเป็นต่อ impact analysis ภายใต้ confidentiality

Exit controls ประกอบด้วย data/configuration export, documented interface, transition support, knowledge transfer, alternate supplier/build capability, escrow เมื่อเหมาะสม, access/key/certificate revocation, service routing change, return/disposition evidence, license continuity, archive/record retention และ recovery/rollback exercise Exit plan ที่ไม่เคยทดสอบเป็น assumption โดยเฉพาะ proprietary state และ identity integration

การเจรจา stronger warranty/liability อาจเพิ่ม leverage หรือ share consequence แต่มี cost และ supplier อาจไม่ยอม องค์กรต้องประเมินว่าจะ reduce technical dependency, accept residual risk, เลือก alternate หรือเปลี่ยน business design ไม่ใช่ถือว่า wording แก้ exploit path

Monitoring, response และ control effectiveness

Supplier/component monitoring ต้องเริ่มจาก decision questions เช่น “artifact ใดใช้ maintainer key ที่ถูก revoke,” “ระบบใดเรียก affected API path,” หรือ “supplier ใดผิด support commitmentซ้ำ” แล้วกำหนด source, identity correlation, owner, playbook และ response deadlineตาม risk

Control effectiveness ต้องวัด outcome และ quality ไม่ใช่ activity count ตัวอย่างที่มี ความหมายมากกว่า raw totals ได้แก่ time-to-map verified advisory ไป effective assets, inventory reconciliation gaps by critical tier, supplier noticesที่ customerตรวจพบก่อน, exception past expiry, unsupported critical dependency, admission bypass, fix delivery- to-fleet closure delta และ restore/exit exercise result ค่าต่าง ๆ ต้องกำหนด population, window, exclusions และ data quality โดยไม่แต่ง universal threshold

เมื่อ signal ชี้ malicious update ทีม operations ต้อง revoke trust/credential, block digest/source, identify affected fleet, contain, preserve evidence, recover และ monitor ตาม บทที่ 7 พร้อมส่ง RCA กลับมาปรับ admission, provenance, supplier assessment, contract และ test regression

Pseudo code

Pseudo code ต่อไปนี้สาธิต component admission policy gate ซึ่งแยก evidence missing, identity mismatch, cryptographic failure, policy failure, contextual finding และ authorized exception การตรวจเกิดกับ immutable digest เดียวกับที่จะ promote เพื่อลด TOCTOU ตัวอย่างนี้ไม่ใช่ code ที่ compile หรือ policy สำเร็จรูป

# PSEUDO CODE — component admission with provenance, SBOM, and risk policy

function admit_component(request, quarantine_repository, policy_snapshot):
    assert request.intended_use_id is not empty
    assert request.requester != request.approver       # segregation of duties

    artifact = quarantine_repository.fetch_by_digest(request.expected_digest)
    if artifact is MISSING:
        return decision("evidence missing", reason="artifact unavailable")

    measured_digest = approved_hash(artifact.bytes)
    if measured_digest != request.expected_digest:
        quarantine(artifact)
        alert_security("identity mismatch", request, measured_digest)
        return decision("fail", reason="artifact bytes do not match requested identity")

    evidence = load_evidence_bound_to(measured_digest)
    required = ["provenance", "signature", "sbom", "license", "analysis"]
    if any(evidence[item] is MISSING for item in required):
        return decision("evidence missing", missing=list_missing(evidence, required))

    signature_result = verify_signature(
        digest=measured_digest,
        signature=evidence.signature,
        trusted_roots=policy_snapshot.trusted_roots,
        allowed_signer=request.project_release_authorities,
        purpose="component-release",
        revocation_state=policy_snapshot.revocation_state,
        algorithm_policy=policy_snapshot.crypto_policy
    )
    if not signature_result.valid:
        quarantine(artifact)
        return decision("fail", reason=signature_result.reason)

    provenance_result = verify_provenance(
        statement=evidence.provenance,
        artifact_digest=measured_digest,
        allowed_source=request.approved_source_revision,
        allowed_builders=policy_snapshot.builders_for(request.project),
        allowed_dependency_sources=policy_snapshot.dependency_sources,
        freshness_rule=policy_snapshot.provenance_freshness
    )
    if not provenance_result.valid:
        return decision("fail", reason=provenance_result.reason)

    sbom_result = validate_sbom(
        sbom=evidence.sbom,
        artifact_digest=measured_digest,
        required_depth=policy_snapshot.depth_for(request.risk_tier),
        observed_components=inspect_artifact_components(artifact)
    )
    if sbom_result.identity_conflicts:
        return decision("fail", reason="SBOM and artifact evidence conflict")
    if sbom_result.coverage_unknown:
        return decision("evidence missing", owner=request.component_owner)

    findings = correlate_findings(
        resolved_components=sbom_result.components,
        intended_use=request.intended_use,
        architecture_context=request.trust_and_privilege_context,
        production_inventory=current_effective_inventory()
    )
    risk_result = evaluate_contextual_risk(findings, request.risk_model)

    if risk_result.exceeds_tolerance:
        exception = load_exception(
            artifact_digest=measured_digest,
            intended_use_id=request.intended_use_id,
            policy_version=policy_snapshot.version
        )
        if not exception.is_authorized_and_unexpired():
            return decision("exception required", risk=risk_result)
        if not controls_are_effective(exception.compensating_controls):
            return decision("fail", reason="exception conditions are not effective")
        outcome = "conditional pass"
    else:
        outcome = "pass"

    # Promote the already-verified bytes, never re-fetch by mutable name or tag.
    approved_repository.promote_same_digest(
        artifact=artifact,
        digest=measured_digest,
        evidence_bundle=evidence,
        decision_record=protect_record(outcome, request, risk_result, policy_snapshot)
    )
    schedule_reassessment(
        digest=measured_digest,
        triggers=["advisory", "supplier change", "key revocation", "support change",
                  "incident", "license change", "exception expiry"]
    )
    return decision(outcome, digest=measured_digest)

จุดสำคัญคือ valid signature ไม่ทำให้ gate ข้าม provenance, SBOM, license, analysis หรือ contextual risk และ exception ต้อง bind กับ artifact, intended use และ policy version หาก component เดียวกันถูกใช้ใน privileged control plane แทน low-impact tool risk decision เดิมอาจใช้ไม่ได้

ตัวอย่างหรือกรณีศึกษา

กรณีศึกษานี้ต่อ thread ระบบ payroll จากบทก่อน โดยสมมติว่าระบบใช้ external Identity Provider (IdP), bank transfer SDK, cryptographic signing service, open-source parser, CI build plugin และ managed log service ข้อกำหนด SR-PAY-001, SR-PAY-002, SR-DAT-004 และ SR-REC-008 เป็น illustrative IDs ที่คู่มือนี้สร้างขึ้น ไม่ใช่ official requirements

บริบทและ supply-chain map

Payroll ต้องรักษา maker/checker SoD, จำกัด Restricted payroll data, ป้องกัน replay, กู้คืน transaction/evidence ได้ และส่ง bank instruction version ที่อนุมัติจริง Architecture review พบว่า supplier dependencies ไม่ได้อยู่ขอบระบบ แต่มี authority สำคัญดังนี้

• IdP ออก identity/session claim ที่ใช้ authorization แต่ application ยังต้อง enforce transaction-specific SoD และ revocation ทุก action
• bank SDK แปลง message และ sign request ใน process ที่เข้าถึง payroll payload
• signing service ถือ key และมี privileged API; customer กำหนด policy/identity บางส่วน
• parser ประมวลไฟล์นำเข้า attacker-controlled และมี transitive dependencies
• build plugin รันใน CI พร้อมอ่าน source และเขียน build output
• managed log service รับ minimized security events และเป็นส่วนหนึ่งของ incident evidence

ทีมจัด build plugin และ signing service เป็น critical แม้ค่าใช้จ่ายต่ำ เพราะ compromise มี blast radius สูง นี่แสดงว่า supplier tier ไม่ควรอาศัย spend

Selection, acquisition และ admission

สำหรับ bank SDK ทีมเปรียบเทียบ version ตาม interface fitness, memory/data exposure, supported branch, vulnerability handling, release signing, provenance/SBOM, compatibility, license และ exit path Supplier ส่ง assessment report แต่ scope ครอบคลุม service portal ไม่ครอบคลุม SDK build pipeline ทีมจึงไม่ตีความ report เป็น product assurance และขอ targeted build/release evidence เพิ่ม

Contract/requirement กำหนด supported-version advisory, emergency workaround, authenticated distribution, material dependency notification, incident coordination, test right และ support/exit โดย legal/procurement authority ยืนยัน wording [uncertain] ทีม pin SDK/proxy source/digest แล้ว admission gate ตรวจ signature authority, provenance, SBOM, license decision และ contextual findings ก่อน promote

IdP/shared service responsibility ถูก map ว่า supplier ปกป้อง service platform และ ออก event ส่วน payroll owner provision/revoke user, enforce business SoD, ingest events และ respond Joint test ตรวจ deprovisioning, token freshness, privileged event delivery, clock skew, feed outage และ incident contact ไม่ถือว่า IdP certification ปิด gap เหล่านี้

Incident และ closed-loop treatment

หลายเดือนต่อมา repository แจ้งว่า signing key ของ build plugin maintainer อาจถูก compromise Signature ของ plugin version ที่ใช้อยู่ตรวจผ่านในอดีต และยังไม่มี CVE ทีมไม่สรุปว่าปลอดภัย แต่ดำเนินการดังนี้

1. revoke/block maintainer key และ affected digests ตาม validated scope
2. query build provenance และ inventory เพื่อหา artifact ที่ plugin version นั้นสร้าง
3. หยุด promotion ใหม่ แยก affected release และ preserve source/build/provenance logs
4. เปรียบเทียบ reviewed source, independent rebuild/analysis และ production telemetry
5. rotate/revoke CI credentials ที่ plugin อาจเข้าถึง และตรวจ unauthorized publication
6. ประเมิน payroll mission risk เพื่อ rebuild จาก trusted toolchain, retest และ promote
7. ประสาน supplier/maintainer ตาม disclosure และ evidence route พร้อม track response
8. ปรับ component admission, key monitoring, builder isolation, regression tests, supplier tier และ alternate tool plan

ทีมพบว่า production artifact digest ตรงกับ release package แต่ provenance แสดงว่า builder เปิด network egress กว้าง จึงยังมี uncertainty ว่า plugin ดาวน์โหลด payload เพิ่มหรือไม่ Hash integrity ของ production ไม่ตอบคำถาม build behavior ทีมใช้ containment และ rebuild/retest แทนการรอ definitive vendor statement

Contract performance และ exit lesson

Managed log supplier เปลี่ยน schema โดยแจ้งช้าจน privileged-route correlation หายไป แต่ dashboard ingest ยังเขียว เหตุนี้ไม่ใช่แค่ operations tuning: supplier ผิด change notification/evidence semantics ที่ acquisition กำหนด ทีมใช้ alternate raw audit feed เป็น compensating control, เปิด corrective action, ทดสอบ backfill และแก้ contract monitoring ให้ตรวจ sentinel events กับ schema version

เมื่อ review continuity ทีมพบว่า IdP และ signing service ใช้ cloud region/control plane เดียวกัน “สอง suppliers” จึงมี common-mode dependency ทีมปรับ degraded payroll procedure, alternate identity/signing path, recovery exercise และ contract exit/support assumptions พร้อมส่งผลกลับ บทที่ 4 และ บทที่ 7

บทเรียนจากกรณีศึกษา

กรณีนี้แสดงความต่างของ evidence และ action ดังนี้

• inventory หา affected builds; SBOM ช่วย map dependencies; ทั้งสองไม่พิสูจน์ origin
• signature บอกว่า key ที่ policy เชื่อได้ sign digest; key compromise ทำให้ trust เปลี่ยน
• provenance ระบุ build context; egress gap ลด assurance แม้ statement cryptographically valid
• supplier report ผิด scope จึงไม่ครอบคลุม SDK; targeted evidence เติมเฉพาะ decision gap
• contract ให้ notification/remedy/coordination leverage; operations ยังต้อง contain เอง
• incident feedback เปลี่ยน implementation/build, testing, operations, supplier tier, architecture และ contractual monitoring จึงเป็น closed-loop governance จริง

Exam tips

คำถามเชิงสถานการณ์มักมีหลาย control ที่ “ทำได้” แต่คำตอบที่ดีที่สุดต้องตรง stage, authority และ information gap อ่านคำกริยาให้ชัดว่าโจทย์ถาม identify, assess, select, verify, respond, accept หรือ enforce แล้วใช้หลักต่อไปนี้ช่วยตัดตัวลวง

• ถ้ายังไม่รู้ asset, intended use, scope หรือ criticality ให้กำหนด context และ requirements ก่อนเลือก certification/tool/contract clause
• ถ้าถามว่า component ใดได้รับผล ให้เริ่มจาก normalized identity, dependency/effective inventory และ version mapping ไม่เริ่มจาก patch ทุกระบบ
• ถ้าถาม origin/build path ให้ใช้ provenance/pedigree evidence; SBOM หรือ SCA อย่างเดียว ไม่ตอบว่าใครสร้างผ่าน process ใด
• ถ้าถาม bytes ถูกเปลี่ยนหรือไม่ ให้ hash เทียบ trusted reference; ถ้าถาม signer identity ให้ signature/trust policy แต่ทั้งคู่ไม่ตอบว่า software ปลอดภัย
• Certification/assessment ช่วยเมื่อ scope, period, criteria และ subject match intended use ถ้าไม่ match ให้หา evidence เพิ่มหรือ compensating control
• Supplier reputation, popularity, license model และ CVE count เป็น signals ไม่ใช่ risk decision ให้ดู privilege, exposure, maintainability, support, exit และ impact
• Security requirement ควรเกิดก่อน supplier selection และผูก outcome, responsibility, evidence, timing/trigger, verification และ remedy
• Audit right ไม่เท่ากับ audit execution; SLA credit ไม่เท่ากับ preventive control; insurance/liability ไม่ทำให้ exploitability ลดลง
• Vulnerability notification, incident notification, coordinated response, patch/fix, reporting และ RCA เป็นคนละ commitment อย่าใช้คำว่า “notify” แทนทั้งวงจร
• Customer ไม่ outsource accountability ทั้งหมด Shared responsibility gap ต้องมี owner และ residual risk decision แม้ supplier รับผิดชอบ platform
• เมื่อพบ active harm ให้ operations contain/recover ตาม authority แล้วทำ contract/ supplier coordinationคู่ขนาน ไม่รอพิสูจน์ liability ก่อน
• การยอมรับ residual business risk เป็นหน้าที่ risk owner หรือผู้มีอำนาจตาม governance ไม่ใช่ developer, auditor, scanner, procurement หรือ supplier เพียงฝ่ายเดียว
• คำตอบที่เป็น “best” มักรักษา traceability และ closed loop: production evidence ต้อง เปลี่ยน risk, requirements, design, implementation, testing, supplier และ contract decision เมื่อสมมติฐานเปลี่ยน

Common pitfalls

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

• ถือว่า SBOM ครบถ้วน/ทันสมัยโดยไม่ระบุ scope, artifact binding, transitive relation, generation method และ effective runtime reconciliation
• ถือว่า “ไม่มี CVE” แปลว่าไม่มี vulnerability, malicious behavior หรือ supplier risk
• ใช้ CVSS หรือ vulnerability count แทน contextual risk, reachability และ business impact
• ยอมรับ package จากชื่อ/tag/latest โดยไม่ bind namespace, source, version และ digest
• ตรวจ signature แต่ไม่ตรวจ signer authority, purpose, revocation, freshness และ provenance หรือใช้ checksum ที่ส่งจาก channel เดียวกับ artifact เป็น independent proof
• ถือว่า provenance ครบแปลว่า source ปลอดภัย หรือ pedigree ดีแปลว่า release ไม่ถูกโจมตี
• พึ่ง certification logo, questionnaire pass หรือ policy presence โดยไม่ตรวจ scope, evidence และ operating effectiveness
• จัด supplier tier ตามค่าใช้จ่ายเท่านั้น จึงมองข้าม free dependency/build plugin ที่ มี privilege สูง
• ทำ due diligence ครั้งเดียวก่อนซื้อแล้วไม่ monitor ownership, support, key, dependency, vulnerability, incident และ contract change
• เขียน “follow best practices” หรือ “notify promptly” โดยไม่มี measurable trigger, responsibility, evidence, escalation และ verification route
• ไม่ flow-down obligations ไป subcontractor หรือไม่กำหนด supplier ให้ coordinate fourth-party response
• ถือว่า supplier ส่ง logs แล้ว customer monitoring สำเร็จ โดยไม่ตรวจ schema, time, coverage, event semantics, ingestion outage และ response playbook
• ใช้ right to audit แทนการกำหนด audit criteria, remediation/retest และ consequence
• ใช้ warranty, liability, indemnity หรือ service credit แทน preventive/response/ continuity controls
• เก็บ source ใน escrow แต่ไม่ทดสอบ completeness, buildability, rights, dependencies, documentation และ release triggers
• ไม่มี exit plan หรือทดสอบ data portability หลัง vendor lock-in เกิดแล้ว
• ให้ procurement, security tester หรือ supplier accept risk แทน business risk owner
• patch source repository แต่ไม่ reconcile deployed fleet, transitive artifacts และ release built ด้วย compromised toolchain
• สร้าง alternate supplier สองรายที่พึ่ง common cloud, library, identity หรือ signing root เดียวกัน แล้วเข้าใจผิดว่าลด concentration risk
• ตีความ legal/privacy/license/contract obligation เองโดยไม่ใช้ authority และไม่กำกับ [uncertain] เมื่อ applicability ยังไม่ยืนยัน

ข้อฝึกทบทวน

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

ข้อ 1

องค์กรได้รับ advisory ของ transitive library และต้องทราบว่าระบบ production ใดได้รับ ผล ขั้นตอนแรกที่ดีที่สุดคือข้อใด

A. สั่ง supplier ทุกเจ้าส่ง certification ใหม่
B. ค้น component identity/version ใน dependency graph และ effective inventory
C. patch ทุก application ที่มีชื่อ library ใน source repository
D. accept risk เพราะ library ไม่ถูก declare โดยตรง

ข้อ 2

Artifact มี valid digital signature จาก key ที่ policy เชื่อถือ ข้อสรุปใดถูกต้องที่สุด

A. Artifact ไม่มี vulnerability
B. Source ผ่าน secure code review แล้ว
C. Signature ตรวจ authenticity/integrity claim ภายใต้ key และ policy แต่ยังต้องตรวจ authority, provenance และ risk
D. Supplier ต้องรับ liability ต่อ defect ทั้งหมด

ข้อ 3

Supplier ส่ง certification report แต่ scope ครอบคลุม corporate IT ไม่ครอบคลุม managed service ที่องค์กรจะใช้ การตอบสนองที่ดีที่สุดคือข้อใด

A. ยอมรับเพราะเป็น certification จาก third party
B. ปฏิเสธ supplier ทันทีเพราะ report ไม่มีค่า
C. ระบุ assurance gap แล้วขอ scoped evidence/assessment หรือ controls เพิ่มตาม risk
D. ใช้ SLA credit แทน product assurance

ข้อ 4

ทีมจัดซื้อกำลังร่าง requirement สำหรับ vulnerability notification ข้อความใดดีที่สุด

A. Supplier ต้องแจ้ง vulnerability โดยเร็วที่สุด
B. Supplier ต้องไม่มี vulnerability
C. Supplier ต้องใช้ best practices ทั้งหมด
D. กำหนด affected product/version, trigger, channel, content, update/coordination, evidence และ timeline ที่ผู้มีอำนาจอนุมัติ

ข้อ 5

Managed service ส่ง logs เข้า SIEM แล้ว แต่ supplier เปลี่ยน schema ทำให้ correlation rule ไม่ทำงาน Control ใดจัดการ root gap ได้ดีที่สุด

A. เพิ่ม retention โดยไม่เปลี่ยน integration
B. กำหนด schema/version-change notice, sentinel test, coverage monitoring และ joint response ownership
C. ปิด alert เพื่อลด false positives
D. ถือว่า supplier รับผิดชอบทั้งหมดเพราะเป็นผู้สร้าง log

ข้อ 6

ข้อใดอธิบาย code escrow ได้ถูกต้องที่สุด

A. เป็น preventive control ที่หยุด malicious update
B. รับประกันว่า customer build และ maintain product ได้
C. เป็น recovery/exit mechanism ที่ต้องตรวจ deposit, completeness, rights, buildability และ release triggers
D. ใช้แทน backup, documentation และ alternate supplier ได้

ข้อ 7

ทีมพบ build plugin ไม่มี known CVE แต่รันด้วย credential ที่เขียน release repository ได้ ข้อใดเป็นการวิเคราะห์ที่ดีที่สุด

A. Risk ต่ำเพราะไม่มี CVE
B. ประเมิน origin/provenance, privilege, build isolation, behavior, support และ compromise impact แล้วลด authority ตาม least privilege
C. อนุมัติเพราะ plugin เป็น open source
D. ซื้อ cyber insurance แล้วไม่ต้องตรวจเพิ่ม

ข้อ 8

หลัง supplier signing key ถูก compromise การดำเนินการใดดีที่สุด

A. รอ liability decision ก่อนแตะ production
B. เปลี่ยนชื่อ package ใน inventory เท่านั้น
C. revoke/block trust ตาม scope, map affected digests/builds, contain, verify/rebuild/ retest และประสาน supplier พร้อมปรับ controls
D. เชื่อ artifact เดิมทุกชิ้นเพราะ signature เคย valid

ข้อ 9

Supplier และ customer ต่างระบุว่าตนทำหน้าที่ตาม shared responsibility แล้ว แต่ช่องโหว่ ยัง deploy อยู่ทั่ว fleet ปัญหาหลักคือข้อใด

A. ไม่มี end-to-end outcome ownership และ evidence reconciliation ระหว่าง fix กับ fleet
B. Supplier ไม่มี certification เพิ่มอีกหนึ่งฉบับ
C. Customer ใช้ SBOM format ผิดเสมอ
D. SLA ต้องมี service credit สูงขึ้นเท่านั้น

ข้อ 10

องค์กรเลือก suppliers สองรายเพื่อ continuity แต่ทั้งคู่พึ่ง control plane และ region เดียวกัน สิ่งที่ควรทำต่อคือข้อใด

A. ถือว่าความหลากหลายของชื่อ supplier เพียงพอ
B. วิเคราะห์ common-mode/concentration dependency แล้วออกแบบ alternate/exit และ exercise recovery ที่ไม่พึ่งจุดร่วมเดียวกัน
C. เพิ่ม warranty แต่ไม่เปลี่ยน recovery plan
D. ลบ dependency ออกจาก inventory เพื่อไม่ให้เกิด finding

เฉลยข้อฝึกทบทวน

เฉลยต่อไปนี้อธิบายเหตุผลของคำตอบและตัวเลือกสำคัญที่ไม่เหมาะ เพื่อฝึกแยก evidence, stage, authority และ control objective

เฉลยข้อ 1: B

ต้อง map normalized component identity/version ผ่าน dependency graph ไป effective production inventory ก่อน จึงจะรู้ scope สำหรับ applicability และ risk analysis ตัวเลือก C อาจ patch ผิดระบบหรือพลาด runtime/transitive use ส่วน A ไม่ตอบ asset scope และ D ตีความ indirect dependency ว่าไม่สร้าง exposure

เฉลยข้อ 2: C

Signature สนับสนุน integrity/authenticity claim ภายใต้ trusted key และ verification policy แต่ไม่พิสูจน์ source safety, test, vulnerability หรือ contract liability ตัวเลือก A และ B ขยาย claim เกิน evidence ส่วน D เป็น contractual/legal conclusion [uncertain] ที่ signature ไม่ได้กำหนด

เฉลยข้อ 3: C

ผู้ประเมินต้องอ่าน scope และระบุ gap ต่อ intended service แล้วเลือก scoped report, targeted test, architecture evidence หรือ compensating control ตาม risk ตัวเลือก A ใช้ certification เกิน scope ส่วน B ทิ้ง evidence ที่อาจยังช่วยประเมิน organization บางมิติ และ D ใช้ financial remedy แทน assurance

เฉลยข้อ 4: D

Requirement ที่ตรวจได้ต้องกำหนด subject/version, trigger, channel, information, coordination, evidence และ time/authority ตาม risk ตัวเลือก A และ C กำกวม ส่วน B เป็น absolute outcome ที่ไม่สมจริงและไม่กำหนด response เมื่อพบ weakness

เฉลยข้อ 5: B

Root gap คือ interface lifecycle และ monitoring coverage ไม่ใช่พื้นที่เก็บ การกำหนด schema/version notice, test event, coverage signal และ joint response ทำให้ตรวจพบและ จัดการ change ตัวเลือก A เก็บข้อมูลที่อาจตีความไม่ได้ C ปิด detection และ D ทิ้ง customer responsibility ต่อ ingestion/correlation/response

เฉลยข้อ 6: C

Escrow มีคุณค่าเมื่อ deposit ทันสมัย ครบ มีสิทธิ์ใช้ และสามารถ build/recover ได้ภายใต้ release trigger ที่ตกลง ตัวเลือก A สับสน recovery กับ prevention B ถือว่า deposit เป็น validated capability และ D ตัด controls/knowledge ที่จำเป็นต่อ continuity ออก

เฉลยข้อ 7: B

Privilege และ build position ทำให้ plugin มี impact สูงแม้ไม่มี known CVE ต้องประเมิน origin/provenance, behavior และ lifecycle พร้อมลด authority/isolate ตัวเลือก A ใช้ absence of known identifier แทน assurance C ใช้ license model แทน trust และ D share financial consequence แต่ไม่ลด exploitability

เฉลยข้อ 8: C

Key compromise เปลี่ยน trust assumption ต้อง revoke/block, map exact artifacts/builds, contain และสร้าง version-matched evidence ใหม่ พร้อม coordinate และปรับระบบ ตัวเลือก A ทำให้ active risk รอ dispute B ไม่เปลี่ยน effective state และ D ไม่คำนึงว่า signature จาก compromised key อาจ authenticate attacker-controlled release

เฉลยข้อ 9: A

End-to-end patch outcome ต้องเชื่อม supplier fix, customer testing/rollout และ effective fleet closure ด้วย owner/evidence การทำ task แยกส่วนไม่ลด exposureเอง ตัวเลือก B ไม่ แก้ handoff C กล่าวกว้างเกินข้อมูล และ D เปลี่ยน consequence แต่ไม่ทำให้ patch deploy

เฉลยข้อ 10: B

ชื่อ supplier ต่างกันไม่สร้าง control independence หากทั้งคู่มี common-mode dependency ต้องวิเคราะห์ concentration และ exercise alternate path ที่ไม่พึ่งจุดเดียว ตัวเลือก A มอง topology ไม่ครบ C ใช้ contract แทน resiliency และ D ทำลาย visibility โดยไม่ลด risk

สรุปบท

Secure Software Supply Chain เป็นการบริหารความเชื่อและความไม่แน่นอนผ่านหลายองค์กรและ หลาย technical control plane ตลอด lifecycle แก่นของ Domain 8 สรุปได้ดังนี้

• SCRM เริ่มจาก mission/risk context แล้ว map ecosystem, identify/analyze scenario, select/treat, verify/admit, monitor/respond และ learn/exit
• inventory บอกสิ่งที่มีหรือใช้ ส่วน SBOM บอกองค์ประกอบ/relations ตาม product/build scope ทั้งสองต้อง bind version และ reconcile กับ effective state
• integrity, authenticity, provenance และ pedigree ตอบคนละคำถาม Hash, signature, attestation, SCA, test และ certification เป็น complementary evidence
• third-party analysis ต้องดู fitness, origin, privilege, vulnerability/exposure, maintenance/support, assurance, licensing, track record, concentration และ exit
• secure repository/build/transfer/custody และ admission gate ต้องรักษา immutable identity, least privilege, SoD, trust policy, evidence และ failure behavior
• acquisition requirements ต้อง measurable และครอบคลุม SSDLC evidence, audit, vulnerability/incident coordination, support, testing, shared responsibility, logging, change, EOL และ transition ตาม applicability
• IP, escrow, liability, warranty, EULA และ SLA จัดสิทธิ์ ความรับผิด evidence และ remedy แต่ไม่แทน technical prevention, monitoring, response หรือ continuity
• production component state, incident, patch/support performance และ supplier change ต้องย้อนกลับไปปรับ lifecycle, requirements, architecture, implementation, testing, operations และ contract จึงจะเป็น closed-loop governance

คำถามสุดท้ายของ risk owner ไม่ใช่ “supplier ผ่านหรือไม่” แต่คือ “สำหรับ system, version, intended use และเวลานี้ เรามี evidence เพียงพอ เชื่อ assumptions ใด ใช้ controls ใด เหลือ residual risk เท่าใด ใครมี authority และ trigger ใดทำให้ต้องตัดสินใหม่”

เชื่อมโยงไปยังบทอื่นที่เกี่ยวข้อง

บทนี้เป็นบทสุดท้ายจึงไม่มีบทที่ 9 แต่ supply chain ทำให้วงจรทั้งคู่มือย้อนกลับอย่างมี หลักฐาน ความเชื่อมโยงต่อไปนี้ใช้ตรวจว่าการตัดสินไม่หยุดอยู่ในฝ่ายจัดซื้อ

• บทที่ 1 ให้ security properties, least privilege, SoD, defense in depth, complete mediation, resiliency และเหตุผลเรื่อง control independence ที่ใช้ประเมิน supplier ecosystem
• บทที่ 2 กำหนด governance, control gates, risk owner, metrics, exception, EOL/decommission และ data disposition ซึ่งรับ supplier performance/exit evidence จากบทนี้
• บทที่ 3 สร้าง measurable third-party requirements, SRTM, data/privacy/access/misuse constraints แล้วบทนี้ทำให้ข้อกำหนด เหล่านั้นอยู่ใน selection, acquisition, shared responsibility และ contract
• บทที่ 4 กำหนด dependency/trust boundaries, interface contracts, threat paths, invariants, replaceability และ continuity topology ซึ่งต้องเปลี่ยนเมื่อ provenance/concentration/exit assumption พัง
• บทที่ 5 ทำ component integration, secure build, digest/signature และ implementation evidence ส่วนบทนี้กำกับ component origin, builder/tool pedigree, provenance, repository และ supplier lifecycle
• บทที่ 6 แยก finding/risk, test scope, V&V และ version-matched evidence ซึ่งใช้ประเมิน supplier claim และ regression หลัง update
• บทที่ 7 ให้ effective inventory, release/install state, monitoring, incident, patch, continuity และ SLA evidenceกลับมาปรับ supplier selection, treatment, contract และ exit ในบทนี้

Closed loop จบเมื่อ feedback เปลี่ยน authoritative baseline, controls, evidence และ decision จริง ไม่ใช่เมื่อทีมส่งรายงานให้กันครบเท่านั้น