Why TRUSTIVAN
A security vendor you can check
Most security marketing asks you to take capability on trust, which is a strange request from a category whose entire value is not taking things on trust. This page is the argument, with the parts we cannot substantiate left out.
The premise
The scan is not the product
Vulnerability data is public. Matching it against a package list is well understood, and several open-source engines do it competently. If that were the product, it would already be free — and it is.
The expensive part of vulnerability management was never generating the list. It is the afternoon somebody spends reading advisories, judging exposure, and being willing to sign their name to “we are accepting this one”. That work is what a nightly rescan throws away, because a fresh report has no way to know it happened.
TRUSTIVAN is built around keeping it. A finding has an identity that survives rescans and re-ratings, a state with rules about who may change it, and a timeline recording what caused every change. The scan is an input to that record, not the output of the product. For the specific engine and the specific difference, seeTRUSTIVAN vs. running Trivy yourself.
Straight answers
The questions an evaluator asks first
- Who wrote the detection?
- We did not. Vulnerability matching is done by Trivy, an established open-source engine, under Apache 2.0. It is good, it is public, and claiming it as our own moat would be a lie a reader could check in an afternoon.
- So what did you build?
- Everything that happens to a finding after it is found: identity that survives a rescan, a lifecycle with rules, an audit timeline, a deterministic policy engine, recorded verdicts, and an API a pipeline can be built on.
- What does it not do?
- No infrastructure-as-code scanning — nothing here parses a Terraform or Kubernetes manifest, though connecting a cluster or a cloud account to inventory what runs there is a different thing and does ship. No reachability analysis — known-exploited status is enriched, but not whether the vulnerable code is called. No pull-request scanning. No mail delivery: you can invite a colleague, but sending them the token is yours to do. No attestation of our own — evidence maps to controls, but we hold no SOC 2 report or ISO certificate. And no published price: checkout, the billing portal and signature-verified subscription webhooks all ship behind BILLING_PROVIDER=stripe, but no price has been set up for this service, so a plan is still arranged by conversation. All of that is listed on the platform page rather than discovered in week three.
What is actually different
Four decisions a competitor would have to undo
Not features — commitments that shape what the product can and cannot become.
Evidence closes a finding, not a button
Nobody can mark a finding resolved by hand. Resolution means a scan that would have found it did not. The alternative — a “mark as fixed” control — lets a person assert evidence they do not have, and produces a backlog that is clean because it is wrong.
Accepted risk stays visible
Suppression needs a written reason and an owner, expires within two years, and by default still shows up in every policy verdict as a warning. A tool where clicking “accept” turns the build green teaches people to click.
A build cannot grade itself
Policy management is not a permission any machine credential can hold, and accepting risk is separated from ordinary triage. A CI runner that can queue scans cannot silence its own failures.
Silence is treated as suspicious
If the vulnerability database is too old to trust, the scan fails rather than reporting nothing found. A stale scanner's silence is indistinguishable from good news, and that is the failure most likely to go unnoticed for months.
Fit
When TRUSTIVAN is the wrong choice
Stated because a bad fit discovered during a pilot costs both of us more than a paragraph here.
- You need infrastructure-as-code or cloud-posture scanning. TRUSTIVAN scans container images, repositories and ingested SBOMs, and it inventories what runs in a connected cloud account or Kubernetes cluster — but no shipped engine parses a Terraform or Kubernetes manifest for a policy violation.
- You want a tool that tells you that you are compliant. TRUSTIVAN maps evidence to controls in five frameworks and exports a hash-chained audit package, but it never reports a control as “compliant” or “pass” — that conclusion is your auditor’s, and a badge from a scanner is not one.
- You need to know whether a vulnerability is reachable from your own code. Known-exploited enrichment ships; reachability analysis does not.