Skip to main content

API Security in CI/CD

Gate the security-relevant API change, not just the syntax.

CI already knows when an OpenAPI file changed. A stronger gate asks whether that change added capability, relaxed documented authorization, introduced new sensitive data, or reduced the quality of the security evidence.

01Baseline → candidate

Compare the approved contract with the proposed one.

Treat the main-branch contract as the baseline and the pull-request contract as the candidate so the pipeline can show what changed.

BASELINE openapi-main.yaml
CANDIDATE openapi-pr.yaml
POLICY REVIEW
02Useful gate signals

Focus the review on material expansion or regression.

New capability

A newly documented operation gives an application or agent another action it may be able to request.

Authorization relaxation

A sensitive operation moves toward optional authentication, broader permissions, or weaker declared controls.

New sensitive surface

A request or response begins exposing data or inputs that deserve additional runtime controls.

03Fail closed

Incomplete comparison should not become an automatic PASS.

Unresolved references, invalid structures, unsupported surfaces, or other diagnostics can make part of the comparison non-evaluable. Preserve uncertainty and route it to review.

Boundary

PASS, FAIL, REVIEW, NOT_EVALUATED and coverage communicate different facts; missing evidence is not safety.

04Agent integrations

Capability drift is an agent-security change.

A pull request that adds POST /refunds or relaxes authorization can expand an agent’s potential blast radius even when the OpenAPI remains syntactically valid.

Boundary

A contract gate can block or review declared changes. It does not prove production IAM, network policy, or agent runtime behavior.