Security teams should automate scanning inside the pipeline itself, triggered by code changes such as pushes and merge requests. A practical setup combines SAST, SCA, and IaC checks with policy enforcement, so developers get feedback where they work. The goal is to reduce context switching, catch issues early, and make secure delivery the default rather than a separate review step.
Why This Matters for Security Teams
Embedding application security into GitLab pipelines is less about adding more checks and more about shifting security left without turning delivery into a bottleneck. When scans run on pushes and merge requests, teams can catch vulnerable code, exposed secrets, and misconfigured infrastructure before review becomes expensive. NIST’s Cybersecurity Framework 2.0 reinforces this by tying risk management to repeatable, operational controls rather than one-off gatekeeping.
This matters because pipeline security failures usually surface where developers move fastest. NHIMG research on CI/CD pipeline exploitation case study shows how attackers abuse build and release trust to reach code, secrets, and deployment paths. The issue is not just detection quality. It is whether findings appear early enough, in enough context, for developers to act before a merge is blocked or a release is already staged. In practice, many security teams encounter pipeline abuse only after a secret has been leaked or a malicious dependency has already been promoted.
How It Works in Practice
A practical GitLab setup embeds security jobs directly into the pipeline stages that developers already use. Typical controls include SAST for code flaws, SCA for dependency risk, IaC scanning for cloud and infrastructure misconfigurations, and secret detection for exposed credentials. The goal is not to scan everything at every moment. It is to run the right checks on the right trigger, usually merge requests, branch updates, and scheduled rescans for long-lived code.
GitLab pipelines work best when security output is actionable. That means:
- Failing builds only for agreed severity thresholds, not every finding.
- Posting results into merge requests so developers do not have to leave the workflow.
- Using policy-as-code to enforce baseline requirements consistently.
- Pairing scanners with suppression rules, ownership, and expiration so exceptions do not become permanent.
For secret detection, the operational lesson is especially clear. NHIMG’s Guide to the Secret Sprawl Challenge and Reviewdog GitHub Action supply chain attack both illustrate how quickly hidden credentials can spread when pipelines are not enforcing consistent checks. Current guidance suggests that teams should treat secrets scanning as a release safeguard, not an occasional audit. NIST CSF 2.0 also aligns with this model by emphasizing continuous protection and response rather than end-of-cycle review. These controls tend to break down in monorepos with many exception paths because scan noise, duplicated jobs, and unclear ownership cause developers to bypass the very gates meant to protect delivery.
Common Variations and Edge Cases
Tighter pipeline controls often increase build time and alert volume, requiring organisations to balance developer throughput against enforcement strength. That tradeoff is especially visible when teams try to apply the same policy to every repository, language, and deployment path.
Best practice is evolving in a few areas. For regulated workloads, security teams often separate advisory findings from blocking findings so that only critical issues stop delivery, while lower-severity items create tickets. In highly regulated environments, that approach reduces friction without weakening governance. In contrast, shared templates and centralised GitLab runners can help standardise controls, but only if teams keep scanner versions, rule sets, and exception handling aligned.
Another edge case is third-party and generated code. Dependency updates, vendor imports, and AI-assisted code generation can all introduce risk faster than manual review can catch it. The secure pattern is to combine automated scanning with ownership rules and periodic rescans, especially where secrets, build tokens, or deployment credentials may already exist outside the repository. When a pipeline spans multiple groups, external contributors, or brittle release branches, security controls tend to break down because policy enforcement becomes inconsistent across the path to production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret scanning and rotation in pipelines reduce exposed NHI credential risk. |
| OWASP Agentic AI Top 10 | A1 | Pipeline automation for AI-assisted code needs guardrails against unsafe tool use. |
| CSA MAESTRO | M2 | Pipeline controls map to secure delivery and continuous assurance for agentic workloads. |
| NIST AI RMF | GOVERN | Pipeline security is a governance control for automated software creation and release. |
| NIST CSF 2.0 | PR.IP-1 | Secure pipeline checks support repeatable protective processes in delivery workflows. |
Standardize CI security jobs so protection is built into delivery, not added afterward.
Related resources from NHI Mgmt Group
- How should security teams add application security testing into Azure DevOps CI/CD pipelines without slowing delivery?
- How should security teams add application security testing into a CircleCI pipeline without slowing delivery down?
- How should security teams implement application vulnerability management across the SDLC without slowing delivery?
- How should security teams secure FastAPI applications in CI/CD pipelines without slowing delivery?
