Menu
Use when called by the devops dispatcher after analysis to audit security posture and select CI security tooling before config generation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when called by the devops dispatcher after config generation to produce a self-contained HTML report with architecture and workflow diagrams embedded as inline SVG
Use when called by the devops dispatcher to analyze a project and gather DevOps configuration choices through guided questions before generating configs
Use when called by the devops dispatcher after security review to generate all DevOps config files based on analysis.json and security-findings.json
Use when a user asks to set up CI/CD, Dockerize a project, add a deployment pipeline, configure GitHub Actions / GitLab CI / CircleCI, review existing DevOps config, or says "we have no CI", "no pipeline", "need to containerize this", or "help with deployments". Proactively suggest when source code is present but no devops/ folder or CI config files exist.
| name | devops-security |
| description | Use when called by the devops dispatcher after analysis to audit security posture and select CI security tooling before config generation |
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.
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/falseEvaluate 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.
API_KEY, SECRET, PASSWORD, TOKEN, PRIVATE_KEY, aws_access_key, api_key =).env files are listed in .gitignorerun: stepsSeverity guide: Hardcoded secret in source = Critical. .env not gitignored = High. Secret echoed in CI = High. Secrets as literal values in non-CI configs = Medium.
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.
USER instruction before CMD)latestSeverity 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.
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:
origin: '*' in production configSeverity guide: No auth on data-modifying endpoints = Critical. Wildcard CORS in prod = High. No rate limiting = Medium. No HTTPS redirect = Medium.
package-lock.json, yarn.lock, poetry.lock, go.sum, Gemfile.lock, Cargo.lock)pip install requests without ==version)Severity guide: No lockfile = High. Unpinned Dockerfile installs = Medium. Outdated major versions = Low.
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:
latestSeverity guide: No prod approval gate = High. Secrets in CI YAML = Critical. Image tagged with latest = Medium.
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").
* wildcard permissions)Severity guide: Wildcard IAM permissions = High. Public storage = High. Committed keys = Critical. No infra-as-code for IAM = Low.
Apply based on detected framework (from stack.framework in analysis.json). For design scenario, write Low findings for each applicable item.
Severity guide: SQL injection risk (string-concatenated queries found) = Critical. Debug mode in prod = High. No password hashing = High. Auth missing session expiry = Medium.
.env files committed to repo).env.local (gitignored), not .env (which may be committed)Severity guide: Production secrets in committed env file = Critical. No rotation policy = Low.
Read choices.ci_cd_platform and choices.deployment_target from analysis.json to populate selected_tools:
| Tool | When to Include |
|---|---|
| Trivy | Always — container + dependency CVE scanning |
| Semgrep | Always — open source SAST, no account required |
| CodeQL | Include if choices.ci_cd_platform = "GitHub Actions" |
| Dependabot | Include if choices.ci_cd_platform = "GitHub Actions" |
| Snyk | Include if choices.ci_cd_platform = "GitLab CI" or "CircleCI" |
| Gitleaks | Always — secrets detection in git history and CI |
| OWASP ZAP | Include if choices.deployment_target = "Containers" or "Kubernetes" |
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"
}
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$''',
]
Create devops/working/ci/security/.trivyignore:
# Add CVE IDs here to suppress false positives after manual review
# Example: CVE-2023-12345
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