GitLab Security: Pipeline Hardening, SAST/DAST, and Container Scanning
Part of the Cybersecurity Skills Guide — This article is one deep-dive in our complete guide series.
By HADESS Team | February 28, 2026 | Updated: February 28, 2026 | 5 min read
GitLab ships with built-in security scanning, container registries, and pipeline controls. Most of it is turned off by default. Configuring these features properly turns your GitLab instance from a code repository into a security enforcement point.
CI Pipeline Security
GitLab CI pipelines run in runners — shared or dedicated. The security of your pipeline depends on how those runners are configured and what your .gitlab-ci.yml allows.
Use protected branches and protected variables. CI/CD variables marked as protected are only available to pipelines running on protected branches. This prevents feature branches (or merge requests from forks) from accessing production credentials.
Restrict runner scope. Shared runners serve multiple projects. If one project is compromised, the runner’s cache and network access are available to the attacker. Dedicate runners to sensitive projects and tag them accordingly.
Lock pipeline configuration. Use include with specific refs to pull pipeline templates from a trusted repository:
“yaml include: - project: 'security-team/pipeline-templates' ref: 'v2.1.0' file: '/templates/secure-build.yml' `
Pin the ref. Do not use main or latest — someone pushing to that repository should not silently change your pipeline behavior.
SAST/DAST Integration
GitLab provides built-in security scanning templates. Include them in your pipeline:
`yaml`
include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/DAST.gitlab-ci.yml
- template: Security/Dependency-Scanning.gitlab-ci.yml
- template: Security/Secret-Detection.gitlab-ci.yml
SAST (Static Application Security Testing) analyzes source code for vulnerabilities without executing it. GitLab supports multiple analyzers (Semgrep, SpotBugs, Gosec, etc.) and selects the right ones based on detected languages.
DAST (Dynamic Application Security Testing) runs against a deployed application. Point it at your review app environment for per-merge-request scanning:
`yaml`
dast:
variables:
DAST_WEBSITE: https://review-$CI_MERGE_REQUEST_IID.example.com
Make findings actionable. Configure vulnerability severity thresholds in your merge request approval rules. Block merges when critical or high vulnerabilities are unresolved. The security dashboard gives you project-level and group-level visibility.
Container Scanning
If you build container images in GitLab CI, scan them before pushing to the registry:
`yaml
include:
- template: Security/Container-Scanning.gitlab-ci.yml
container_scanning: variables: CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA “
This runs Trivy (or Grype, depending on configuration) against your built image and reports vulnerabilities in the merge request. Pair this with GitLab’s container registry cleanup policies to remove old, unpatched images automatically.
Merge Request Approvals
Merge approvals are your last line of defense before code reaches protected branches:
- Require security team approval when security scans find issues
- Set minimum approvals — one reviewer is rarely enough for production changes
- Prevent approval by the author — self-approving defeats the purpose
- Enable “Remove all approvals when new commits are pushed” to prevent post-approval modifications
- Use CODEOWNERS to enforce review by specific teams for sensitive paths (infrastructure configs, CI definitions, security modules)
Compliance Pipelines
GitLab Premium and Ultimate support compliance frameworks and compliance pipelines. These run security checks that project maintainers cannot skip or modify — the compliance pipeline configuration lives outside the project and is enforced at the group level. This is how you ensure security scanning runs even in projects that would rather skip it.
Related Career Paths
GitLab security expertise is directly applicable to DevSecOps roles. Review your current skill level on the skills page and see how GitLab pipeline security fits into the broader DevSecOps competency map.
Next Steps
- Run a self-assessment on your CI/CD and GitLab security skills
- Plan your certifications for DevSecOps and application security
- Talk to the career coach about building GitLab-specific security experience
- Search for DevSecOps positions that list GitLab as a requirement
- Compare salary data for roles requiring GitLab security expertise
Related Guides in This Series
- Ansible Security: Vault Encryption, Access Control, and Playbook Hardening — HADESS | 2026
- ArgoCD Security: RBAC, SSO, and GitOps Access Control — HADESS | 2026
- CI/CD Security: Pipeline Hardening and Supply Chain Integrity — HADESS | 2026
Take the Next Step
Browse 80+ skills on HADESS. Go to the browse 80+ skills on hadess on HADESS.
See your certification roadmap. Check out the see your certification roadmap.
Get started free — Create your HADESS account and access all career tools.
Frequently Asked Questions
How long does it take to learn this skill?
Most practitioners build working proficiency in 4-8 weeks of dedicated study with hands-on practice. Mastery takes longer and comes primarily through on-the-job experience.
Do I need certifications for this skill?
Certifications validate your knowledge to employers but are not strictly required. Hands-on experience and portfolio projects often carry more weight in technical interviews. Check the certification roadmap for relevant options.
What career paths use this skill?
Explore the career path explorer to see which roles require this skill and how it fits into different cybersecurity specializations.
—
HADESS Team consists of cybersecurity practitioners, hiring managers, and career strategists who have collectively spent 50+ years in the field.
