A startup needs six working dependency controls before a SOC 2 audit: an inventory of what you ship, pull request review for changes, automated vulnerability scanning, a written fix timeline, a way to record exceptions, and evidence that all of it runs. SOC 2 is an attestation from an independent CPA, not a certificate, so the goal is controls you can prove.
Why dependencies show up in a SOC 2 audit
Your product is mostly other people's code. Auditors do not read your package.json for fun, but they do test whether you manage vulnerabilities and control changes to production. Third-party libraries sit in the middle of both topics. If a critical flaw lands in a library you ship, the auditor wants to see that you noticed, decided, and acted, with dates.
SOC 2 does not hand you a checklist of dependency tasks. You describe your own controls, and the auditor tests whether they operate as described. That is good news for a small team: you choose controls you can actually run. It is also a trap, because a control you write down and then skip becomes an exception.
The six controls
| Control | What it looks like in a small team | Evidence it leaves behind |
|---|---|---|
| Inventory | Lockfiles committed in every in-scope repo, plus a generated component list | Repo files, a dated export |
| Change review | Dependency changes go through a pull request with an approver | PR history, branch rules |
| Scanning | Automated checks on pull requests and on the default branch | Scan results, alert history |
| Fix timeline | A short written policy by severity | The policy, ticket dates |
| Exceptions | A record for anything you choose not to fix on time | Exception tickets with owner and expiry |
| Operation | A monthly look at open items | Meeting notes, sampled tickets |
Start with the first row. You cannot manage what you cannot list, and GitHub documents that its dependency graph is a summary of the manifest and lock files in a repository, so committed lockfiles give you a usable inventory almost for free.
Keep each control small enough to run
A common mistake is writing a policy that promises more than the team can deliver. Weekly reviews of every transitive package sound responsible and collapse by March. Pick cadences you can keep during a bad sprint.
Practical sizing for a team under 30 engineers:
- Turn on automated alerts for known vulnerabilities in every in-scope repository.
- Require one approving review on the default branch, so a dependency bump cannot reach production unreviewed.
- Set a fix timeline with three or four severity bands, and write the same numbers in your questionnaires.
- Open an exception ticket whenever you miss it. Missing a date is survivable. Missing a date with no record is the finding.
- Hold a 30 minute monthly review and save the notes.
What not to promise
Do not tell a buyer your dependencies are "fully secure" or "continuously monitored" unless a scheduled job proves it. Do not describe SOC 2 as something you "have" before the auditor issues a report. Say what you operate today and what is in progress.
Try it yourself
Open the demo and look at how a dependency inventory is built from manifests, then notice which fields you could export as dated evidence.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, reachability analysis and policy gates can supply the inventory, scan and review records described above, and its compliance and evidence automation helps organize them. You can run a free scan at https://gold.safeguard.sh/scan. Safeguard does not replace your auditor or make you certified.
Quick check
Does SOC 2 say how fast I must patch a library?
No. SOC 2 expects you to define your own timeline and follow it. Choose numbers you can meet and record exceptions when you cannot.
Do I need all six controls on day one?
Not perfect versions. Have each one running in a simple form, and keep the records from the first day they operate.
Sources
- AICPA and CIMA, SOC suite of services
- GitHub Docs, About the dependency graph
- GitHub Docs, About Dependabot alerts
Last reviewed: 19 October 2026.
