# API Security in CI/CD — Routebase > Where a scan belongs in a pipeline, how to set a gate that is still switched on in month three, and why findings belong in the code host rather than in a second tool. Canonical page: https://routebase.dev/guides/api-security/api-security-in-ci-cd/ Chapter 10 of 12 · API Security · Last reviewed 2026-09-13 · The Routebase Team A scan that runs when somebody remembers is a scan that runs after the incident. This chapter is about the version that runs on its own. ## The shape of the job Whatever tool you use, the pipeline step has the same four parts. It queues a scan against a deployed environment, since there has to be something running to probe. It waits, with a timeout that accounts for the scan's own time budget plus queueing. It reads the results and decides whether to fail. And it hands the results to something a reviewer will actually look at. The fourth part is the one that gets dropped, and dropping it is what turns a security gate into an obstacle. A build that fails without showing what failed teaches people to re-run it. ## Set the gate where it will survive The instinct is to fail on anything. The outcome of that instinct is a permanently red build, and then a pipeline configuration change that quietly removes the step. Start by failing on critical findings only. That gate is achievable, so it stays on, and a critical finding genuinely should stop a release. Once the existing backlog has been triaged and the critical count is a real zero, tighten to high. Tightening is a one-line change and rebuilding trust in a build everyone ignores is not. Two properties make a gate trustworthy. It should reflect your current triage state rather than one scan in isolation, so something you accepted last week does not come back as a blocker. And it should be deterministic, meaning the same posture produces the same verdict rather than depending on which scanner happened to finish inside the budget. ## Put the findings where the code is Security findings that live in a separate dashboard get read by the person who owns the dashboard. The format that moves them is SARIF, which code hosts read natively and render next to the code. Two details decide whether that integration is pleasant. Severity has to be expressed in the way the host expects, because most hosts bucket on their own numeric property rather than on a severity string. And every result needs a stable fingerprint, since without one the host treats every run as a fresh set of findings and the noise makes the feature useless. Upload the results even when the gate fails. A failed build with the findings attached is a conversation, and a failed build with a non-zero exit code is a mystery. ## Two cadences The pull request pass and the scheduled pass are different jobs with different constraints, and trying to make one configuration serve both produces something too slow for review and too shallow for the weekend. The pull request pass runs against a preview or staging deployment with the passive checks and a short budget, and its purpose is catching a regression while the change is still open. The scheduled pass runs nightly or weekly against staging with everything enabled, including the authorization scanners and, where the environment is yours to stress, the fuzzers. There is a third option worth knowing about. A scan on a clock does not need a pipeline at all, and a scheduled scan inside the security tool covers the recurring pass without a runner. Use the pipeline when you want the scan tied to a change and the schedule when you want it tied to a clock. ## In Routebase The whole scan lifecycle is available over the REST API, so the pipeline step is three calls. One `POST` queues a run from an existing profile and returns immediately with the run id, because the scan is a background job. A `GET` on the run polls until the status reaches completed, failed or cancelled. The same response carries the score, the open findings count and the scanner progress, so a pipeline can print something useful while it waits. A final `GET` reads the findings, either as JSON for the gate or as SARIF for upload. _Screenshot: A pipeline key needs Full Access, because queueing a run needs execute permission on security while reading runs and findings needs read access to the project._ The SARIF export is version 2.1.0 and is shaped for code scanning specifically. Findings are grouped into rules by guidance id, so there is one rule per issue class carrying the remediation text. Severity is expressed twice. The SARIF `level` is `error` for critical and high, `warning` for medium, `note` for low and `none` for info, and alongside it the numeric `security-severity` property carries the value hosts bucket on. The endpoint path is the result location, so findings land on the route rather than all on line one, and every result carries a `partialFingerprints` entry so the same finding is recognised across runs. Both result calls are project-wide and reflect current triage state, so a finding marked accepted risk does not come back as open and trip the gate. There is no server-side pass or fail verdict, which is deliberate, because the threshold is yours. The [Routebase CLI](https://docs.routebase.dev/cli-overview/) collapses queue, poll, gate and export into one command with a `--fail-on` flag if installing a tool on the runner is acceptable. A profile can also carry its own cron schedule with notifications on critical and optionally high findings, which covers the recurring pass without any pipeline at all. See [Security in CI/CD](https://docs.routebase.dev/security-in-cicd/) for the complete job, and [API Keys](https://docs.routebase.dev/api-keys/) for the key. ## Frequently asked questions ### How do you add API security testing to a CI/CD pipeline? Queue a scan against a deployed environment, wait for it to finish, then read the findings and decide whether to fail the build. Export the results in a format your code host understands so reviewers can see what broke the build rather than only that something did. Keep the pull request pass small and put the thorough pass on a schedule. ### What severity should fail a build? Start at critical only, then tighten once the existing backlog is triaged. A gate that is red on day one is a gate somebody disables by day three, and a disabled gate finds nothing at all. Tightening later is an easy change, while restoring trust in a permanently red build is not. ### What is SARIF and why does it matter for security scanning? SARIF is a standard JSON format for static analysis results that code hosts read natively, so findings appear next to the code instead of in a separate dashboard. It also carries a fingerprint per result, which is what lets a host recognise the same finding across runs rather than reporting it as new every time. ### Should a security scan run on every pull request? A small one should, because an authorization regression is cheapest to fix while the change is still in review. The full profile, including the authorization scanners and anything that generates load, belongs on a nightly or weekly schedule against an environment you own. Most teams end up running both. --- [Routebase](https://routebase.dev/) — [Sign up](https://app.routebase.dev/): Every account starts with a 14-day Pro trial — no credit card required.