Container vulnerability management
Scanning is the commodity.
The decision is the product.
Any scanner can tell you a container image has 300 vulnerabilities. TRUSTIVAN remembers which ones you already triaged, who accepted the risk and until when, and whether this build satisfies the policy you wrote — every time the image is scanned again.
Scans container images from public registries, and from private ones with a stored credential. No Docker socket, no agent installed on your hosts, no access to your build host.
One product, two parts
TRUSTIVAN AppSec and TRUSTIVAN NHI Security
One sign-in, one organization and one dashboard, over two parts that each keep their own backend and database.
TRUSTIVAN AppSec
Scans container images, repositories, filesystems and SBOMs, then keeps every finding's triage, suppression and policy verdict. The rest of this page is about AppSec.
TRUSTIVAN NHI Security
Inventories service accounts, workload identities and the tools of MCP servers through connectors, maps who owns them and what they reach, and authorizes an AI agent's action at runtime. It does not discover AI agents, and it has not yet been deployed to production.
The problem
A report is not a memory
Most tools rescan and hand you a fresh list. Yesterday's triage is gone, the risk your team accepted in writing is back at the top of the queue, and the only way to tell a regression from a re-run is to remember. So the list gets ignored, and the one finding that mattered is ignored with it.
Without a lifecycle
The same 300 findings, every night, in a different order.
Without an audit trail
"We accepted this last quarter" — with nothing to show who, when, or why.
With TRUSTIVAN
One finding, one identity, one history — and a verdict a pipeline can act on.
Finding lifecycle
Five states, and rules that mean something
The lifecycle is a single state machine with an exhaustively tested transition table. Three of its rules are opinions the product is willing to defend.
open
A scan observed it. Nobody has looked yet.
triaged
Someone has read it and accepted it into the backlog.
suppressed
Risk accepted, with a mandatory reason, an owner, and an expiry of at most two years.
resolved
A scan that would have found it did not. Only evidence closes a finding — no button does.
reopened
It was fixed and came back. That fact is permanent; it cannot be relabelled as merely open.
Every transition is written to an append-only timeline that records whether a person, a scan, a scheduled job or an API key caused it. No audit row ever claims a human did something a pipeline did.Read the lifecycle reference.
Policy and verdicts
One question, one answer, in the body
A pipeline does not want a list. It wants to know whether it may ship. TRUSTIVAN answers with a recorded verdict — pass, warn or fail — that explains itself rule by rule.
- Rules, not code. Conditions on severity, status, fixability, advisory identifier, age and match count. There is no expression language to review and no customer code to run.
- Versions are immutable. Enforced by a database trigger, so the policy a historical verdict was graded against can always be produced.
- Suppressing does not buy a green build.By default an accepted risk still appears in every verdict as a warning. You choose whether it stays visible, is ignored, or blocks.
- A build cannot grade its own homework.Policy management is not a scope an API key can hold.
{
"result": "fail",
"policy_version": 3,
"summary": {
"evaluated": 128,
"matched": 2,
"truncated": false
},
"explanation": [
{
"rule": "block-critical-fixable",
"effect": "fail",
"fired": true,
"matched": 2
},
{
"rule": "warn-accepted-risk",
"effect": "warn",
"fired": false,
"matched": 0
}
]
}The verdict is in the response body, never in the HTTP status. A pipeline must be able to tell "the build should stop" from"TRUSTIVAN is unreachable" — those call for opposite reactions, and a non-2xx status conflates them.
Machine API
Built to be driven by a pipeline
Everything a person can do in the dashboard is available to a scoped credential, subject to what that credential was granted — and to a few things it deliberately cannot be.
Scoped keys that expire
The secret is shown once. Expiry is mandatory — 90 days by default, 365 at most. There is no "never expires", because that is a credential nobody rotates.
Pagination that states its guarantee
Signed cursors bound to a tenant, an order and a filter set. Enumerating by recency is exhaustive, and every response reports whether the traversal was stable so a client can assert it.
Idempotent by key
Keys are reserved before any work, so two concurrent retries cannot both execute. A completed request replays its stored response verbatim.
Signed, retried webhooks
Scan completion, verdicts and finding state changes, published from inside the transaction that caused them, HMAC-signed, and retried for about a day.
Why the answer is trustworthy
The properties underneath
A security tool is only worth the confidence you can place in its output. These are the design decisions that confidence rests on.
Findings keep their identity
A finding's identity is derived from its content, not its position in a report. Severity, line numbers and installed version are deliberately excluded — so a rescan, a re-rating, or a change of detection engine does not orphan the decision you already made.
Verdicts are recorded, never recomputed
Policy evaluation is a pure function of the policy, the findings and the time. Historical verdicts replay identically, and the explanation is ordered deterministically, so a diff between two verdicts shows a policy change and never a coincidence of iteration order.
A stale database fails the scan
If the vulnerability database is too old to be trusted, the scan fails rather than returning a clean result. Silence from an out-of-date scanner looks exactly like good news, which is the most dangerous output a security tool can produce.
Tenant isolation the compiler enforces
Every tenant-scoped query requires a scope value that can only be constructed after a membership check. A handler that forgets to authorise does not compile — and CI fails the build if that structure is removed.
Scan an image. Keep the decision.
Start with a public image and a policy that blocks nothing. The quickstart takes about ten minutes and ends with a verdict your pipeline can branch on.