Write your own only if a small script on public advisory data meets your need, such as one language and a few repositories. Beyond that, the parsers, data upkeep, matching edge cases and triage workflow add up to a product. Most teams that start with a script end up maintaining a tool they never planned to own.
The thin version that works
If you have one ecosystem, you can write a script that reads the lockfile, queries a public advisory database and prints affected packages with fixed versions. A day of work, no license, and perfectly good for a single service. Run it in CI and fail on critical findings.
Be honest about what it will not do: no transitive path display beyond what the lockfile gives, no prioritisation, no history, no reports.
What grows around it
Every extra requirement adds a component:
- Parsers. Each package manager has several lockfile formats and versions, plus workspaces, overrides and aliases.
- Advisory data. Public sources differ in format and quality. You need ingestion, normalisation and a way to handle withdrawn or corrected records.
- Matching. Version range logic differs by ecosystem. Pre-release ordering, epoch prefixes and distro backports cause wrong answers.
- Storage and history. To show trends and closure you need a database and a retention policy.
- Prioritisation. Severity alone is weak. Adding exploit signals and reachability is a real engineering effort.
- Triage workflow. Suppression with reasons, ownership, expiry and tickets.
- Reporting. Auditors and customers want evidence in a form they accept.
- Maintenance. New ecosystems, format changes, API shifts and your own bugs.
None of these is impossible. Together they are a team's worth of ongoing work.
A cost test
Estimate honestly:
- How many engineer-weeks to reach the features you need?
- How many to maintain per quarter?
- Who owns it when the author leaves?
- What is the cost of one false negative caused by a bug in your own matching?
If the answers are uncomfortable, buy or adopt an open source tool and put your effort into the integration and policy layer, where your knowledge is truly unique.
When building makes sense
- You have an unusual build system or an internal package format no tool reads.
- You need to embed checks in a proprietary platform.
- Your requirements for data handling rule out every option.
Even then, consider building only the adapter that feeds an existing scanner, rather than the whole engine. See the broader build vs buy guide.
A staged approach
Start with the script. Write down the day it first fails you: a missed ecosystem, a request for a report, a developer asking for fixes. When two or three of those arrive, re-run the cost test with real data.
Where Safeguard fits: SBOM and dependency scanning is available as a ready-made option, and the free scan lets you compare it with your script's output on a public repository.
Quick check
Is a homegrown script a compliance risk?
Not by itself, but you must show it runs consistently, covers your scope and produces retained evidence. Those parts are easy to neglect.
Last reviewed: 19 October 2026.
