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

Automated checks in continuous integration catch problems before they ship. Learn what static and dynamic testing find, why leaked secrets are so dangerous, when to fail a build, and how to protect the pipeline itself.

Ta strona jest na razie po angielsku.

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

Check	What it looks at	Good at finding	Limits
SAST (static analysis)	Source code, without running it	Unsafe patterns such as injection risks and insecure functions	False positives; cannot see runtime configuration
Dependency scanning (SCA)	Third-party libraries and their versions	Components with publicly known vulnerabilities	Only knows about vulnerabilities already published
Secrets scanning	Code, configuration and history	API keys, passwords and tokens committed by mistake	Unusual secret formats can slip through
DAST (dynamic analysis)	A running test instance, from the outside	Issues in real behaviour: headers, sessions, input handling	Needs a deployed test environment; slower

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.

Najważniejsze

SAST reads code, SCA checks dependencies, secrets scanning finds credentials and DAST tests the running app.
A leaked secret is immediately usable: revoke and rotate it, do not just delete the line.
Break the build only on high-confidence, high-impact findings, with a recorded exception process.
The pipeline is a target: apply least privilege, protected branches and pinned dependencies.

Sprawdź się

1. Which check analyses source code without running it?
- DAST
- SAST — Dobrze.
- Penetration testing
- Load testing
Static application security testing reads the code itself; dynamic testing exercises a running instance.
2. A developer accidentally committed a cloud access key. What is the first priority?
- Delete the line and push again
- Revoke and rotate the key — Dobrze.
- Rename the repository
- Wait to see if anyone uses it
The key stays in history and may already be copied. Revoking it makes the leaked value useless.
3. What is a sensible policy for breaking the build?
- Block on every warning from every tool
- Never block, only report
- Block on high-confidence, high-impact findings and report the rest — Dobrze.
- Let each developer decide
Blocking on everything leads teams to disable checks; blocking on nothing means findings are ignored.

Wypróbuj to z FireAI

Zastosuj tę lekcję w praktyce na swoim Macu.

Źródła

Zastosuj to na swoim Macu

Wypróbuj wszystkie funkcje za darmo przez 17 dni, bez karty.

Pobierz na Maca Dokumentacja