Security in CI/CD. Block the PR, not the team.
Run the same detection in your pipeline that the platform runs continuously — with a gate that breaks the build only on new issues over your threshold, and results that land natively in GitHub's Security tab.
SARIF-native · new-issues-only gate · import existing scanners · runs read-only
Three lines in your workflow file.
Scan, gate, publish. Each step is one command — and the gate is the only thing that can fail your build.
Scan in the pipeline
One command runs the same best-in-class OSS detection floor your platform uses — in your runner, on the branch, before it merges. No agent, no infra to host.
The gate decides
A policy thresholds the findings and exits non-zero only when the build should break. Annotations post inline on the PR so the diff shows exactly what failed.
Results land in GitHub Security
Export native SARIF and every finding shows up in the repo's Security tab and as PR code-scanning alerts — dedup, history, and dismissal handled by GitHub.
# 1. Scan the branch (any asset: repo, image, web, api…) tsengine scan --target . --out scan.json # 2. Fail the build only on NEW high+ issues vs. the baseline tsengine gate --in scan.json \ --fail-on high --new-only --baseline .tsengine/baseline.json \ --format github # → inline PR annotations, exit 1 on fail # 3. Publish to GitHub's Security tab tsengine export --in scan.json --format sarif --out results.sarif # …then: github/codeql-action/upload-sarif@v3
Every flag above is real. Run tsengine gate --help for the full policy surface.
A gate developers don't route around.
A pipeline check only works if it's right more than it's annoying. The policy is built so a clean change passes — and only a real regression stops the merge.
Fails on new issues, not your backlog
--new-only diffs against a saved baseline of fingerprints, so a clean PR passes even on a repo with pre-existing debt. The gate blocks what this change introduced — nothing else.
Threshold on real risk, not raw count
Break the build on a severity floor (--fail-on high), or only on actively-verified findings (--fail-on-verified) or reachable SCA vulnerabilities (--fail-on-reachable). Noise doesn't stop a merge.
Native SARIF — first-class in GitHub
export --format sarif emits SARIF 2.1.0. Upload it with the standard code-scanning action and findings become PR annotations and Security-tab alerts, with GitHub's own triage on top.
Bring the scanners you already run
import ingests SARIF, Snyk, or Dependabot output from your existing tools — so they get the same grounding, reachability, and gate treatment without ripping anything out.
Budget the regression
--max-new caps how many new findings a PR may add before the gate trips — a pragmatic middle ground while a team pays down a backlog, instead of all-or-nothing.
Or stream to your own system
export --webhook POSTs the normalized findings event to any endpoint, HMAC-signed, so a homegrown dashboard or SIEM gets the same data the platform does.
The same engine, two places it runs.
The platform watches your assets continuously and runs the autonomous agent on top. The CLI puts that same best-in-class OSS detection in your pipeline, so a vulnerability is caught at the pull request — not in next month's scan. One contract, one set of findings, two entry points.
Runs read-only
The pipeline command reads your code and dependencies. It never writes back — no tokens with push access, no surprise commits.
Branch-aware baseline
Save a baseline on main; diff every PR against it. Existing debt stays visible on the platform without blocking unrelated changes.
Grounded findings only
Every gate decision traces to a tool that fired. No model invents a reason to fail your build.
Catch it at the pull request.
Add the gate to one workflow file and ship with security in the loop — without slowing the team down.