Security Configuration Review

Review infrastructure and configuration files for security misconfigurations. This skill is language-agnostic and supports containers, orchestration, CI/CD pipelines, web frameworks, cloud IaC, and secrets management.

Workflow

Step 1: Configuration Discovery

Scan the project for all configuration files. Auto-detect file types across these categories:

Container & Orchestration:

• Dockerfile, Dockerfile.*, *.dockerfile
• docker-compose.yml, docker-compose.*.yml, compose.yml, compose.*.yml
• .dockerignore
• Kubernetes manifests: *.yaml, *.yml in k8s/, kubernetes/, manifests/, deploy/, helm/ directories, or any YAML with apiVersion/kind fields

CI/CD Pipelines:

• .github/workflows/*.yml
• .gitlab-ci.yml
• Jenkinsfile, Jenkinsfile.*
• .circleci/config.yml
• azure-pipelines.yml
• bitbucket-pipelines.yml
• .travis.yml

Web Framework Configuration:

• Express/Node.js: index.ts, index.js, app.ts, app.js, server.ts, server.js, package.json
• Flask: app.py, config.py, wsgi.py, __init__.py
• Django: settings.py, settings/*.py, urls.py
• Spring Boot: application.yml, application.properties, application-*.yml, application-*.properties, pom.xml
• Laravel: .env, config/*.php, config/app.php, config/auth.php, config/cors.php
• ASP.NET: appsettings.json, appsettings.*.json, Startup.cs, Program.cs, web.config

Secrets & Credentials:

• .env, .env.*, .env.local, .env.production
• credentials.json, serviceAccount.json, secrets.yaml, secrets.json
• Vault config files
• *.pem, *.key (check if committed)

Cloud Infrastructure as Code:

• terraform/*.tf, *.tf, terraform.tfvars, *.tfvars
• cloudformation/*.yaml, cloudformation/*.json, *.template
• pulumi/*, Pulumi.yaml, Pulumi.*.yaml
• ansible/*.yml, playbook*.yml

Use Glob and Grep to discover these files. Do not assume a project uses only one technology — scan for all categories.

Step 2: Checklist Application

For each discovered configuration file, use the Read tool to load the appropriate hardening checklist from the reference documents:

• Docker/Kubernetes files: Use references/docker_hardening.md
• Web framework configs: Use references/web_framework_hardening.md
• Secret/credential files: Use references/secrets_management.md
• CI/CD pipeline files: Use references/cicd_hardening.md

Use the Read tool to read each config file fully. Check every applicable item from the relevant checklist. Do not skip checks — be thorough.

Step 3: Severity Assessment

Rate each finding using this scale:

Step 4: Context Evaluation

Consider the project context before finalizing findings:

• Development vs Production: A DEBUG=True in a clearly-labeled dev config is lower severity than in a production config. Note the distinction but still flag it.
• Project type: A public-facing web app has different threat exposure than an internal tool.
• Existing mitigations: If a reverse proxy handles TLS and headers, missing framework-level headers may be mitigated. Note this.
• Intentional choices: Some configs may be intentionally permissive for valid reasons. Flag but acknowledge.

Do NOT dismiss findings just because it is a development project. Development configs often become production configs.

Step 5: Report

Present findings in a structured report. For each finding include:

Group findings by severity (Critical first, then High, Medium, Low).

End the report with:

• A summary count: X Critical, Y High, Z Medium, W Low
• Top 3 priority actions to take immediately
• Any positive security practices already in place (acknowledge good config)