Vulnerability management,
measured against the SLA you promised.

• Findings from the SDK in CI, from Trivy, or posted by any scanner through the API
• Remediation SLAs by severity: critical 7 days, high 30, medium 90, low 180
• SLA breaches and mean time to remediate, computed from real timestamps
• A risk score that weighs CVSS with exploitability where you record it
• Each finding linked to the controls it affects in every framework you run

An auditor wants three things from vulnerability management: a defined remediation timeline per severity, evidence that findings were found continuously, and proof of how many were fixed inside that timeline. ISO 27001 Annex A 8.8 and SOC 2 CC7.1 both read this way. A clean scan on the day of the audit answers none of them.

So the record that matters is the history: when each finding was first seen, when it was fixed, and whether that was before its deadline. The platform keeps that history and computes the breach count from it.

1. Findings arrive from your pipelineThe SDK runs a dependency audit in CI; if Trivy is installed it adds dependency, container and misconfiguration findings; any other scanner can post findings to the API. Nothing is generated by the platform.
2. Each finding gets a deadlineThe severity sets the remediation deadline: 7 days for critical, 30 for high, 90 for medium and 180 for low, counted from when the finding was first seen.
3. Findings are enriched by rulesEach finding is given an exploit maturity, an SSVC decision and a risk score that combines CVSS with exploitability fields where they are recorded, so the order you fix things in is not CVSS alone.
4. Findings are linked to controlsA vulnerability carries links to the framework controls it affects, so an open critical shows against vulnerability management in SOC 2, ISO 27001 and the other frameworks you run.
5. Fixing it closes the clockWhen a finding is fixed, the time from first seen to fixed is recorded. Breaches of the SLA and mean time to remediate are computed from those timestamps.

Because a vulnerability list nobody can trace to a scanner is worse than an empty one. The platform does not run scans against your code from outside; findings come from the tools that ran in your pipeline, and a scan button with nothing connected says so instead of returning sample data.

Common remediation SLAs are 7 days for critical vulnerabilities, 30 days for high, 90 for medium and 180 for low, which is the default policy in TryTrustable. They are a starting point, not a standard: the right timeline is one your team can meet consistently, because an auditor tests whether you kept your own promise.

Set the clock from when the finding was first seen, not from when someone triaged it, or the measured time will look better than the real exposure. Decide in advance what happens when a fix does not exist yet: record an accepted risk with a reason and a review date rather than letting the finding sit in breach.

Report two numbers every month: how many findings breached their SLA, and the mean time to remediate per severity. A falling breach count is the clearest evidence that the process works.

CVSS measures how bad a vulnerability could be in general, not how likely it is to be exploited in your environment, so sorting by CVSS alone puts unreachable criticals ahead of reachable highs. Better prioritisation adds whether the vulnerability is being exploited, whether exploit code exists, and whether the affected component is reachable.

TryTrustable combines CVSS with exploitability fields into a risk score, and assigns an SSVC decision and exploit maturity by rule. Where you record whether a CVE is on the CISA Known Exploited Vulnerabilities catalogue or its EPSS probability, those feed the score. The platform does not fetch KEV or EPSS itself today, so a KEV listing counts only once someone records it.

Reachability is where attack paths help: a vulnerability on a host that an exposed path reaches matters more than the same CVE on an isolated one.

You evidence vulnerability management with a history, not a snapshot: the date each finding was first seen, its severity and deadline, the date it was fixed, and the exceptions accepted along the way. A clean scan on the day of the audit shows only that the last week went well.

Auditors usually sample. They pick findings from the period and ask when each was found, when it was fixed and whether that met your policy. Keep that record somewhere it cannot be quietly edited; the platform's evidence ledger is append-only for this reason.

Keep the policy and the record consistent. If the policy says 30 days for high and the record shows 45 as normal, the auditor will find the gap; either change the policy or fix the process, but do not let them disagree.

• Your vulnerability management policy, with remediation timelines by severity
• Evidence that scanning ran throughout the audit period, not only before the audit
• A sample of findings with first-seen date, deadline and fix date
• The SLA breaches in the period and what was done about each
• Accepted risks, with the reason, the approver and the review date
• How you learn about vulnerabilities in components you did not write

• It does not scan your code or infrastructure from outside; findings come from tools that ran in your pipeline or were posted to the API
• It does not fetch the CISA KEV catalogue or EPSS scores automatically
• Its built-in dependency audit covers JavaScript and TypeScript projects; other ecosystems need Trivy or another scanner
• It does not patch anything or open pull requests
• A Run scan button with nothing connected returns an explanation, never sample findings

Every result here is a control result on the same graph as the rest of the platform, so it reaches each framework that asks for it without being gathered again. Coverage lists the regimes.

Related reading: code security scanning, attack paths and the SOC 2 guide.