Set up software composition analysis in CI in four steps: commit your lockfiles, generate a dependency inventory on every build, report findings without failing builds, and only then add a gate on a narrow rule such as known exploited vulnerabilities. Gating first usually gets the whole check switched off.
Why does order matter?
Teams often start by asking "what should fail the build?" That is the last question, not the first. A gate built on an inventory you have not trusted yet will fire on noise, block a release on a Friday, and get disabled by Monday.
Each step below produces something the next step needs. Skip one and the later steps rest on guesses.
Step 1: Are your lockfiles committed?
SCA tools resolve what actually installs. A manifest says ^4.17.0; the lockfile says which 4.17.x you shipped. Without the lockfile, the tool guesses, and transitive dependencies (the ones you never chose) are where most of the surprises live.
Check every repository for package-lock.json, yarn.lock, poetry.lock, go.sum, Cargo.lock or the equivalent. OWASP's guidance on software supply chain failures starts the same way: keep an inventory that includes transitive dependencies.
Step 2: Can the pipeline produce an inventory?
Run the scanner in report mode and keep the output as a build artifact. Safeguard's CI documentation describes two routes. You can connect the repository so the platform scans it and evaluates your policies, with nothing extra in the pipeline. Or you can run the CLI in the job: safeguard detect writes SARIF or JSON, and safeguard scan writes a results folder.
Two practical notes from that page. Pin the CLI version with SAFEGUARD_VERSION so a release does not change a build under you. And safeguard scan needs syft and grype on the PATH, which a fresh CI runner does not have.
Open the dependency inventory demo
Step 3: Should findings fail the build yet?
No. Report them for two to four weeks. Read what shows up. Count how many findings are in code you never call, how many are in dev-only dependencies, and how many repeat across services.
Be aware of one documented limit: the Safeguard CLI "reports findings; it does not fail a build on them." Enforcement comes from the platform's policy gates, and exit code 0 means the scan ran, not that it was clean. If you rely on exit codes alone, nothing will ever block.
Step 4: What is a safe first gate?
Pick a rule with almost no false positives. Good first candidates:
- A dependency on CISA's Known Exploited Vulnerabilities list. CISA says the catalog should be an input to your prioritization, and every entry has confirmed exploitation.
- A package flagged as known malicious.
- A new critical finding in a package the pull request added, not the whole backlog.
Gating on "new in this change" keeps old debt from blocking unrelated work. Reachability data, where your tool provides it, can narrow a rule further, though Safeguard's own docs warn that reflection and dynamic dispatch leave some results unknown.
What are the honest limits?
SCA only knows about published advisories and listed packages. It will not find a flaw in code you wrote, and it cannot tell you a package is safe, only that nothing is known. Pair it with static analysis for your own code and with install-time checks for malicious packages.
What to do
- Audit lockfiles in every repo this week and commit the missing ones.
- Add a report-only SCA job and save its output as a build artifact.
- Pin the scanner version in CI.
- Review a month of results and write down which findings the team would have acted on.
- Add one narrow gate, such as known exploited vulnerabilities, and review it after two weeks.
Quick check
Should the first SCA job block merges?
No. Start in report mode, learn what your baseline looks like, then gate one narrow rule.
Does a zero exit code mean the dependencies are clean?
Not with the Safeguard CLI. Per its CI documentation, exit code 0 means the scan ran regardless of findings. Enforcement comes from policy gates on the platform.
Sources
- Safeguard docs, CI/CD integration
- Safeguard docs, Software composition analysis
- Safeguard docs, Reachability analysis
- OWASP Top 10 2025, A03 Software Supply Chain Failures
- CISA, Known Exploited Vulnerabilities catalog
Last reviewed: 18 October 2026.
