When a dependency scanning proof of concept finds real vulnerabilities, they belong to the same owners as the code, not to the trial. Agree before day one who triages, who fixes, how urgent items are escalated, and where findings are stored, so the PoC does not create a private list of known risks.
The awkward truth about PoCs
You are running a scanner on real repositories. It will find real issues. Some will be old and harmless. A few may be serious and in production. Once someone has seen them, they are known, and a known, unaddressed risk is a different position from an unknown one.
Teams often forget this. The PoC runs in a corner, results sit in a vendor dashboard, and nobody checks whether a serious finding was ever fixed. Plan for it.
Decide four things before the trial
- Triage owner. One named person who looks at every high priority finding within a set time during the trial.
- Fix owner. The repository's usual maintainers, who are told in advance that findings may arrive.
- Escalation rule. What counts as urgent. A reasonable rule: any finding on the CISA Known Exploited Vulnerabilities list in a reachable, internet facing service goes straight to the service owner the same day.
- System of record. Findings that need action go into your normal tracker, not only the PoC tool.
CISA describes KEV as the authoritative source of vulnerabilities exploited in the wild and recommends using it as an input to prioritization, which makes it a clean, defensible trigger for the escalation rule.
A simple routing table
| Finding type | Who sees it first | Where it lives |
|---|---|---|
| Known exploited, reachable, production | Service owner and security lead | Normal incident or ticket queue |
| High severity, not known exploited | Repo maintainers | Backlog with a date |
| Low severity, dev only | PoC team | PoC log only |
| Disputed or unclear | Triage owner | PoC log, revisit at readout |
Tell the repo owners
Nothing sours a PoC faster than a team learning from a vendor email that their repo was scanned. Send a short note: what is being tested, which repos, for how long, what access the scanner has, and who to ask. Say that findings will be shared with them and that you are not grading their work.
Keep disclosure internal and calm
Do not paste real findings into chat channels, slide decks or vendor shared documents. Share counts and categories in status updates. Keep detail in the tracker with normal access controls. If a vendor asks to use your findings in marketing, say no unless your leadership agrees in writing.
At the end of the PoC
Reconcile. List every high priority finding raised during the trial and mark it fixed, accepted with a date, or false positive with a reason. If anything is still open, give it an owner. Include the count in the readout, because it is a real outcome of the test: the scanner produced something worth acting on, or it did not.
What if the PoC ends and you do not buy?
The findings are still yours. The vulnerabilities do not go away when the trial ends. Export the list before access closes, load it into your own tracker, and note the date. See what to do with your data when a trial ends.
Try it yourself
Click through the demo to see how a finding moves from detected to assigned to resolved, and ask who would hold each step in your team.
Click through it at your own pace, or open it full screen.
Quick check
Should developers be told about the PoC?
Yes, at least the owners of the scanned repos. Surprise findings from an unknown tool damage trust.
Do PoC findings need to be fixed?
Serious, reachable ones should be handled like any other finding. Low value ones can stay in the PoC log with a note.
Sources
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
