SOC 2 is the report most SaaS companies reach for to prove their security posture to customers — and yet its criteria never mention dependencies, CVEs, or software bills of materials by name. That gap trips up engineering teams who assume SOC 2 is purely about access reviews and HR policies. In reality, several Trust Services Criteria map directly onto how you manage third-party code, and auditors are asking sharper questions about it every year. This guide connects the dots.
What SOC 2 actually is
SOC 2 is an attestation report, defined by the AICPA, in which an independent auditor evaluates a service organisation's controls against the Trust Services Criteria (TSC). There are five trust services categories — Security, Availability, Processing Integrity, Confidentiality, and Privacy — but every SOC 2 report includes Security, known as the Common Criteria (CC series). A Type I report assesses whether controls are suitably designed at a point in time; a Type II report tests whether they operated effectively over a period, typically 3 to 12 months.
Unlike a prescriptive standard, SOC 2 does not hand you a control list. You define controls appropriate to your environment, and the auditor evaluates them against the criteria. That flexibility is exactly why the software supply chain fits in — the criteria describe outcomes, and vulnerability management in your dependencies is one way you meet them.
The Common Criteria that map to the supply chain
Three areas of the Common Criteria are where dependencies and third-party code most clearly live:
- CC7 — System Operations. CC7 covers detecting and responding to security events, including monitoring for vulnerabilities. An auditor evaluating CC7 will ask how you identify newly disclosed vulnerabilities in the software you run — and "we don't have a process for our open source dependencies" is a finding.
- CC8 — Change Management. CC8 covers authorising, designing, testing, and approving changes. Pulling in a new dependency or upgrading one is a change; auditors increasingly expect that security review is part of your change process, not just functional testing.
- CC9 — Risk Mitigation. CC9 addresses risk mitigation, including risks arising from vendors and business partners. Your open source and third-party components are part of that vendor and supplier risk surface.
Underlying all of these is CC3 (risk assessment) and CC4 (monitoring) — you are expected to identify risks (which includes vulnerable components) and monitor whether your controls are working over time.
What auditors increasingly expect
The bar has risen. A few years ago, showing an auditor that you ran periodic scans satisfied CC7. Today, mature auditors expect to see:
- A current inventory of the components in your applications
- Continuous, not occasional, vulnerability monitoring against that inventory
- Defined remediation SLAs by severity, and evidence you meet them
- Security review integrated into change management for dependency updates
- Vendor/supplier risk assessment that accounts for third-party code
The recurring failure mode is evidence that exists but cannot be reconstructed. For a Type II report, the auditor samples across the whole period — so it is not enough to be secure today; you must show that a critical vulnerability disclosed four months ago was detected and remediated within your stated SLA, with timestamps to prove it.
A second failure mode is scope drift. Teams often scope their vulnerability management around first-party code and infrastructure, then discover during fieldwork that the auditor considers the open source dependencies inside their product to be in scope for CC7 and CC9 as well. Because most of the code in a modern application is third-party, excluding it leaves a large, visible gap in the control narrative — one that is far cheaper to close before the audit period begins than to explain away during it.
SOC 2 supply chain checklist
| Criterion | Control to evidence |
|---|---|
| CC3 / CC4 | Risk assessment that includes vulnerable components; ongoing monitoring |
| CC7 | Continuous vulnerability detection across application dependencies |
| CC8 | Security review of dependency changes within change management |
| CC9 | Vendor/supplier risk assessment covering third-party and open source code |
| Cross-cutting | Component inventory (SBOM), remediation SLAs, and retained evidence |
How Safeguard helps
Safeguard supplies the software supply chain evidence a modern SOC 2 auditor asks for and makes it reconstructable across a full Type II window. Software composition analysis continuously monitors your dependencies for newly disclosed vulnerabilities — the CC7 outcome — and records detection and remediation timestamps so a Type II auditor sampling any point in the period sees that your controls actually operated. SBOM Studio maintains the component inventory that underpins CC3 risk assessment and CC9 supplier risk, kept current per release.
Griffin AI triages findings by real exploitability and applies severity so your remediation SLAs stay meaningful and defensible, and the whole trail — inventory, findings, fixes, and dates — lives in one queryable place you can hand to an auditor rather than reconstruct across dashboards. Our compliance pages map these capabilities to the specific Common Criteria they satisfy.
If your SOC 2 program runs on a compliance-automation platform, it is worth understanding where that stops and continuous supply chain monitoring begins — our Drata comparison walks through exactly that boundary.
SOC 2 gives you room to define your own controls, but the criteria clearly expect you to manage the risk in the code you did not write. Build continuous supply chain monitoring into your program and CC7, CC8, and CC9 stop being annual scrambles.
Make your supply chain evidence audit-ready. Create a free account or read the Safeguard documentation to connect your repositories.