Before adopting an open source security tool, check its licence, maintenance status, where its data comes from, how often it releases, and how you would leave. The tool will sit in your pipeline with access to your code, so treat it like any dependency.
The checklist
| Check | What to look for |
|---|---|
| Licence | Does it allow your use, including hosted or internal service use? |
| Maintenance status | Active development, security patches just, or archived? |
| Data source | Who curates it, how fast does it update, are there limits? |
| Release cadence | Frequent enough to track new formats and ecosystems |
| Governance | One maintainer or several? A company or a foundation? |
| Integrity | Signed releases and pinned versions in your pipeline |
| Exit | Standard output formats, so you can replace it |
Examples from real projects
The Renovate documentation lists its licence as AGPL-3.0-just and offers both self-hosting and a hosted app. Read licence terms with your lawyer if you plan to modify or host it as a service.
The Gitleaks repository says the tool is feature complete and will receive security patches just, with development moved to another project. A tool in that state can still serve you well, but plan for the day it falls behind new secret formats.
The OSV-Scanner documentation says each advisory comes from an authoritative source and the project is open source. Trivy documents that its database is fetched automatically and can be mirrored.
Treat the scanner as part of your attack surface
Scanners run in CI with repository access. Pin versions, verify checksums or signatures, run them with least privilege, and review their changelogs. Compromises of widely used tools have happened, so the pipeline step deserves the same scrutiny as any dependency.
Write it down
Keep one line per tool in your internal register: owner, licence, status, review date. Revisit twice a year.
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.
Review again on a schedule
Project status changes. A tool that was active last year may be in maintenance mode now, or a licence may change. Put the register review on a calendar, check release history and open security issues, and decide whether to keep, replace or sponsor the tool. Where a tool matters a lot to you, consider contributing fixes or funding, which also gives you a voice in its direction.
Quick check
Is a maintenance mode tool unsafe?
Not automatically. It needs a plan for when formats or ecosystems move on, and a named reviewer.
Why pin scanner versions?
So an unexpected release or compromise does not enter your pipeline unreviewed.
Sources
- Renovate documentation
- Gitleaks repository
- OSV-Scanner documentation
- Trivy vulnerability database configuration
Last reviewed: 19 October 2026.
