Devsecops

DevSecOps

When to Use

• Add or harden SAST, SCA, secrets, IaC, DAST, or container scans in CI/CD
• Configure protected-branch security gates, artifact signing, SBOMs, provenance, or OIDC federation
• Triage pipeline security findings and define remediation SLAs or exception workflows
• Secure GitHub Actions, GitLab CI, build containers, registries, and deployment credentials
• Map delivery artifacts to SOC 2, ISO 27001, SSDF, or supply-chain evidence requirements

When NOT to Use

• Provision general cloud infrastructure without a security gate focus → infrastructure-engineer
• Operate build/deploy pipelines without security requirements → devops
• Implement corporate IdP, KMS, PAM, SIEM, or EDR controls → information-security-engineer
• IAM entitlement design, access reviews, federation (non-pipeline) → iam-specialist
• Triage live SOC alerts or run SOAR playbooks → soc-analyst
• Threat hunts or SIEM detection authoring → defensive-security-analyst
• Define company-wide security strategy or GRC roadmap → cybersecurity
• Bootstrap clusters, Helm releases, ingress, routine pod debug → cluster-deployment-engineer
• Execute authorized penetration tests or exploit PoCs → penetration-tester
• Manual web/API OWASP testing and retest → web-pentester
• Disassembly, decompilation, patch diff, or malware RE lab work → reverse-engineer

Related skills

Core Workflows

1. Shift-left security baseline

Apply on every repo before merge to default branch:

1. Inventory languages, build tool, deploy target, and compliance scope 2. Enable secret scanning and push protection on the org/repo 3. Add SAST + SCA in CI on pull requests (fail on new critical/high) 4. Scan IaC on terraform plan / manifest changes (Checkov, tfsec, KICS) 5. Scan container images before registry push (Trivy, Grype) 6. Document exceptions with owner, expiry, and compensating control

Gate policy (default):

See `references/shift_left_scanning.md` for tool matrices, baseline configs, and false-positive handling.

2. CI/CD security gates

Pipeline order (security stages must not be skippable on protected branches):

lint → unit test → SAST/SCA → build → image scan → sign/SBOM → deploy staging → DAST (if applicable) → promote prod

Checklist:

• [ ] Use OIDC federation to cloud/K8s—no long-lived cloud keys in CI secrets
• [ ] Pin actions/images by digest or immutable version; allowlist third-party actions
• [ ] Separate build (untrusted) from deploy (trusted) jobs with environment protection rules
• [ ] Require code review + passing checks on default branch
• [ ] Store artifacts in immutable registry; verify signatures at deploy
• [ ] Log retention for audit (who deployed what, from which commit)

See `references/cicd_security_gates.md` for GitHub Actions/GitLab patterns, OIDC, and deployment controls.

3. Supply chain integrity

Minimum viable supply chain for production services:

1. Generate SBOM (CycloneDX or SPDX) on each release build 2. Sign container images and/or provenance (Sigstore/cosign, SLSA-oriented attestations where required) 3. Block dependencies with known critical CVEs unless documented exception 4. Prefer pinned lockfiles; review major dependency upgrades in PR 5. Vet new third-party actions, Helm charts, and base images

See `references/supply_chain.md` for SBOM fields, signing flows, and dependency update policy.

4. Cloud, container, and runtime security

Pre-production checklist:

• [ ] Workloads in private subnets; ingress only via LB/WAF
• [ ] Non-root containers, read-only root FS, dropped capabilities, no privileged pods
• [ ] Network policies or service mesh mTLS for east-west traffic
• [ ] Secrets from Vault/Secrets Manager/External Secrets—not in manifests or env in git
• [ ] CSPM/posture alerts wired to on-call for critical misconfigurations
• [ ] Runtime detection (Falco, cloud-native threat detection) for production clusters

See `references/cloud_runtime_security.md` for K8s admission policies, WAF, and CSPM triage.

5. Threat modeling and security review

Lightweight review (every feature with auth, payments, PII, or external input):

1. Draw data flow: actors, trust boundaries, stores, external APIs 2. List assets and STRIDE threats per boundary 3. Map mitigations to existing controls or new tickets 4. Record accepted risks with approver and review date

Deeper review triggers: new public API, auth model change, multi-tenant isolation change, crypto design, admin tooling, agent/LLM in production path.

See `references/threat_modeling.md` for STRIDE prompts, abuse-case templates, and review cadence.

6. Vulnerability management and compliance evidence

Triage workflow:

1. Normalize findings (tool, CVE, asset, environment, exploitability) 2. Score with CVSS + business context (internet-facing, data class, compensating controls) 3. Assign owner and remediation SLA (see reference SLAs) 4. Verify fix in CI rescan before closing 5. Aggregate metrics: MTTR, open critical count, recurring classes

