Key Takeaways: Third-Party and Supply Chain Risk Management
A scannable, reference-grade card. Reread this before a cert exam or a vendor review. Tables and
decision rules first; prose only where it earns its place.
The one-sentence version
Your attack surface is the union of your own and everyone you trust; TPRM manages the part you don't
control — through assessment and contract for vendors, and SBOMs + provenance for the software you didn't
build.
Core definitions (the term ledger for this chapter)
Term
Definition
Third-party risk management (TPRM)
The lifecycle discipline of identifying, assessing, mitigating, and monitoring risk from external parties (vendors, suppliers, contractors) with access to your data, systems, or facilities, or that you depend on.
Supply chain risk
The risk that a component/product/service you incorporate is compromised, tampered with, or flawed before it reaches you — importing the problem into your environment.
Software bill of materials (SBOM)
A machine-readable inventory of every component in a piece of software (name, version, supplier, dependency relationships). Formats: SPDX, CycloneDX.
Fourth-party risk
Risk from your vendors' vendors (sub-processors, dependencies) — no direct contract, low visibility and leverage.
Vendor security assessment
Structured evaluation of a vendor's security posture: questionnaire + independent audit evidence (SOC 2/ISO 27001) + external signals.
Contractual security requirements
Binding security obligations in the vendor contract that make posture enforceable (right to audit, breach notification, etc.).
Continuous vendor monitoring
Keeping a vendor's risk picture current throughout the relationship (re-assessment, security ratings, breach/news watch, SBOM/vuln tracking).
Software provenance / SLSA
Verifiable record of where an artifact came from, what source/build produced it, and that it wasn't tampered with. SLSA = a graduated framework for build integrity.
Concentration risk
Outsized dependence on a single vendor/product/provider, so one failure has systemic impact — not fixable by a better assessment.
The three (plus one) flavors of "their risk"
Flavor
What goes wrong
Meridian example
Primary treatment
Data/access risk
Vendor holds your data or reaches your systems; their breach exposes you
Breached payroll processor leaks SSNs
Assess, least-privilege access, contract
Supply chain risk
A component you deploy is compromised/flawed before delivery
The rule: an SBOM has value only when continuously matched against vulnerability feeds —
NVD/NIST CVE, CISA KEV (actively exploited), OSV.dev (open-source). Stored-and-ignored = an
ingredient list nobody checked against the recalls.
Read a dependency graph: follow dependsOn to find transitive components (the buried Log4j).
Scoring a vendor questionnaire (the decision rule)
Assign each control a weight (importance) and an answer score 0–4.
Critical-control override: if any critical control scores below 2, cap the tier at HIGH-RISK
regardless of the average. (A 91% can't hide a missing admin MFA.)
Output a structured verdict, never a bare percentage: overall rating + flagged gaps + required
remediations + named residual risk.
Corroborate critical "yes" answers with evidence (SOC 2, pen-test summary, policy proof) — trust,
but verify.
Vendor-breach response playbook (you didn't cause it; you still run it)
1. CONFIRM & SCOPE — what of OURS is affected? (data inventory saves you)
2. CONTAIN YOUR SIDE — revoke vendor access (keys/VPN/creds); isolate their product
3. HUNT BLAST RADIUS — IoC match + beaconing + lateral-movement/identity hunt (Ch.22,10)
4. INVOKE CONTRACT — demand details + notification within the contracted window
5. MEET OBLIGATIONS — YOUR regulator/customer notifications (duty does NOT transfer)
6. REASSESS — re-tier, decide to continue, demand improvements, feed lessons
If the vendor's product runs in your network with privilege → it's a FULL IR event (Ch.24), not a
procurement task. Put the "trusted vendor compromised" scenario in your IR plan and tabletop it.
Stay on your side of the line: investigate your logs/data/access only; never probe the vendor's
systems (unauthorized access). The right-to-audit clause is the lawful channel.
Common pitfalls (memorize)
Treating a SOC 2 report as a pass without checking scope/date/exceptions.
Taking self-attestation at face value for critical controls (no corroboration).
Reducing a questionnaire to one percentage that hides a failed critical control.
Assessing once at signing and never monitoring (the vendor drifts for years).
Offboarding without confirming data destruction / revoking access (years-later leaks).
Program: a TPRM standard — vendor inventory + 3-tier scheme + lifecycle + contractual-requirements
checklist + SBOM requirement (with the consuming/feed-matching process) + vendor-breach playbook.
Concentration-risk note feeds the Chapter 27 enterprise risk register. Slots between compliance mapping
(Ch.28) and the awareness program (Ch.30).
bluekit:compliance.py gains vendor_risk(answers) — weighted questionnaire scoring plus a
critical-control override that caps the tier when a critical control fails. (Joins policy_coverage
(Ch.26) and crosswalk (Ch.28) in the same module.)