A known issues register is a short table of open security findings: what it is, how severe, whether it is exploitable in your product, who owns it and when it will be fixed. Giving one to a buyer shows you know your gaps, which is usually worth more than claiming you have none.
Why include one
Every real codebase has open findings. A scan report with hundreds of rows tells a reader very little, while a register with twenty triaged rows tells them how your team thinks. Nothing hurts credibility like a buyer finding an issue that your documents said did not exist.
The columns
| Column | Content |
|---|---|
| ID | Advisory or CVE identifier, or internal ticket |
| Component | Package, version, product |
| Severity | Rating you use, plus the source |
| Exposure | Internet facing, internal, build time |
| Exploitability | Affected, not affected with reason, under investigation |
| Known exploited | Yes or no against the CISA catalog |
| Owner | A named role |
| Target date | A date you control |
| Status | Open, mitigated, fixed, accepted |
Using standard status words
OpenVEX defines four statuses: not_affected, affected, fixed and under_investigation. Borrowing them gives your register a vocabulary buyers already recognise. For not_affected, OpenVEX expects a justification, and the labels it lists include vulnerable_code_not_in_execute_path and vulnerable_code_not_present. A reason you can name is much better than the word "unaffected" on its own.
If you later want to publish the same facts in machine readable form, the register converts easily.
Checking the known exploited catalog
CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with reliable evidence of active exploitation. CISA's directive for federal agencies sets default remediation windows for catalog entries, including two weeks for CVEs assigned in 2021 or later. Your company is not bound by that directive, but a column for catalog membership lets a buyer see at a glance which rows deserve urgency. Any open row that is in the catalog needs a short explanation.
Steps to build it
- Export findings from your scanner for production dependencies.
- Remove duplicates and dev-only items, noting you did so.
- Triage the highest severity rows first and write an exploitability status.
- Add owners and dates. If a date is unknown, say "not yet scheduled" rather than guessing.
- Review it with engineering leads before it leaves the building.
- Date the document and keep each version.
Red flags to fix first
Rows with no owner. Target dates already in the past. Severity changed with no note. Accepted risks with no approver. Any known exploited item marked "monitor".
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are triaged, assigned and tracked, which is the same data a register summarises.
Safeguard supports vulnerability triage with reachability analysis, so the exploitability column can be backed by evidence. Run a free scan to see findings for one repository.
Quick check
Should the register include low severity items?
Include them in a count by severity, and list individually those with exposure or exploit evidence.
Is sharing open issues risky?
It can be, so use a controlled data room with access logs and share the detailed rows with just the people who need them.
Sources
- OpenVEX specification
- CISA, BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
