
Building DevSecOps Pipeline
FreeIntegrate security testing into your GitLab CI/CD pipeline.
Free · Opens the source repo
What Building DevSecOps Pipeline does
The Building DevSecOps Pipeline with GitLab CI skill enables developers and security teams to seamlessly integrate security testing into their CI/CD workflows using GitLab. By leveraging GitLab's built-in security features, including Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), container scanning, dependency scanning, and secret detection, this skill helps teams identify and remediate vulnerabilities early in the development cycle. This proactive approach to security, often referred to as 'shifting left', allows teams to tackle potential issues before they reach production.
This skill is particularly useful for organizations that require compliance with security standards and regulations. It provides a comprehensive framework for implementing security controls directly within the GitLab CI/CD pipeline, ensuring that security assessments are part of the development process rather than an afterthought. The inclusion of GitLab Duo AI further enhances the process by assisting in the detection of false positives in SAST findings, allowing teams to focus their efforts on genuine vulnerabilities.
To utilize this skill effectively, users must have a GitLab Ultimate license and familiarity with GitLab Runner and the .gitlab-ci.yml configuration. The skill also requires a staging environment for DAST scanning and the use of Docker for container builds. With a complete pipeline configuration provided, users can quickly set up the necessary stages for building, testing, and deploying applications while ensuring security checks are enforced at each step.
Overall, this skill is designed for development and security teams looking to enhance their CI/CD processes with integrated security practices, making it an essential tool for modern software development.
When to use it
Use this skill when setting up or enhancing a DevSecOps pipeline in GitLab, particularly when compliance and security are priorities.
When not to use it
This skill is not suitable for teams not using GitLab or those without a GitLab Ultimate license, as it relies on features exclusive to that version.
What you can build with it
Setting Up a New DevSecOps Pipeline
Utilize this skill to configure a new DevSecOps pipeline in GitLab, ensuring security checks are integrated from the start.
Enhancing Existing CI/CD Processes
Implement this skill to add automated security scanning stages to an existing GitLab CI/CD pipeline.
Compliance and Security Assessments
Use this skill to align your development practices with compliance requirements and conduct thorough security assessments.
How to install Building DevSecOps Pipeline
View source1. Install with the skills CLI
npx skills add mukul975/anthropic-cybersecurity-skills/building-devsecops-pipeline-with-gitlab-ci --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by mukul975Building DevSecOps Pipeline with GitLab CI
Overview
GitLab provides an integrated DevSecOps platform that embeds security testing directly into the CI/CD pipeline. By leveraging GitLab's built-in security scanners---SAST, DAST, container scanning, dependency scanning, secret detection, and license compliance---teams can shift security left, catching vulnerabilities during development rather than post-deployment. GitLab Duo AI assists with false positive detection for SAST vulnerabilities, helping security teams focus on genuine issues.
When to Use
- When deploying or configuring building devsecops pipeline with gitlab ci capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation
Prerequisites
- GitLab Ultimate license (required for full security scanner suite)
- GitLab Runner configured (shared or self-hosted)
.gitlab-ci.ymlpipeline configuration familiarity- Docker-in-Docker (DinD) or Kaniko for container builds
- Application deployed to a staging environment for DAST scanning
Core Security Scanning Stages
Static Application Security Testing (SAST)
SAST analyzes source code for vulnerabilities before compilation. GitLab supports 14+ languages using analyzers such as Semgrep, SpotBugs, Gosec, Bandit, and NodeJsScan. The simplest inclusion uses GitLab's managed templates.
Dynamic Application Security Testing (DAST)
DAST tests running applications by simulating attack payloads against HTTP endpoints. It detects XSS, SQLi, CSRF, and other runtime vulnerabilities that static analysis cannot find. DAST requires a deployed, accessible target URL.
Container Scanning
Uses Trivy to scan Docker images for known CVEs in OS packages and application dependencies. Runs after the Docker build stage to gate images before they reach a registry.
Dependency Scanning
Inspects dependency manifests (package.json, requirements.txt, pom.xml, Gemfile.lock) for known vulnerable versions. Operates at the source code level, complementing container scanning.
Secret Detection
Scans commits for accidentally committed credentials, API keys, tokens, and private keys using pattern matching and entropy analysis. Runs on every commit to prevent secrets from reaching the repository.
Implementation
Complete Pipeline Configuration
# .gitlab-ci.yml
stages:
- build
- test
- security
- deploy-staging
- dast
- deploy-production
variables:
DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
SECURE_LOG_LEVEL: "info"
# Include GitLab managed security templates
include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/Secret-Detection.gitlab-ci.yml
- template: Security/Dependency-Scanning.gitlab-ci.yml
- template: Security/Container-Scanning.gitlab-ci.yml
- template: DAST.gitlab-ci.yml
- template: Security/License-Scanning.gitlab-ci.yml
build:
stage: build
image: docker:24.0
services:
- docker:24.0-dind
variables:
DOCKER_TLS_CERTDIR: "/certs"
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $DOCKER_IMAGE .
- docker push $DOCKER_IMAGE
rules:
- if: $CI_COMMIT_BRANCH
unit-tests:
stage: test
image: $DOCKER_IMAGE
script:
- npm ci
- npm run test:coverage
coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'
artifacts:
reports:
junit: junit-report.xml
coverage_report:
coverage_format: cobertura
path: coverage/cobertura-coverage.xml
# Override SAST to run in security stage
sast:
stage: security
variables:
SAST_EXCLUDED_PATHS: "spec,test,tests,tmp,node_modules"
SEARCH_MAX_DEPTH: 10
# Override container scanning
container_scanning:
stage: security
variables:
CS_IMAGE: $DOCKER_IMAGE
CS_SEVERITY_THRESHOLD: "HIGH"
# Override dependency scanning
dependency_scanning:
stage: security
# Override secret detection
secret_detection:
stage: security
# License compliance scanning
license_scanning:
stage: security
deploy-staging:
stage: deploy-staging
image: bitnami/kubectl:latest
script:
- kubectl set image deployment/app app=$DOCKER_IMAGE -n staging
- kubectl rollout status deployment/app -n staging --timeout=300s
environment:
name: staging
url: https://staging.example.com
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
# DAST runs against deployed staging
dast:
stage: dast
variables:
DAST_WEBSITE: https://staging.example.com
DAST_FULL_SCAN_ENABLED: "true"
DAST_BROWSER_SCAN: "true"
needs:
- deploy-staging
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
deploy-production:
stage: deploy-production
image: bitnami/kubectl:latest
script:
- kubectl set image deployment/app app=$DOCKER_IMAGE -n production
- kubectl rollout status deployment/app -n production --timeout=300s
environment:
name: production
url: https://app.example.com
when: manual
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
Security Approval Policies
Configure scan execution policies to enforce mandatory security scans:
- Navigate to Security & Compliance > Policies
- Create a "Scan Execution Policy" requiring SAST and secret detection on all branches
- Create a "Merge Request Approval Policy" requiring security team approval when critical vulnerabilities are detected
Custom SAST Ruleset Configuration
Create .gitlab/sast-ruleset.toml to customize analyzer behavior:
[semgrep]
[[semgrep.ruleset]]
dirs = ["src"]
[[semgrep.passthrough]]
type = "url"
target = "/sgrep-rules/custom-rules.yml"
value = "https://semgrep.dev/p/owasp-top-ten"
[[semgrep.passthrough]]
type = "url"
target = "/sgrep-rules/java-rules.yml"
value = "https://semgrep.dev/p/java"
Security Dashboard and Vulnerability Management
Vulnerability Report
GitLab consolidates all scanner findings into a single Vulnerability Report accessible at Security & Compliance > Vulnerability Report. Each vulnerability includes:
- Severity rating (Critical, High, Medium, Low, Info)
- Scanner source (SAST, DAST, Container, Dependency, Secret)
- Location in source code or image layer
- Remediation guidance and suggested fixes
- Status tracking (Detected, Confirmed, Dismissed, Resolved)
Merge Request Security Widget
Every merge request displays a security scanning widget showing:
- New vulnerabilities introduced by the MR
- Fixed vulnerabilities resolved by the MR
- Comparison against the target branch baseline
Pipeline Optimization
- Parallel execution: Security scanners run concurrently in the security stage
- Caching: Use CI cache for dependency downloads to speed up scanning
- Incremental scanning: SAST can scan only changed files using
SAST_INCREMENTAL: "true" - Fail conditions: Set
allow_failure: falseon critical scanners to enforce quality gates
Monitoring and Metrics
| Metric | Description | Target |
|---|---|---|
| Pipeline security coverage | Percentage of projects with all scanners enabled | > 95% |
| Critical vulnerability MTTR | Time from detection to resolution for critical findings | < 48 hours |
| False positive rate | Percentage of dismissed-as-false-positive findings | < 15% |
| Secret detection block rate | Percentage of secret commits blocked by push rules | > 99% |
References
Frequently asked questions about Building DevSecOps Pipeline
Similar skills
GitHub Actions Hardening
Enhance the security of your GitHub Actions workflows.
Sensitive Logging Audit
Audit and fix sensitive data exposure in Python logging.
Android App Static Analysis
Automate security assessments of Android apps with MobSF.
Integrating DAST with OWASP ZAP
Seamlessly integrate dynamic security testing into CI/CD pipelines.
Implementing Runtime Security with Tetragon
Enhance Kubernetes security with eBPF-based observability.
Implementing Mobile Application Management
Secure enterprise data on mobile devices with app-level controls.
