Shift left: security becomes a quality gate

APIs change with every deploy. An endpoint tested in January can have a new parameter, a new HTTP method, or a new role in February - and thus a new gap. A finding from twelve months ago says nothing about what's shipped today. OWASP puts this unambiguously in the chapter What's Next For DevSecOps: Scanning and penetration testing yearly are no longer enough. Instead, OWASP calls for continuous security testing across the entire software development life cycle, as well as security automation in the pipeline, without slowing down development velocity.

Shift-left means running security tests as early as possible and on every change, not just shortly before or after the production release. The decisive lever is the quality gate: a failed security test aborts the build, a vulnerable state never reaches production in the first place. OWASP lays down exactly this logic as a prevention measure for BOLA (API1:2023): Write tests to evaluate the vulnerability of the authorization mechanism. Do not deploy changes that make the tests fail. The test is therefore not reporting, it is a condition for shipping.

It's important to draw the line against pentesting: an annual penetration test and an external audit remain worthwhile, but they don't replace continuous testing. They are point-in-time samples, whereas the pipeline checks every commit. The two complement each other; neither subsumes the other.

MethodWhat it checksPipeline phaseRisk addressed
SASTSource code statically, without executionBuild / pull requestInjection, hardcoded secrets
DASTRunning API from the outsideTest (deployed instance)Misconfiguration, runtime behavior
SCAThird-party dependencies, SBOMBuildUnsafe Consumption, supply chain
Authorization contract testsAccess rules per role/objectTestBOLA (API1), BFLA (API5)
OpenAPI spec diffingChanges against the approved specBuild / gateImproper Inventory (API9), Misconfiguration (API8)
Secret scanningSecrets in code and historyPre-commit / CISecrets leakage

Security checks in the CI/CD pipeline

The test types: SAST, DAST, SCA, IAST

The OWASP DevSecOps Guideline assigns the automated checks to the pipeline phase Vulnerability Scanning and distinguishes several complementary methods. Each covers a different type of flaw; none is sufficient on its own.

  • SAST (Static Application Security Testing): analysis of the source code without execution, typically on every pull request. Finds insecure patterns, hardcoded secrets, and injection paths early. OWASP names tools such as Semgrep and Checkmarx; for infrastructure as code, scanners such as Checkov and tfsec are added.
  • DAST (Dynamic Application Security Testing): tests the running, deployed API from the outside, i.e. against real responses rather than against code. Suited to finding misconfigurations and runtime behavior that aren't visible statically.
  • SCA (Software Composition Analysis): examines third-party and open-source dependencies for known vulnerabilities and license risks. Relevant to API10:2023 Unsafe Consumption of APIs and the supply chain as a whole; an SBOM makes the inventory traceable.
  • IAST (Interactive Application Security Testing): instruments the application during functional tests and observes data flows at runtime, as a bridge between the static and dynamic views.

For APIs, a specific limit applies: generic SAST and DAST scanners recognize patterns and known signatures, but not authorization and logic flaws. Whether user A is allowed to see user B's object follows from identity, role, and object ownership, not from the shape of the request. These cases need their own, context-aware tests.

Authorization contract tests and OpenAPI spec diffing

The most common and most severe API risks are authorization errors: BOLA (API1:2023) and BFLA (API5:2023). Both consist of syntactically flawless requests; a signature or pattern detector sees nothing here. The right test has to be actively formulated: can user A access someone else's object? Can a regular user trigger an administrative function, for instance by switching the method from GET to DELETE?

OWASP describes a concrete approach in the Authorization Testing Automation Cheat Sheet: you maintain an authorization matrix along the dimensions of feature, logical role, and optionally data filtering, and derive integration tests from it that run on every new release. This immediately surfaces when a changed or newly added function violates the defined permissions. The background: most authorization problems only arise once features are added or changed in later releases without checking their effect on permissions. These tests are authorization contract tests: they fix the expected access decision as a contract and fire as soon as the code breaks it.

In parallel, OpenAPI spec diffing in the build secures the declared inventory. Every change is checked against the approved specification; new, unreviewed routes or incompatible changes break the build before they ship. This addresses API9:2023 Improper Inventory Management and API8:2023 Security Misconfiguration directly in the development process. The limit matters here: spec diffing checks the known, declared state. Endpoints that were never in a spec, ticket, or review (shadow or zombie APIs) slip through pure pipeline checks and additionally need runtime discovery.

Secret scanning in CI

Secrets such as API keys, tokens, and passwords regularly end up in repositories, CI configurations, Docker images, and compiled artifacts. Once in the Git history, a secret remains retrievable even after being deleted from the current state; it must be considered compromised and rotated.

The OWASP CI/CD Security Cheat Sheet names two lines of defense. First, secrets must never be hardcoded in code repositories or CI/CD configuration files. Second, tools such as gitleaks or git-secrets should detect such secrets. The goal according to OWASP: prevent a secret from ever being committed in the first place, and monitor continuously to catch deviations. In practice, that means:

  • Pre-commit hook: blocks secrets before they enter the history.
  • CI gate: a scan on every push and pull request that aborts the build on a hit (quality gate).
  • History scan: periodic review of the entire Git history, not just the current diff.

Secrets belong in a dedicated secrets manager, not in build variables in plaintext; OWASP also requires encryption to recognized standards. For more depth on leak vectors and countermeasures, see the page on API Secrets & Key Leakage.

NIST SP 800-204D: anchoring security in the CI/CD phases

Where security measures concretely belong in a pipeline is described by the NIST publication SP 800-204D (Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines, 2024). It assumes cloud-native microservice architectures and treats the pipeline as a sequence of the phases Build, Test, Package, and Deploy, through which the source code runs as part of the software supply chain.

The core idea: security controls are not applied downstream, but integrated phase by phase into exactly these steps. This covers securing the supply chain, i.e. the provenance and integrity of dependencies and build artifacts, as well as anchoring checks along integration and delivery. For an API pipeline, that maps as follows:

  • Build: SAST and secret scanning on the source code, SCA and SBOM generation for dependencies.
  • Test: authorization contract tests (BOLA/BFLA), DAST against the running instance, OpenAPI spec diffing as a gate.
  • Package: signing and integrity checking of artifacts, no secrets in the image.
  • Deploy: release only of compliant builds, handover of the inventory to runtime enforcement.

SP 800-204D thus provides the framework that connects the individual methods (SAST, DAST, SCA, spec diffing, secret scanning) into one continuous, automated chain, rather than a set of loose individual measures.

Reproducible findings in developers' own tools

A security finding is only effective once it gets fixed. OWASP states explicitly in the DevSecOps chapter that findings should be delivered promptly and within the tools development teams are using (not PDF files), that the team should be supported through remediation, and that every finding should be made tangible with a concrete attack scenario, to make it real.

For API logic flaws, this means: a finding needs the exact request, the manipulated ID or changed method, and the observed response. Only then is it reproducible and can be adopted into the suite as a permanent regression test, so the same gap doesn't ship again. A PDF report without an executable proof, by contrast, creates friction and goes stale with the next deploy.

In practice, reproducible in developers' tools means: a finding as an annotated pull-request comment or pipeline output instead of an external document, with severity, the affected endpoint, and an executable reproduction step. This closes the shift-left loop: the test becomes the quality gate, the finding becomes the test, and the next build checks exactly this condition again. How these three steps (knowing the inventory, continuously testing the right things, enforcing at the gateway) come together into an overall picture is described on the page Implementing API Security.

Sources

Keep reading
ImplementationImplementing API Security RiskBOLA (API1) RiskAPI Secrets & Key Leakage