Devops Security

DevOps Security Review

Overview

Runs a security checklist audit and selects appropriate CI security tools. Produces devops/report/security-findings.json and security tool configs in devops/working/ci/security/. Runs BEFORE devops-generate so security tool choices are baked into CI configs.

Inputs

Read devops/report/analysis.json before starting. The relevant fields are:

• scenario — "design", "codebase", or "review"
• choices.cloud_provider — "AWS", "GCP", "Azure", "Multi-cloud", or "Self-hosted"
• choices.ci_cd_platform — "GitHub Actions", "GitLab CI", or "CircleCI"
• choices.deployment_target — "Containers", "Kubernetes", "Serverless", or "VMs"
• detected.has_dockerfile — true/false

Security Checklist

Evaluate each item. For codebase and review scenarios, actively read source files and existing configs to check.

Rate each finding: Critical / High / Medium / Low. Only write a finding if the item FAILS the check. Items that pass are not included in output.

Design scenario handling: For each category that says "design scenario: skip", write no findings for that category. For categories with "design scenario: write Low findings", write a finding with severity "Low", finding "Cannot verify at design stage", and a remediation recommendation.

Category 1: Secrets & Credentials

• No hardcoded secrets in source files (grep for patterns: API_KEY, SECRET, PASSWORD, TOKEN, PRIVATE_KEY, aws_access_key, api_key =)
• .env files are listed in .gitignore
• CI/CD YAML files do not echo secret values in run: steps
• Secrets referenced by environment variable name, not literal value, in configs

Severity guide: Hardcoded secret in source = Critical. .env not gitignored = High. Secret echoed in CI = High. Secrets as literal values in non-CI configs = Medium.

Category 2: Container Security

If detected.has_dockerfile is false: Skip this category — write no findings. The devops-generate skill will create a secure Dockerfile.

If detected.has_dockerfile is true: Check the existing Dockerfile for each item below.

• App process does not run as root (Dockerfile has USER instruction before CMD)
• Base image uses a specific version tag, not latest
• Multi-stage build used to exclude dev dependencies from production image
• Dockerfile does not EXPOSE more than 2 ports unless the service is a documented multi-port service
• Base image is official (from Docker Hub official or distroless)

Severity guide: Running as root = High. latest tag = Medium. No multi-stage build = Medium. EXPOSE more than 2 ports without documentation = Low. Unofficial base image = Medium.

Category 3: Network Exposure

Design scenario: Write Low findings for each item below with finding "Cannot verify at design stage" and a remediation recommendation for implementation time. Do not attempt to verify against source code.

Codebase / review scenario: Check framework config files and source files for each item:

• API endpoints that modify data require authentication middleware
• Rate limiting configured (check for express-rate-limit, django-ratelimit, etc.)
• CORS policy is restrictive — not origin: '*' in production config
• HTTPS enforced (HTTP requests redirect to HTTPS)

Severity guide: No auth on data-modifying endpoints = Critical. Wildcard CORS in prod = High. No rate limiting = Medium. No HTTPS redirect = Medium.

Category 4: Dependencies

• Lockfile present (package-lock.json, yarn.lock, poetry.lock, go.sum, Gemfile.lock, Cargo.lock)
• No obviously outdated major versions in direct dependencies (check package.json/requirements.txt dates)
• Dockerfile RUN installs pin package versions (not pip install requests without ==version)

Severity guide: No lockfile = High. Unpinned Dockerfile installs = Medium. Outdated major versions = Low.

Category 5: CI/CD Pipeline

Design and codebase scenarios: Skip this category — write no findings. The generated pipeline will include proper controls.

Review scenario only: Check existing CI/CD config files for each item:

• Main/production branch is protected (requires PR review)
• Production deployments require manual approval gate
• Docker images are tagged with commit SHA, not latest
• No secrets stored as plain text in CI YAML

Severity guide: No prod approval gate = High. Secrets in CI YAML = Critical. Image tagged with latest = Medium.

Category 6: Cloud IAM

If choices.cloud_provider is "Self-hosted" or "Multi-cloud": Skip this category — write no findings.

If choices.cloud_provider is AWS, GCP, or Azure: Check existing infra-as-code (terraform/, pulumi/) if present. If no infra-as-code exists, write one Low finding per item below with finding "No infra-as-code found — cannot verify" and a remediation recommendation (e.g., "Use IAM roles with least-privilege — create Terraform IAM module at infra/iam.tf").

• Service accounts/roles use least-privilege (no * wildcard permissions)
• CI/CD runner role has only the permissions needed to deploy
• Storage buckets/blobs are not publicly accessible by default
• No long-lived access keys committed to repository

Severity guide: Wildcard IAM permissions = High. Public storage = High. Committed keys = Critical. No infra-as-code for IAM = Low.

Category 7: OWASP Top 10 (framework-specific)

Apply based on detected framework (from stack.framework in analysis.json). For design scenario, write Low findings for each applicable item.

• Injection: ORM or parameterized queries used (no string-concatenated SQL queries visible in source)
• Authentication: Session expiry configured; passwords hashed using bcrypt or argon2
• Security Misconfiguration: Debug mode disabled in production config; detailed error messages not returned to clients
• Vulnerable Components: See Dependencies category — flag unresolved issues here too if dependency findings exist

Severity guide: SQL injection risk (string-concatenated queries found) = Critical. Debug mode in prod = High. No password hashing = High. Auth missing session expiry = Medium.

Category 8: Secrets Management

• Production secrets stored in secrets manager (not .env files committed to repo)
• Dev secrets in .env.local (gitignored), not .env (which may be committed)
• Secret rotation policy exists or is recommended

Severity guide: Production secrets in committed env file = Critical. No rotation policy = Low.

Security Tool Selection

Read choices.ci_cd_platform and choices.deployment_target from analysis.json to populate selected_tools:

Output

1. Write security-findings.json

Create devops/report/security-findings.json. Populate summary counts from actual findings. Populate selected_tools from the tool selection table above using the exact lowercase strings: trivy, semgrep, codeql, dependabot, snyk, gitleaks, owasp-zap.

{
  "summary": {
    "critical": 0,
    "high": 0,
    "medium": 0,
    "low": 0
  },
  "findings": [
    {
      "category": "Secrets & Credentials",
      "severity": "Critical",
      "finding": "Specific description of what was found",
      "remediation": "Specific fix: e.g., move API_KEY to .env.local and add to .gitignore"
    }
  ],
  "selected_tools": ["trivy", "semgrep", "gitleaks"],
  "scenario": "codebase"
}

2. Write Gitleaks config

Create devops/working/ci/security/.gitleaks.toml:

title = "Gitleaks Config"

[allowlist]
  description = "Allowlisted paths"
  paths = [
    # devops/working/ is allowlisted because it contains generated tool configs, not application code
    '''devops/working/''',
    '''\.env\.example$''',
  ]

3. Write Trivy ignore

Create devops/working/ci/security/.trivyignore:

# Add CVE IDs here to suppress false positives after manual review
# Example: CVE-2023-12345

Confirmation

After writing all output files, tell the user:

Security review complete.
  Critical: N | High: N | Medium: N | Low: N
  Tools selected: [list]
  Saved to devops/report/security-findings.json

Top findings:
  [List up to 3 findings, sorted by severity (Critical first, then High, then Medium, then Low). Break ties by listing in checklist order. If fewer than 3 findings total, list all of them.]
  Format each as: [SEVERITY] Category — one-line remediation