A typical open source AppSec stack combines a dependency scanner, a static analysis tool, a secrets scanner, an infrastructure as code checker and a container scanner. Each does its job well. What is usually missing is the layer that joins them: one inventory, one set of owners, one policy and one report.
The usual pieces
| Need | What teams commonly run | Output |
|---|---|---|
| Vulnerable dependencies | A lockfile scanner such as OSV-Scanner, or Dependabot alerts | List of known issues |
| Code flaws | An open source static analysis tool | Findings with locations |
| Secrets | A secrets scanner such as Gitleaks | Leaked credential candidates |
| Infrastructure as code | A misconfiguration checker | Policy failures |
| Containers | An image scanner | OS and package issues |
OSV-Scanner matches a project's dependency list against the OSV database and can run in CI. Gitleaks scans git history, directories and stdin, and supports a baseline so later runs report just new findings. Dependabot alerts come from the GitHub Advisory Database and just reviewed advisories trigger alerts.
The glue you have to write
- Normalisation. Each tool has its own output format and severity scale. Someone maps them to one format.
- Deduplication. The same vulnerable package appears in the dependency scan and the image scan.
- Ownership. Findings need a team, and teams change.
- History. Raw reports are snapshots. Trend lines need a datastore.
- Policy. Gates need exception handling, or developers route around them.
What remains missing
Reachability (is the vulnerable code actually called), exploit context, evidence for auditors and a view for non technical readers. You can build parts of this. Whether you should depends on how many hours you can commit, as the earlier worksheet shows.
How to start small
Pick the three scanners that match your highest risk, run them on one repository, and write down every manual step you take in the first month. That list is your real glue backlog and your honest basis for build versus buy.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
A note on choosing tools
Match tools to your languages first. A scanner that handles your main ecosystem well is worth more than a long list of tools with shallow support. Check each project's licence and maintenance status, and keep a one line register of who owns each tool. Add a new scanner just when you can name the person who will triage its output, otherwise it becomes one more list nobody reads.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one inventory joins findings from different sources, which is the layer a script stack usually lacks.
Quick check
Is one scanner enough?
For a small codebase, sometimes. Dependencies, code, secrets and images fail in different ways, so most teams end up with more than one.
What do teams build themselves most often?
Normalisation, deduplication and reporting around the scanners.
Sources
Last reviewed: 19 October 2026.
