Securing the CI/CD pipeline: SAST, DAST, secrets and breaking the build

Continuous integration and continuous delivery (CI/CD) is the automated assembly line of modern software. Every change a developer pushes is built, tested and often deployed without a person touching it. That automation is also the ideal place for security checks: they run every time, for every change, the same way. It also makes the pipeline itself a target, because whoever controls it controls what gets shipped.

The main automated checks

OWASP keeps a list of source code analysis tools, and projects such as OWASP Dependency-Check and the ZAP dynamic scanner are widely used open-source options. Code hosting platforms also provide built-in secret scanning; GitHub’s version can block a push that contains a recognised secret before it ever reaches the repository.

Why leaked secrets deserve special attention

A vulnerability usually needs work to exploit. A leaked cloud key or access token does not: anyone who finds it can simply use it. Secrets committed to a repository also stay in its history even after the line is deleted, and repositories get copied, forked and made public by mistake. The OWASP Secrets Management Cheat Sheet recommends keeping secrets out of code entirely, in a dedicated secrets manager, with short lifetimes and automatic rotation.

• Scan before the commit (a pre-commit hook) and again on the server, in case the hook was skipped.
• If a secret leaks, revoke and rotate it first. Deleting the commit is not enough.
• Prefer short-lived credentials issued to the pipeline at run time over long-lived keys stored in settings.

Breaking the build, deliberately

A check only matters if its result changes what happens. “Breaking the build” means the pipeline stops and the change cannot be merged or deployed until the problem is fixed. The skill is choosing what should block. A useful rule is to block on findings that are high-confidence and high-impact, such as a verified secret or a critical known-vulnerable dependency with an available fix, and report everything else as a warning to review. Blocking on everything leads teams to disable the check.

Protecting the pipeline itself

The pipeline has access to source code, secrets and production. The OWASP CI/CD Security Cheat Sheet lists the main protections:

• Least privilege for pipeline jobs: each job gets only the permissions and secrets it needs.
• Protected branches and mandatory review, so nobody can push straight to what gets deployed.
• Pin third-party build actions and plugins to exact, reviewed versions.
• Isolate build runners, and do not run untrusted pull request code with access to secrets.
• Log pipeline changes and runs, and review who changed the pipeline definition.

Where FireAI fits

Pipelines usually run in the cloud, beyond FireAI’s reach. On the developer’s Mac, though, FireAI lets you see and control which apps and tools connect to code hosts, package registries and cloud services, and its rules can be exported to a file to back them up or reuse them on another Mac.