The CI gate
Most application security tools tell you what is wrong. The gate is the part that can decide whether a build goes out.
It runs after every ingest, asks a small fixed question of the findings it has just processed, and gives your pipeline an answer it can act on.
What blocks a build
A finding blocks if either condition holds:
- It is listed in the CISA KEV catalogue, meaning it is known to be exploited in the wild.
- Sinterly has verified it as exploitable and it sits on a public-facing target, meaning business-context tier A or B.
Both conditions, and the tier list, are settings you control.
What deliberately does not block
| Not a condition | Why not |
|---|---|
| Severity, or the priority score | A wall of unverified criticals is exactly what the gate exists not to relay. A threshold also produces an argument about the number every time it fires. |
| A scanner's own "exploitable" label | The gate acts on Sinterly's verified verdict, never on a vendor's unevidenced claim. |
| Reachability | Sinterly does not analyse your source, so this cannot be verified for every finding. A gate with a condition it cannot evaluate is a gate nobody trusts. |
| Threat model findings | A design threat is not something a build can fix. |
| Anything under a live risk acceptance | A documented, expiring, signed-off exception is honoured. See Risk decisions. |
Advisory first, always
Every tenant starts in advisory mode. The gate evaluates, records its verdict, and reports what it would have blocked. It never fails a build.
This means you can wire the gate into your pipeline today with nothing at risk. Watch it for a few weeks, see what it would have caught and what it would have annoyed you about, and only then decide.
Switching to blocking is a deliberate change you make. A gate that starts by breaking builds is a gate that gets switched off in a fortnight.
Wiring it in
Create an ingest token (see Ingest API) and give
it to your CI system as SINTERLY_TOKEN. Ingest calls go to the
pipeline host, not the dashboard API:
export SINTERLY_URL=https://pipeline.sinterly.com
export SINTERLY_TOKEN=stk_...
semgrep --config p/owasp-top-ten --sarif -o results.sarif .
./sinterly-ci-gate.sh results.sarif sarifThe helper script uploads the file, waits for the run, and exits with a code your pipeline understands.
| Exit code | Meaning |
|---|---|
| 0 | The gate passed, or the policy is advisory |
| 1 | The gate failed and the policy is blocking |
| 2 | Something went wrong: upload rejected, run failed, or timed out |
Accepted formats are sarif, csv and
otm. The script needs curl, and either
jq or python3.
Doing it without the script
Two calls. Ingestion is asynchronous, so the verdict arrives with the run status rather than with the upload.
curl -X POST "$SINTERLY_URL/ingest/commit?format=sarif" \
-H "Authorization: Bearer $SINTERLY_TOKEN" \
--data-binary @results.sarif
# {"status":"accepted","run_id":"...","tenant_id":"..."}
curl "$SINTERLY_URL/ingest/runs/$RUN_ID" \
-H "Authorization: Bearer $SINTERLY_TOKEN"{
"run": { "status": "completed", "findings_created": 3 },
"gate": {
"status": "fail",
"enforcement": "advisory",
"blocking_count": 1,
"blocking_findings": [
{
"finding_id": "...",
"condition": "kev_listed",
"detail": "Listed in the CISA KEV catalogue, exploited in the wild",
"cve_id": "CVE-2026-1234",
"title": "Deserialisation of untrusted data"
}
],
"policy_version": 1,
"should_fail_build": false
}
}should_fail_build is the only field your pipeline needs
to read. It is false in advisory mode however bad the verdict.
gate is null while the run is still going, and for a tenant with
no policy configured.
Reading a verdict later
Every evaluation is stored permanently and cannot be edited, including a copy of the policy exactly as it stood at the time. A verdict from six months ago still explains itself after the policy has changed.
Suggested rollout
- Week one. Wire the script into one pipeline. Leave the policy advisory. Change nothing else.
- Weeks two and three. Look at what it would have blocked. If anything looks wrong, the usual cause is a target tier that does not match reality.
- Week four. Decide. If the verdicts have been right, switch to blocking on that one pipeline first.
- Afterwards. Watch the override rate on the executive view. A rising override rate means the policy is too broad, or the team is under too much delivery pressure. Both are worth knowing.