A scanner disagreement log should record, for every conflict: the package and version, both tools and their versions, the input file, the likely cause, the decision, the evidence, the owner and a review date. One row per disagreement is enough, and it doubles as audit evidence.
Why keep a log at all
Without one, each disagreement is argued from scratch, decisions are lost when people change roles, and nobody can show a customer or auditor how a gap was handled. A log converts a recurring annoyance into a record.
It also lets you spot patterns. If a third of your rows share the cause "different scope setting," you fix the setting once instead of resolving the rows one by one.
The template
| Column | What to write |
|---|---|
| Date | When the conflict was found |
| Package and version | Normalized name and exact version |
| Advisory IDs | All known aliases |
| Tool A result | Finding or none, plus tool version |
| Tool B result | Finding or none, plus tool version |
| Input | File or artifact, and commit |
| Cause category | Input, naming, version range, scope, unit, data timing, other |
| Decision | Affected, not affected, accepted risk, fix scheduled |
| Evidence | Link to the advisory or maintainer note |
| Owner | Named person or team |
| Review date | When to look again |
Use a spreadsheet or a file in your repository. A file in version control gives you history for free.
How to fill it in
- Add a row when you notice a conflict. Do not wait for a perfect analysis.
- Classify the cause from a fixed list. A fixed list lets you count causes later.
- Read the advisory yourself. The OSV schema tells you how to read the affected and fixed fields.
- Write the decision and the evidence. One sentence and a link.
- Set a review date. Accepted risks should expire.
- Close the row when the underlying change is made, and note the commit or ticket.
Using the log
Review it monthly. Sort by cause and count. Ask which categories you can remove by changing configuration, for example aligning scope or pointing both tools at the lockfile, as covered in the npm audit documentation on lockfiles and repeatable results. Anything left over is a genuine data difference and deserves a closer look.
Use it in reviews with customers and auditors as a sample of how you handle conflicting evidence. Share a redacted version if rows name internal projects.
What not to log
Do not store secrets or exploit details. Do not put customer names in rows. Keep the language factual and short. If a row says a tool is wrong, back it with the advisory text rather than opinion.
Keep it light
The log fails when it becomes a chore. Cap it to conflicts that changed a decision or a gate. Routine duplicates, where both tools agree, do not belong. If the log passes a few hundred rows, archive closed rows each quarter and keep a summary of cause counts.
Quick check
Who should own the log?
One named person or team, usually application security or the platform team, with contributions from developers.
Is this a compliance document?
It is an internal record that can serve as supporting evidence. It does not by itself satisfy any framework requirement.
Sources
Last reviewed: 19 October 2026.