Compliance: map controls to delivery artifacts (pipeline configs, scan reports, access reviews, change tickets).

See `references/compliance_evidence.md` for SOC 2 / ISO 27001 / SSDF mapping and audit artifact list.

When to load references

• SAST, SCA, secrets, IaC scans → references/shift_left_scanning.md
• Pipeline gates, OIDC, GitHub/GitLab hardening → references/cicd_security_gates.md
• SBOM, signing, dependencies → references/supply_chain.md
• K8s, CSPM, WAF, runtime → references/cloud_runtime_security.md
• STRIDE, abuse cases, review templates → references/threat_modeling.md
• SLAs, SOC 2/ISO evidence → references/compliance_evidence.md

CI/CD security gates

Table of contents

1. Protected branches and environments 2. OIDC federation 3. GitHub Actions hardening 4. GitLab CI hardening 5. Deploy-time controls 6. Agentic CI risks

Protected branches and environments

OIDC federation

Replace static AWS keys:

permissions:
  id-token: write
  contents: read

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/github-deploy
    aws-region: us-east-1

IAM trust policy essentials:

• Restrict sub to repo:ORG/REPO:ref:refs/heads/main (or environment)
• Restrict aud to STS provider audience
• Least-privilege policy on the role—no * on iam:* or s3:* unless justified

Same pattern applies to GCP Workload Identity Federation and Azure Federated Credentials.

GitHub Actions hardening

Dangerous patterns to block in review:

• curl | bash from unpinned URLs in workflows
• Passing ${{ github.event.issue.body }} into shell without sanitization
• Wildcard allowed-users on workflow_dispatch from untrusted actors
• Storing cloud keys in repo/org secrets without rotation

GitLab CI hardening

• Use protected branches and protected variables (environment-scoped)
• Separate deploy stage with when: manual for production
• Enable dependency and SAST templates from GitLab Security
• Restrict runner tags so production deploys only on hardened runners

Deploy-time controls

1. Immutable artifact: image digest or signed bundle, not floating tag 2. Verify signature before apply (cosign verify, Notation) 3. Policy check: OPA/Gatekeeper/Kyverno deny non-compliant manifests 4. Smoke test post-deploy; automatic rollback on failed health 5. Audit record: commit SHA, actor, pipeline ID, artifact digest in change ticket

Agentic CI risks

When CI runs AI coding agents (Claude Code Action, Codex, Gemini CLI):

• Treat PR comments, issue bodies, and fork content as untrusted input
• Never pass untrusted text into run: shell via string interpolation
• Sandbox with minimal permissions; no org-wide secrets on fork workflows
• Require human review for changes touching workflows, IAM, or auth code
• See dedicated agentic-actions-auditor skill when available for workflow-specific checks

Cloud and runtime security

Table of contents

1. Kubernetes admission 2. Network segmentation 3. Secrets and identity 4. CSPM triage 5. WAF and edge 6. Runtime detection

Kubernetes admission

Enforce with Kyverno or OPA Gatekeeper (pick one per cluster).

Sample Kyverno (concept): require runAsNonRoot: true on Deployments in namespace production.

Network segmentation

• Default-deny network policies; allowlist by label
• Ingress only through ingress controller + WAF
• Egress allowlist for workloads that do not need open internet
• Private endpoints for managed databases and object storage

Secrets and identity

Rotate secrets on compromise, role change, or quarterly for high-risk systems.

CSPM triage

When posture tool flags a finding:

1. Confirm resource ID, account, environment (prod vs dev) 2. Classify: misconfiguration vs intended exception 3. Check blast radius (public exposure, data class) 4. Remediate via IaC PR or automated auto-remediation where safe 5. Document exception with expiry if not fixing immediately

High-priority CSPM categories: public storage, open security groups on admin ports, disabled encryption, overly permissive IAM, logging disabled.

WAF and edge

• OWASP CRS or managed rule sets on public HTTP APIs
• Rate limiting and geo blocks where appropriate
• TLS termination at edge; HSTS for browser clients
• Block common probes; alert on rule spikes

Runtime detection

Response: isolate workload (network policy, scale to zero), capture forensics snapshot, rotate credentials, open incident per severity matrix in compliance_evidence.md.

Compliance and evidence

Table of contents

1. Remediation SLAs 2. SOC 2 mapping (delivery) 3. ISO 27001 touchpoints 4. SSDF / secure development 5. Audit artifact checklist 6. Security incident severity

Remediation SLAs

Adjust for exploitability, exposure (internet-facing), and compensating controls. Document extensions in waiver register.

SOC 2 mapping (delivery)

ISO 27001 touchpoints

SSDF / secure development

