Vulnerability management

Every scanner (SCA, SAST, secrets, IaC, containers, licences, malware) and every SBOM upload writes findings for your organisation. Vulnerability management is what you do with them after that: decide what each one means, rank what is left, hold yourself to a deadline, and prove the work was done.

The parts

Part	What it does	Resolve Platform page	Read
Findings and triage	One deduplicated list of every finding across repositories. Each finding has a triage state, a justification and an optional custom score.	Findings › What to fix first (/resolve/findings), Awaiting Review (/resolve/awaiting-review)	Findings and triage
Suppressions	Ignore rules that hide matching findings from reports and the next scan, with an expiry and a review trail.	Configuration › Suppression Policies (/resolve/suppression-policies)	Suppressions
Risk strategies	An ordered rule list that puts every open finding in a priority tier. Drives sort=priority.	Configuration › Risk Prioritization (/resolve/risk-strategy)	Risk strategies
Remediation policy	How many days each severity may stay open, and how long a finding may wait for a triage decision. Compliance reports grade against it.	Configuration › Remediation Policy (/resolve/triage-policy)	Remediation policy
SSVC decisions	The CISA SSVC decision (Track, Track*, Attend or Act) for every open finding, from your signals and each repository’s criticality, with a policy you can tune.	Configuration › SSVC Decisions (/resolve/ssvc)	SSVC decisions
Internet exposure	Whether the vulnerable package, or its repository, runs on a publicly reachable cloud resource.	The SCA finding’s Attack Surface tab	Internet exposure
Campaigns	A named, time-boxed push with a frozen cohort and done criteria verified by later scans. Pro and above.	Findings › Campaigns (/resolve/campaigns)	Campaigns
Repository scope	Which repositories count as yours, and how the GitHub App and forge connections decide it.	Inventory › Repositories (/resolve/repositories)	Repository scope
Repository assets	Labels, an owner and a criticality on each repository, readable by risk, suppression, jail and SSVC rules as labels, owner and criticality.	Inventory › Repositories (/resolve/repositories), Asset panel	Repository labels, owner and criticality
Asset relationships	The tech stack graph built by vulnetix analyze, cross-repository edges, and threat model labels.	Overview › Tech Stack Graph (/resolve/graph), Threat Model	Asset relationships and labels

How a finding moves

1. A scan or upload writes the finding. If an active suppression covers it, it is hidden from the list as suppressed.
2. It appears in the findings list, ranked by the active risk strategy when you sort by priority.
3. A person triages it: exploitable, not_affected, false_positive, resolved and so on. Each decision mints a VEX statement for the finding, and a false_positive also creates a suppression so the next scan’s copy stays hidden.
4. The remediation policy sets the date it becomes overdue. The Exposure report (/resolve/exposure) and the PCI DSS, ISO 27001 and EU CRA reports grade against it.
5. When a later scan no longer reports it, it is gone from the open list. A campaign that admitted it records which scan proved the closure.

Who can change what

Every write records who made it: triage rows, suppression actors, campaign events and VEX statements name the principal.

API

The console calls the API at https://www.vulnetix.com/api/site/v1/, which forwards to /v1/ on the account API. The paths on these pages are written from /v1. Every route here accepts the console session or Authorization: ApiKey <orgId>:<key> (see Service accounts and API keys) and acts on the caller’s organisation. The route list is on HTTP API.

Platform IaC

How findings are ranked and fixed is kinds: RiskStrategy, RemediationPolicy and SsvcPolicy, which configures the CISA SSVC decision. Findings that are known not to matter are Suppression documents or a VexSource. Time-boxed remediation work is Campaign. A risk rule or suppression can take a when over the finding’s severity, EPSS, KEV, reachability and more; see CEL rule expressions, which also says what happens when one cannot be evaluated. Terraform and OpenTofu manages them.

When Drift protection is on, a change made in the console or through a legacy API to suppressions, risk strategies, the triage policy, the SSVC policy or campaigns that is managed as code (by Terraform or a repository) is refused with HTTP 409 managed_by_platform_iac. Change it where it is declared, or ask an admin to turn Drift protection off.