Platform
One question a pipeline actually asks
Not “what did you find”, but “may this ship”. TRUSTIVAN answers with a recorded verdict — pass, warn or fail — and the reasoning behind it.
The rule language
Deliberately not a language
There is no expression evaluator, no embedded interpreter, and no customer-supplied code. A rule is a set of conditions that must all hold.
Conditions cover severity, finding kind, lifecycle status, fixability, advisory identifier, age, and how many findings must match before the rule fires. A rule carries one effect: fail, warn or ignore.
A rule with no conditions is rejected when you write it — it would match every finding, which is never what anyone meant. A policy with no rules is rejected for the same reason.
{
"name": "block-critical-fixable",
"effect": "fail",
"conditions": {
"min_severity": "critical",
"fixabilities": ["fixable"],
"statuses": ["open", "reopened"],
"min_count": 1
}
}Why you can trust the answer
Deterministic, and replayable
A pure function
Evaluation takes the policy, the findings and the time. The clock is an input rather than something read from the environment, so age-based rules are testable and a historical evaluation reproduces its historical answer.
Stable explanations
Findings are put in a total order before evaluation, so the explanation is stable too. A diff between two verdicts shows a policy change and never an accident of iteration order.
Immutable versions
A policy version cannot be edited after it exists — enforced by the database, not by convention. The policy a historical verdict was graded against can always be produced.
Accepted risk
Suppressing does not buy a green build
By default, an accepted risk still appears in every verdict as a warning.
That default is a product opinion. A suppression is a decision to carry a risk, not a decision to stop knowing about it — and a build that goes green the moment someone clicks “accept” trains a team to click.
You can change it per policy: keep accepted risk visible as a warning, ignore it entirely, or have it block like anything else.
warn default
Visible in every verdict. Does not block.
ignore
Treated as absent for this policy's purposes.
enforce
Accepted risk blocks exactly as an open finding would.
For pipelines
The result is in the body, never the status
A build that stops because a policy failed and a build that stops because TRUSTIVAN was unreachable call for opposite reactions. An HTTP status that conflated them would make that impossible to tell apart.
Requesting a verdict succeeds — with a 2xx — and the verdict itself says pass, warn or fail. A non-2xx response means TRUSTIVAN could not answer, which is an infrastructure problem, not a security one.
Verdicts are append-only and never recomputed. Requesting one again replays the recorded decision rather than re-running it, so two stages of the same pipeline cannot disagree.