Map practices to NIST SSDF practices (PO, PS, PW, RV):

• Prepare: security training, tool standards, threat modeling policy
• Protect: branch protection, secrets management, least privilege
• Produce: SAST/SCA/IaC in CI, code review, signed artifacts
• Respond: vuln triage, incident response, postmortems

Audit artifact checklist

Collect automatically where possible:

• [ ] Branch protection and required check configuration export
• [ ] Sample PR showing security checks passed
• [ ] SAST/SCA scan reports for release tag
• [ ] Container scan report for deployed image digest
• [ ] SBOM for release
• [ ] Sign/provenance verification log
• [ ] Access review for CI and production roles (quarterly)
• [ ] Waiver register with approvals and expiry
• [ ] Threat model for critical service (current version)
• [ ] Penetration test summary and remediation tracker (annual or per major change)

Store in immutable bucket or GRC tool with retention matching audit period.

Security incident severity

Response phases: contain → eradicate → recover → post-incident review (blameless). Link to infrastructure-engineer runbooks for platform-specific steps.

Shift-left scanning

Table of contents

1. Scan types 2. Tool selection 3. CI integration patterns 4. Baseline rules 5. False positives and noise

Scan types

Tool selection

CI integration patterns

Principles:

• Run fast scans on PR; run full scans nightly on default branch
• Upload SARIF to the platform security tab when available
• Fail builds on new critical issues introduced in the diff when possible (diff-aware scanning)

Example: Semgrep in GitHub Actions

- name: Semgrep
  uses: semgrep/semgrep-action@v1
  with:
    config: p/ci
  env:
    SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

Example: Trivy image scan

- uses: aquasecurity/trivy-action@master
  with:
    image-ref: ${{ env.IMAGE }}
    format: sarif
    output: trivy.sarif
    severity: CRITICAL,HIGH
    exit-code: 1

Baseline rules

1. No secrets in repository history—rotate if found 2. No 0.0.0.0/0 ingress on admin ports in production IaC 3. No latest tag for production deploy images 4. No privileged containers or hostNetwork: true in prod namespaces 5. TLS 1.2+ for external endpoints; prefer 1.3

False positives and noise

Waiver template:

## Security waiver: [ID]
- Finding: [tool + rule + CVE]
- Asset: [service/repo]
- Risk: [why accepted]
- Compensating controls: [WAF, network policy, etc.]
- Owner: @team
- Expires: YYYY-MM-DD
- Revisit trigger: [upgrade, exposure change]

Supply chain security

Table of contents

1. SBOM requirements 2. Artifact signing 3. Dependency policy 4. Third-party risk 5. SLSA orientation

SBOM requirements

Generate on every release build (not only on request).

Tools: Syft, CycloneDX CLI, GitHub dependency submission, build tools with native SBOM export.

Store SBOM alongside artifact in registry or artifact store; retain per release for audit window (typically 1–3 years).

Artifact signing

Deploy gate pseudocode:

build → push image@digest → sign digest → deploy only if verify(signature) == OK

Dependency policy

Reachability: prefer scanners that mark CVEs as reachable/unreachable in the dependency graph to reduce noise.

Third-party risk

Before adopting:

• GitHub Action: pinned SHA, org reputation, permissions requested
• Helm chart: verify publisher, scan chart templates, pin version
• Base image: official or distroless; scan and rebuild on CVE SLA
• SaaS CI integration: OAuth scopes, data residency, SOC 2 report

SLSA orientation

Most teams target L2 with hosted CI + signed provenance; L3 requires dedicated build infrastructure.

Provenance attestation (conceptual): builder records source repo, commit, build command, materials; consumer policy checks attestation before deploy.

Threat modeling

Table of contents

1. When to model 2. STRIDE cheat sheet 3. Lightweight template 4. Abuse cases 5. Review cadence

When to model

STRIDE cheat sheet

Lightweight template

# Threat model: [Feature]

## Context
- Actors: [user, admin, partner, anonymous]
- Assets: [data stores, keys, revenue]
- Trust boundaries: [browser→API, API→DB, CI→cloud]

## Data flow
[Diagram or numbered steps]

## Threats
| ID | STRIDE | Threat | Mitigation | Status |
|----|--------|--------|------------|--------|
| T1 | I | ... | ... | Open/Done/Waived |

## Accepted risks
| ID | Rationale | Approver | Review date |

Abuse cases

Write as: Given [precondition] When [action] Then [impact].

Examples:

• User A changes {id} in URL to access User B's record (IDOR)
• Attacker replays webhook without signature verification
• Compromised CI secret deploys malicious image to production
• LLM tool call exfiltrates env var via crafted user message

Map each abuse case to a test (unit, integration, or security test) or monitoring alert.

Review cadence