Infrastructure Security Review
Review the changed infrastructure in its provider context. Do not treat the absence of AWS-specific resources, DynamoDB locking, or one provider's private-network attribute as a generic vulnerability.
Workflow
1. Establish Scope
Identify:
- changed IaC, configuration-management, and bootstrap files
- providers, backends, and deployment environments
- public entry points and administrative paths
- secret sources and CI identities
- production data stores and backup paths
Review the diff first, then inspect the surrounding resources needed to understand behavior.
2. Run Native Validation
Use the tools already configured by the repository:
tofu fmt -check -recursive
tofu validate
tofu plan -out=tfplan
tofu show tfplan
Run configured scanners such as trivy config, checkov, tfsec, or policy tests when present. Do not introduce a scanner merely to claim coverage.
3. Review Security Boundaries
State
- remote state is access-controlled and encrypted where supported
- locking or equivalent concurrency protection is enabled when the backend supports it
- state, plans, and crash logs are excluded from version control and artifact exposure
- state migrations and imports preserve ownership
Secrets and Identity
- no credentials or secret defaults appear in source, plans, logs, or user data
- CI and provider identities use least privilege
- long-lived personal credentials are not used for automation
- secret rotation and revocation paths are explicit
Network
- administrative ports are not open to the world
- databases and internal services use private paths where supported
- firewall and security-group rules are narrow, directional, and attributable
- public exposure is intentional and documented
Compute and Bootstrap
- root login and password authentication are disabled unless justified
- downloaded scripts and packages have trusted, pinned sources
- bootstrap output does not leak secrets
- patching, monitoring, and recovery ownership are defined
Data and Storage
- public access is blocked unless explicitly required
- encryption, retention, backup, and restore behavior match the data classification
- destructive lifecycle settings are reviewed
- production databases have appropriate availability and recovery controls
Load patterns.md for the compact provider-neutral checklist.
4. Validate Findings
For every finding:
- cite the exact file and line
- explain the attack or failure path
- confirm the provider semantics from current documentation
- distinguish exploitable risk from optional hardening
- propose the smallest safe remediation
Do not report regex matches as confirmed vulnerabilities without reading the resource context.
Severity
- Critical: direct credential exposure, public sensitive data, or immediately exploitable administrative access
- High: practical compromise or major data-loss path requiring limited preconditions
- Medium: meaningful defense-in-depth, availability, or recovery gap
- Low: hardening improvement with limited present impact
Report Format
# Infrastructure Security Review
## Verdict
PASS | NEEDS CHANGES
## Findings
### [HIGH] Public SSH ingress
- Evidence: `infra/network.tf:42`
- Risk: ...
- Remediation: ...
## Validation
- Commands run: ...
- Provider documentation checked: ...
- Residual risks: ...
Return NEEDS CHANGES when any confirmed Critical or High finding remains unresolved.
1---2name: infrastructure-security-review3description: Review infrastructure as code for exploitable security failures and unsafe operational defaults. Use when auditing state, secrets, identity, network exposure, compute bootstrap, storage, databases, or supply-chain controls before deployment.4---56# Infrastructure Security Review78Review the changed infrastructure in its provider context. Do not treat the absence of AWS-specific resources, DynamoDB locking, or one provider's private-network attribute as a generic vulnerability.910## Workflow1112### 1. Establish Scope1314Identify:1516- changed IaC, configuration-management, and bootstrap files17- providers, backends, and deployment environments18- public entry points and administrative paths19- secret sources and CI identities20- production data stores and backup paths2122Review the diff first, then inspect the surrounding resources needed to understand behavior.2324### 2. Run Native Validation2526Use the tools already configured by the repository:2728```sh29tofu fmt -check -recursive30tofu validate31tofu plan -out=tfplan32tofu show tfplan33```3435Run configured scanners such as `trivy config`, `checkov`, `tfsec`, or policy tests when present. Do not introduce a scanner merely to claim coverage.3637### 3. Review Security Boundaries3839#### State4041- remote state is access-controlled and encrypted where supported42- locking or equivalent concurrency protection is enabled when the backend supports it43- state, plans, and crash logs are excluded from version control and artifact exposure44- state migrations and imports preserve ownership4546#### Secrets and Identity4748- no credentials or secret defaults appear in source, plans, logs, or user data49- CI and provider identities use least privilege50- long-lived personal credentials are not used for automation51- secret rotation and revocation paths are explicit5253#### Network5455- administrative ports are not open to the world56- databases and internal services use private paths where supported57- firewall and security-group rules are narrow, directional, and attributable58- public exposure is intentional and documented5960#### Compute and Bootstrap6162- root login and password authentication are disabled unless justified63- downloaded scripts and packages have trusted, pinned sources64- bootstrap output does not leak secrets65- patching, monitoring, and recovery ownership are defined6667#### Data and Storage6869- public access is blocked unless explicitly required70- encryption, retention, backup, and restore behavior match the data classification71- destructive lifecycle settings are reviewed72- production databases have appropriate availability and recovery controls7374Load [patterns.md](references/patterns.md) for the compact provider-neutral checklist.7576### 4. Validate Findings7778For every finding:79801. cite the exact file and line812. explain the attack or failure path823. confirm the provider semantics from current documentation834. distinguish exploitable risk from optional hardening845. propose the smallest safe remediation8586Do not report regex matches as confirmed vulnerabilities without reading the resource context.8788## Severity8990- **Critical:** direct credential exposure, public sensitive data, or immediately exploitable administrative access91- **High:** practical compromise or major data-loss path requiring limited preconditions92- **Medium:** meaningful defense-in-depth, availability, or recovery gap93- **Low:** hardening improvement with limited present impact9495## Report Format9697```markdown98# Infrastructure Security Review99100## Verdict101PASS | NEEDS CHANGES102103## Findings104### [HIGH] Public SSH ingress105- Evidence: `infra/network.tf:42`106- Risk: ...107- Remediation: ...108109## Validation110- Commands run: ...111- Provider documentation checked: ...112- Residual risks: ...113```114115Return `NEEDS CHANGES` when any confirmed Critical or High finding remains unresolved.
majesticlabs-dev