Security Advisory & CVE Vulnerability Matrix Markdown Table Template
A vulnerability matrix is the table users open when a scanner flags your package or a security team asks “are we affected?”. Each row ties a public identifier to the part of your software it affects, how severe it is, which versions are exposed, and which release fixes it. It belongs in a SECURITY.md, a release-notes page, or an audit appendix, and it is often the only security documentation downstream users read.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
Readers arrive with a version number and a deadline. A platform engineer wants to know whether 1.9.8 is safe; a compliance auditor wants evidence that known issues were triaged and fixed within policy; a downstream maintainer wants the exact release to pin. The matrix supports those decisions only if the version ranges are precise and consistent with the patched release, and if the severity rating matches the published score.
The best matrices are boringly exact. They link every CVE to its authoritative record, state which CVSS version and which scoring source (NVD or your own CNA score) they use, express affected versions as a closed range, and list every patched release line, including backports. Weak matrices approximate: “older versions” instead of a range, a severity word that contradicts the score, or a patched version that leaves a gap in the vulnerable range.
Formatting This Table in Markdown
A security advisory & cve vulnerability matrix table puts a few things in cells that Markdown treats as syntax. These are the ones to watch so it renders correctly on GitHub, GitLab, Obsidian and docs sites.
Link the ID and keep it monospace
Do not rely on a renderer to link bare CVE IDs. Put the code span inside the link text so the ID stays monospace and becomes clickable, and move the long NVD address into a reference definition under the table so each row stays short.
Version ranges with double bars need escaped pipes
npm-style ranges such as
>=1.0.0 <1.2.3 \|\| >=2.0.0 <2.1.0contain||, and each bar splits the cell even inside a code span, so both must be escaped. For long ranges, state them in prose below the table; see escaping pipes.Pair a severity emoji with the word
Colour is not available because GitHub strips
styleattributes, so severity is carried by bold text and optionally an emoji. Keep the word (🔴 **CRITICAL**), since an emoji alone is ambiguous to screen readers and to readers who cannot tell the colours apart.CVSS vectors are long and unbreakable
A vector such as
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hhas no spaces, so a browser has nowhere to wrap it and the column widens. Link it to the advisory, or fold it into a<details>element, which GitHub renders inside cells, instead of inlining it in every row.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| CVE Identifier | left :--- | The full ID in the form CVE-YYYY-NNNN (four or more digits), linked to its record on cve.org or NVD. The year is when the ID was reserved, not necessarily when the issue was disclosed. Add the GHSA ID too if you publish GitHub advisories. |
| Affected Component | left :--- | The module, function, or feature that contains the flaw, plus the vulnerability class: “JSON deserializer — unsafe deserialization”. Name the class with familiar terms (or a CWE ID) so readers can judge whether their usage is exposed. |
| CVSS v3 | center :---: | The base score to one decimal, centered for quick comparison. Say which minor version (3.0 or 3.1) and which source produced it; NVD and the vendor sometimes disagree. Keep the full vector string available in a linked advisory. |
| Severity | center :---: | The qualitative rating that the score falls into, never a separate opinion: Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, Critical 9.0–10.0. Centered, and bold only High and Critical so the urgent rows stand out. |
| Vulnerable Versions | center :---: | A range in your ecosystem’s syntax, ideally with both ends: >= 1.4.0, < 1.9.9. The upper bound should equal the first fixed version, so the range and the Patched In column can be checked against each other. |
| Patched In | right ---: | Every release that contains the fix, one per supported line (2.0.4, 1.9.12). Right-aligned per the template; use exact versions, not “latest”, so readers can pin and auditors can verify against the changelog. |
How to Fill It In
- 1Pull the authoritative record for each CVE from cve.org or NVD, and from your own advisory if you are the maintainer. Copy the ID, description, and published score rather than retyping them.
- 2Determine affected versions by testing, not guessing: bisect to the commit that introduced the flaw and the one that fixed it, then map both to releases. Check whether older maintained branches received backports.
- 3Compute or confirm the CVSS score with the FIRST calculator from the vector string, then derive the severity word from the standard bands so the two columns cannot disagree.
- 4Cross-check every row: the upper bound of Vulnerable Versions should be the lowest version in Patched In for that release line, and that version must exist on your package registry.
- 5Publish the matrix in
SECURITY.mdor your advisory page, and update it when scores are revised or new backports ship. A status legend helps if you add a supported-versions column.
Ready-to-Paste Variations
CVSS qualitative severity bands
The rating scale defined in the CVSS specification. The same bands apply to v3.x and v4.0 scores, so this lookup works for either.
| Severity | Score range | Typical response target |
| :--- | :---: | :--- |
| None | 0.0 | No action |
| Low | 0.1 – 3.9 | Next scheduled release |
| Medium | 4.0 – 6.9 | Within the regular patch cycle |
| **High** | 7.0 – 8.9 | Expedited release |
| **Critical** | 9.0 – 10.0 | Emergency release and advisory |SECURITY.md supported versions
The table GitHub’s security policy template suggests, extended with the latest patch so users know which exact release to install.
| Version | Supported | Latest patch |
| :--- | :---: | ---: |
| 2.0.x | ✅ Yes | `2.0.4` |
| 1.9.x | ✅ Security fixes only | `1.9.12` |
| 1.8.x | ❌ No | `1.8.7` |
| < 1.8 | ❌ No | — |Triage view with vector and exploitation status
For an internal security review, where the question is what to fix first. Placeholder IDs; replace with the real records you are assessing.
| CVE | CVSS v3.1 vector | Score | Known exploited | Reachable here | Priority |
| :--- | :--- | :---: | :---: | :---: | :--- |
| `CVE-2026-XXXX1` | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` | 9.8 | Yes | Yes | Patch today |
| `CVE-2026-XXXX2` | `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N` | 5.9 | No | Yes | Next sprint |
| `CVE-2026-XXXX3` | `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` | 7.8 | No | No | Track, no action |Common Mistakes
Writing a severity word that contradicts the score, such as 4.2 labelled Low.
Derive severity from the score with the standard bands. 4.0–6.9 is Medium, so 4.2 must be Medium; if you believe the real risk is lower, explain that separately rather than relabelling.
Leaving a gap between the vulnerable range and the fix, like
< 1.9.8vulnerable but patched in1.9.9.Either 1.9.8 is fixed (and is the patched version) or it is vulnerable (and the range is
< 1.9.9). Make the range’s upper bound equal the first fixed release.Treating the CVSS base score as the priority order.
The base score measures severity, not risk to you. Combine it with exploitation evidence (CISA’s Known Exploited Vulnerabilities catalog, FIRST’s EPSS) and whether the vulnerable code is reachable in your deployment.
Using real-looking CVE numbers as examples in docs or tests.
Real IDs belong to real vulnerabilities in other products, and scanners or readers may match them. Use clearly fake placeholders such as
CVE-2026-XXXX1in examples.
Related Markdown Table Templates
Browse all 50 templatesTechnical SEO Audit & Meta Tags Matrix
Technical SEO spreadsheet matrix recording URL routes, target search keywords, title tag lengths, meta descriptions, and indexation status.
Team Roles & Permissions Matrix (RBAC)
Role-Based Access Control matrix mapping organizational roles to CRUD operations, billing controls, and administration privileges.
Risk Assessment & Mitigation Matrix
Identify potential technical and business risks, calculate probability and impact scores, and document mitigation strategies.
Security Advisory & CVE Vulnerability Matrix: Frequently Asked Questions
Should I report CVSS v3.1 or v4.0 scores?
FIRST published CVSS v4.0 in November 2023, and more CNAs now provide v4.0 vectors, but many scanners and policies still key on v3.1. Where both exist, show both in separate columns and say which one your remediation deadlines use.
Why does NVD show a different score than the vendor advisory?
NVD analysts may score the same CVE independently of the CNA that assigned it, and they can weigh attack conditions differently. Record which source you used. If you are the vendor, your advisory’s score is the one users should see first.
How do I get a CVE for a vulnerability in my project?
Request one from a CVE Numbering Authority. For a GitHub-hosted project the simplest path is to draft a repository security advisory and request a CVE from GitHub, which is a CNA; otherwise MITRE acts as the CNA of last resort.
Where should the links in the CVE column point?
Use https://www.cve.org/CVERecord?id=CVE-… for the canonical record or https://nvd.nist.gov/vuln/detail/CVE-… for NVD’s enriched entry with scores and references. Pick one and use it consistently across the table.