In what order should you add API security testing to CI/CD?

Add API security testing to CI/CD in this order: inventory your APIs, run secrets and dependency checks on every pull request, add static analysis, then run authenticated dynamic tests against a staging copy. Turn on build-failing gates last, after you have tuned out the noise.

Why does the order matter?

Teams often start with the most powerful scanner and drown. A dynamic scan with thousands of low-value alerts teaches developers to ignore the tool. The order below puts cheap, low-noise checks first and the costly, noisy ones later, so trust builds as you go.

Step 1: What APIs do you have?

You cannot test what you cannot list. OWASP's API Top 10 includes Improper Inventory Management, noting that APIs expose more endpoints than traditional web applications and that a proper inventory of hosts and deployed versions helps prevent problems like deprecated versions and exposed debug endpoints. Start with an OpenAPI description for each service if you have one, and compare it with what actually runs in staging and production. Fix mismatches first. The inventory also tells you which API handles what data, which decides your priorities.

Step 2: Can you stop leaked keys and bad packages at the pull request?

Secrets scanning and dependency checks are quick and produce findings that are easy to act on. A leaked API key is a direct way into your API, and a vulnerable library is a known weakness. Run both on every pull request.

With the Safeguard CLI, safeguard detect looks for secrets and misconfigurations and can write SARIF, which code-scanning views understand. The Safeguard docs are direct about a limit: the CLI reports findings and does not fail a build by itself. Enforcement comes from the platform's policy gates, once the repository is connected as an integration. Pin the CLI version in CI so a release does not change a build under you, and keep results as build artifacts, since they are your evidence of what was scanned.

Step 3: Where does static analysis fit?

Static analysis reads your source and traces untrusted input to dangerous operations. It is useful on API code, for example to spot input that reaches a query. It will not judge whether your authorization rules are right. Safeguard's documentation says its SAST is rolling out, with JavaScript, TypeScript, Python and Java first, so check coverage for your stack. Start in report-only mode and tune before you enforce.

Step 4: How do you run dynamic tests safely?

Dynamic testing sends requests to a running API and watches the responses. Use a staging environment with test data, never production data. Give the scanner credentials for at least two test users with different roles, so it can try one user's token against another user's objects. That is the check for the top OWASP risk, Broken Object Level Authorization.

Safety controls matter. Safeguard's DAST documentation describes verified targets only, strict host and path scope, mandatory rate limits, and non-destructive checks by default, with a full audit trail. Whatever tool you use, ask for equivalents, and never point a scanner at systems you do not own.

Try the walkthrough at /demos/dast-web-app-scan.

Step 5: When do you turn on gates?

Only after two or three weeks of reports with a low rate of false alarms. Begin by blocking on the narrowest, most certain class: a verified live secret, or a dependency with a known exploited vulnerability. Widen over time. Provide a documented override path with an owner, so a justified exception does not become a pipeline revolt.

What does this setup not cover?

Business logic flaws, such as abuse of a legitimate workflow, need design review and tests written by people who know the domain. The OWASP list includes Unrestricted Access to Sensitive Business Flows for this reason. Automated tests complement that work and do not replace it.

What to do

1. Create or update an inventory of all APIs and versions, with data sensitivity noted.
2. Add secrets and dependency scanning to every pull request, in report mode.
3. Save scan output as build artifacts.
4. Add static analysis in report-only mode and tune it.
5. Stand up a staging target with test users in at least two roles.
6. Run authenticated dynamic tests nightly, then on release candidates.
7. Enable blocking gates for verified secrets and actively exploited dependencies.
8. Review findings and time to fix every month.

Quick check

Sources

• OWASP API Security Top 10, 2023
• Safeguard docs: CI/CD Integration
• Safeguard docs: Application Security Testing

Last reviewed: 18 October 2026.