Secure SDLC Integration

Integrating security into the Software Development Lifecycle (SDLC) ensures that security is considered at every phase—from requirements to retirement.

Secure SDLC Pipeline Gates

SDLC Security Activities

Security Gates

Security gates are checkpoints where security criteria must be met before proceeding.

A gate is only useful if it can stop the pipeline. Gates that emit warnings without a pass/fail decision become background noise, so each one needs a defined threshold, an owner, and an escape hatch that requires explicit risk acceptance. Order them cheapest-and-earliest first: a secret caught by a pre-commit hook never reaches git history, where removal means rewriting history rather than reverting a commit.

Threat Modeling in CI

Threat modeling is only a gate if it runs in the pipeline. Page 01 — Threat Modeling defines the model; this subsection makes it executable. Treat the model as a versioned artifact committed next to the code — Threagile models it as YAML (assets, data flows, trust boundaries, and per-flow authentication), so the model lives in the same pull request as the architecture it describes.

The pipeline then runs the model as code on every change and fails the build when the analysis yields an unmitigated high or critical risk:

1. Commit the model (threat-model/threagile.yaml) and review it in the same PR as the design change.
2. Run Threagile in a CI job against the committed model — it ships as a container image, so no local install is needed.
3. Parse the generated risk report and assert that no high or critical risk is left unmitigated.
4. Fail the job — and therefore the merge — when that assertion is false; allow only an explicit, reviewed risk acceptance to pass.

This closes the loop with page 01: a new data flow that crosses a trust boundary without authentication shows up as a diff in the model, not as a finding discovered during penetration testing months later. The common failure is running the tool once and filing the report — a threat model that does not re-run cannot reflect the architecture it is meant to govern.

Practical: Pre-Commit Hooks

repos:
  # Secret detection — catch before they enter git
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

  # TruffleHog for high-entropy strings
  - repo: https://github.com/trufflesecurity/trufflehog
    rev: v3.97.4
    hooks:
      - id: trufflehog
        args: ['git', 'file://./']

  # Security linting
  - repo: https://github.com/PyCQA/bandit
    rev: 1.9.4
    hooks:
      - id: bandit
        args: ['-c', 'pyproject.toml']

  # Terraform security — tfsec is deprecated; pre-commit-terraform replaced
  # the terraform_tfsec hook with terraform_trivy
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.109.1
    hooks:
      - id: terraform_trivy

  # Dockerfile linting
  - repo: https://github.com/hadolint/hadolint
    rev: v2.15.1
    hooks:
      - id: hadolint

Practical: GitHub Actions Security Pipeline

name: Security Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

permissions:
  contents: read
  security-events: write

# Third-party actions are pinned by commit SHA (with the release tag in a
# comment) so a moved tag cannot change what runs in your pipeline.
jobs:
  secrets-scan:
    name: Secret Detection
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          fetch-depth: 0  # Full history for git-based scanning
      - uses: trufflesecurity/trufflehog@363923b901c911a9164f50b6c423f47c15372b1c  # v3.97.4
        with:
          extra_args: --only-verified

  sast:
    name: Static Analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
      - name: Run Semgrep (writes semgrep.sarif)
        run: |
          docker run --rm -v "$PWD:/src" -w /src semgrep/semgrep \
            semgrep scan --sarif --output semgrep.sarif --error \
            --config p/owasp-top-ten --config p/cwe-top-25 --config p/security-audit
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@b96794f015dfd88f77b49b1c93e0fa7110f94c63  # v4.38.0
        with:
          sarif_file: semgrep.sarif

  dependency-check:
    name: Dependency Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
      - name: Run Snyk
        uses: snyk/actions/node@9adf32b1121593767fc3c057af55b55db032dc04  # v1.0.0
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

  container-scan:
    name: Container Security
    runs-on: ubuntu-latest
    needs: [sast]
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
      - name: Build image
        run: docker build -t app:test .
      - name: Run Trivy
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25  # v0.36.0
        with:
          image-ref: app:test
          severity: CRITICAL,HIGH
          exit-code: 1  # Fail on critical/high

  iac-scan:
    name: IaC Security
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@a8664e3a0549367977f0cda990a34311835c87c0  # v12.3123.0
        with:
          directory: terraform/
          soft_fail: false
          framework: terraform

SDLC Maturity Models

Maturity models give a program a way to measure itself against a known baseline instead of guessing. They are diagnostic, not certification: the point is to find the practices you have not adopted and to prioritize the next one, not to collect a score.

DevSecOps Toolchain

Software Supply-Chain Integrity

Scanning your own code does not help if the artifact that reaches production was built somewhere else, from different inputs, or substituted in the registry. Supply-chain integrity answers three questions: was this built from the source we think, by a process we trust; is the artifact cryptographically the one that was produced; and what is actually inside it? The SLSA framework grades build provenance from level 1 (provenance exists) to level 3 (hardened, isolated builds with non-forgeable provenance) — a ladder to climb rather than a binary gate.

Signing with Sigstore and cosign binds an artifact's digest to a verified identity using short-lived certificates, so there is no long-lived private key to hold. Generate an SBOM at build time with Syft in CycloneDX or SPDX format, attach it to the artifact, and verify at admission: an admission controller (Kyverno, OPA Gatekeeper, or the Kubernetes policy engine you already run) should reject any image whose digest is unsigned or whose signature does not match an allowed builder identity.

Prefer digests to tags everywhere — image:tag is mutable and a re-push silently replaces what production runs, whereas image@sha256:… cannot change. The common failure is signing as a formality without verifying: a signature that nothing checks stops no attack. Wire verification into admission and treat an unsigned image as un-deployable by default; page 12 — Reference Architectures shows how this fits with the rest of the build pipeline.

Security Champions Program

Metrics & KPIs