Vulnerabilities
Known issues in what you run, ranked by whether they are actually reachable.
Security → Vulnerabilities collects known issues in the software you run.
Sources
| Source | Covers |
|---|---|
| Dependency scanning | Libraries in your repositories |
| Package inventory | What the agent reports as installed |
| Container images | Base images and layers |
Severity is not priority
A critical CVE in a library you import but never call on a path reachable from the internet is lower priority than a medium one in your public API's request parser.
The ranking uses:
| Factor | |
|---|---|
| Severity | The published score |
| Reachability | Is the vulnerable code on a path you actually run? |
| Exposure | Is the service public? |
| Fix available | Is there a version to move to? |
A queue sorted purely by CVSS is a queue that stays long, because the top of it is frequently not the most urgent thing. Reachability is what turns the list into work.
Acting
Each finding names the affected component, the fixed version, and where it is running — down to the servers and services. "Which of our boxes has this" is answered rather than investigated.
Accepting
A finding can be accepted with a reason and an expiry.
Always set an expiry. A permanent exception is a finding that has been forgotten with extra steps — the expiry brings it back for a decision rather than letting it quietly become policy.
Related
- Hardening — configuration rather than versions
- Compliance — what you must be able to prove
Where this behaviour lives: frontend/src/app/security/. If the code and this page disagree, the code is right — please fix the page.
Part of Security — Vulnerabilities, compliance, hardening and enterprise identity.