Implementing DevSecOps in CI/CD

Implementing DevSecOps Practices into the CI/CD Pipeline

Security vulnerabilities found in production cost companies 30 times more to fix than if caught during development. Yet most teams only think about security just before release—or after an incident. We integrate security checks directly into the development workflow: pre-commit hooks, CI/CD pipelines, and Kubernetes deployments. Our specialists have been implementing DevSecOps for over 7 years across 50+ projects, reducing early-stage security incidents by 80% compared to manual penetration testing (according to NIST).

Why "Just Install Trivy" Isn't Enough

The most common mistake is installing one tool and considering the task done. A single service has multiple attack vectors, each requiring its own scanning tool.

Vector 1 – Application Code

SAST tools like SonarQube, Semgrep, and CodeQL detect vulnerable patterns: SQL injection, hardcoded credentials, unsafe deserialization.

Vector 2 – Dependencies

SCA (Software Composition Analysis) tools like Dependabot, Snyk, and OWASP Dependency-Check analyze npm, pip, and Maven dependencies for known CVEs.

Vector 3 – Containers

Trivy and Grype scan Docker images, including OS packages and transitive dependencies.

Vector 4 – Infrastructure as Code (IaC)

Checkov, tfsec, and KICS check Terraform, Kubernetes manifests, and Helm charts for open S3 buckets, excessive IAM permissions, lack of encryption at rest.

Vector 5 – Secrets in Code

gitleaks and truffleHog find accidentally committed API keys, tokens, and private keys.

Vector 6 – Runtime

Falco detects suspicious behavior in running containers: unexpected exec, modification of /etc/passwd, outbound network from unusual processes.

How We Handle False Positives

Every security tool generates false positives. A robust exemption process prevents engineers from disabling tools entirely.

For each exemption we record:

• Unique identifier (CVE or rule ID)
• Justification (why not applicable or fixable)
• Review date (typically +3 or +6 months)
• Person who made the decision

# semgrep inline suppression with justification
password = get_password()  # nosemgrep: python.lang.security.audit.hardcoded-password
# Exemption: password is read from env var, not hardcoded. Verified valid.

DevSecOps Pipeline Architecture

We distribute checks across stages based on speed and criticality: Pre-commit (seconds):

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.86.0
    hooks:
      - id: terraform_tfsec
      - id: terraform_checkov

CI/CD – security stage (parallel, minutes):

# .gitlab-ci.yml
stages: [build, security, test, deploy]

.security-base:
  stage: security
  needs: [build]

sast:
  extends: .security-base
  image: returntocorp/semgrep
  script:
    - semgrep --config=auto --error --json --output=semgrep.json src/
  artifacts:
    reports:
      sast: semgrep.json

container-scan:
  extends: .security-base
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --ignore-unfixed --severity CRITICAL --format sarif --output trivy.sarif $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: trivy.sarif

iac-scan:
  extends: .security-base
  image: bridgecrew/checkov:latest
  script:
    - checkov -d terraform/ --output junitxml --output-file-path checkov.xml --soft-fail-on MEDIUM
  artifacts:
    reports:
      junit: checkov.xml

dependency-scan:
  extends: .security-base
  script:
    - npm audit --audit-level=high # or pip-audit, safety

All security stages run in parallel—no sequential time added to the pipeline.

Finding Response Policy

Tools without a clear policy create noise. We agree on this upfront:

The policy must be documented and known to all—otherwise every blocked MR surprises developers. Fixing a vulnerability during development costs 30x less than in production (according to NIST).

Why Runtime Monitoring Matters

After deployment, Falco acts as a host intrusion detection system (HIDS) for Kubernetes:

---
# Example custom Falco rule
- rule: Unexpected Network Connection from App Container
  desc: Detects unexpected outbound connections from app containers
  condition: >
    outbound and container.image.repository = "myorg/myapp" and not fd.rip in (allowed_ips)
  output: >
    Unexpected outbound connection (user=%user.name command=%proc.cmdline connection=%fd.name container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [network, myapp]
---

Falco integrates with Falcosidekick to send events to Slack, PagerDuty, Elasticsearch.

Implementation Process

We never roll out everything at once. Priority order:

1. Week 1–2: gitleaks pre-commit + Trivy in CI (quickest ROI)
2. Week 3–4: SAST (Semgrep with basic ruleset) + dependency scanning
3. Month 2: IaC scanning + findings handling policy
4. Month 3: External Secrets Operator for secrets management + image signing
5. Month 4+: Falco runtime detection + OPA/Kyverno policies

Each phase starts in audit mode—collect baseline, fix existing issues, then enable blocking.

Real-World Impact

On one project for a fintech client, we reduced the number of security-critical findings from 47 to 2 within the first two weeks of scanning. Another client cut their average incident response time from 8 hours to 15 minutes after integrating Falco with automated alerts.

What You Get

• Audit of current CI/CD and infrastructure state
• Configuration of all described tools (gitleaks, Trivy, Semgrep, Checkov, Falco)
• Integration into your pipeline (GitLab CI, GitHub Actions, or Jenkins)
• Security policies for each finding type
• Documentation on the exemption handling process
• Team training in DevSecOps practices (2 workshops)
• 1 month of support post-implementation

Timeline

Cost is determined individually after an audit of your current infrastructure and CI/CD pipelines. Order a security audit of your CI/CD and get a consultation from certified engineers.