infra-security

name

infra-security

description

Audit Infrastructure-as-Code for security misconfigurations before it ships — Terraform (.tf/.tfvars/.hcl), CloudFormation/SAM (YAML/JSON), Kubernetes & Helm manifests, and Docker / Docker Compose. Reads the IaC offline and reports each misconfiguration at file:line with a severity (P0–P3) and a corrected snippet. A dependency-free scanner does the high-recall first pass; the model adds blast-radius and cross-resource judgment. No cloud credentials, no terraform apply, no pip install. Trigger when reviewing a Terraform plan before apply, auditing K8s/Helm manifests or a Dockerfile before deploy, checking CloudFormation for public S3 buckets or open security groups, doing a pre-deployment or compliance (SOC-2 / PCI-DSS / ISO-27001) security review, or when the user asks "audit this Terraform", "is this S3 bucket public?", "is this security group open to the internet?", "is this container running as root?", "what's the blast radius if this infra is wrong?", or "run an IaC security scan".

Infrastructure-as-Code Security Scanner

This skill turns the model into a cloud security auditor. Read the IaC, find the dangerous misconfigurations, and report each one with a severity and a concrete fix. The analysis runs entirely against files on disk — no live cloud, no credentials, no apply.

The rules encode the consensus from the CIS Benchmarks, AWS Well-Architected, the Kubernetes Pod Security Standards, and the checks that tools like tfsec/trivy, checkov, kube-score, and cfn-nag ship — applied as a source read rather than another scanner to wire up.

How it works: two stages

This skill is deliberately split, the same way skill-security is.

• Stage 1 — the scanner (deterministic, mechanical). scripts/scan.py does the fast, high-recall work: it walks the target, classifies each file by format, and runs line-oriented detectors for the misconfigurations that are unambiguous in text (0.0.0.0/0 on port 22, Action: "*", privileged: true, runAsUser: 0, a public-read S3 ACL). It is offline and dependency-free — pure Python standard library, no pip install, no hcl2, no pyyaml. It emits findings with file:line and a CI-friendly exit code.
• Stage 2 — you (semantic, judgment). The scanner cannot reason about blast radius or compensating controls. You can. You read the flagged resources alongside the rest of the IaC and decide what the scanner cannot: is that 0.0.0.0/0 actually reachable, or fronted by a WAF? Does that wildcard IAM policy attach to an internet-facing instance, turning a P1 into a P0? Is the "missing" encryption set by a default elsewhere in the module? Stage 1 finds candidates; you confirm impact, suppress false positives, and catch the judgment-only misconfigs (least-privilege gaps, a missing resource, cross-resource chains) that no regex can see.

The scanner is high-recall, not high-precision on purpose. Trust its file:line anchors; apply your own judgment to severity and validity.

Mental model

Misconfiguration risk is exposure × blast radius, not a checklist tick.

• Exposure — can an attacker reach it? Internet-facing (0.0.0.0/0, public ACL, public subnet) is the top of the funnel. Internal-only, behind a private subnet or an authn proxy, is far lower.
• Blast radius — if reached, what falls? A wildcard IAM policy on a bastion is bad; the same policy on a role assumed by every Lambda is a takeover. Encryption-off on a scratch bucket is P3; on the bucket holding PII it is P1.

The same literal pattern can be P0 or P3 depending on these two axes — which is exactly why the scanner proposes and you decide. When you genuinely cannot tell the blast radius from the IaC alone, say so and rate conservatively with the assumption stated.

Workflow

Three phases, in order.

Phase 1 — Discover and ingest

Run the scanner over the target to get the candidate findings and a file inventory:

python3 scripts/scan.py <target-dir> --format markdown

It classifies files by extension and a content peek:

• Terraform — .tf, .tfvars, .hcl
• CloudFormation / SAM — .yaml/.yml/.json with AWSTemplateFormatVersion or a Resources: map of AWS::* types
• Kubernetes / Helm — .yaml/.yml with apiVersion: and kind: (multi-document streams split on ---)
• Docker — Dockerfile*, docker-compose*.yml

Use --format json when you want to fold the findings into your own reasoning programmatically; --severity P0,P1 to focus; the scanner exits 1 when any P0/P1 is present (so it gates a pipeline) and 0 otherwise.

Phase 2 — Evaluate by category

Take the scanner's candidates and read the surrounding IaC. Walk the categories in references/controls.md, confirming impact and looking for the judgment-only gaps the scanner can't:

• Identity & Access (IAM) — wildcard Action/Resource, * principals in resource policies, over-broad roles attached to compute, missing least privilege, hardcoded credentials.
• Network & Firewall — 0.0.0.0/0 to sensitive ports (22, 3389, 3306, 5432, 6379, 27017, 9200), databases in public subnets, unnecessary open egress, missing WAF on internet-facing endpoints.
• Storage & Data — public S3 ACLs/policies, encryption-at-rest disabled (S3/EBS/RDS/DynamoDB), versioning/logging off on sensitive buckets, public snapshots.
• Compute & Containers — privileged containers, running as root, no readOnlyRootFilesystem, hostNetwork/hostPID/hostIPC, the Docker socket mounted in, missing resource limits.
• Secrets & Encryption — plaintext secrets in variables/env/ConfigMaps, missing TLS, wildcard KMS key policies.
• Logging & Monitoring — CloudTrail/Config/VPC Flow Logs disabled, missing log retention or encryption.
• Supply chain — images on :latest or from untrusted registries, Terraform modules from unpinned git/HTTP sources.

For each candidate, the deciding question is the mental model: what is the exposure, and what is the blast radius? That is what turns a raw pattern match into a rated finding.

Phase 3 — Report and remediate

For every confirmed finding, produce:

• Severity (P0–P3, see references/severity-rubric.md)
• Resource and file:line
• Current code — the verbatim bad snippet
• Fixed code — the corrected snippet (patterns in references/remediation-playbook.md)
• Rationale — the exposure and blast radius, in one or two sentences
• Compliance mapping — SOC-2 / PCI-DSS / ISO-27001 control IDs where applicable
• Effort — Quick Fix / Moderate / Complex

Assemble these into the report in references/report-template.md. Default save path: ./infra-audit-report-<timestamp>.md.

Finding format

When reporting inline (not the full document), use this structure. Group by severity, P0 first.

[P0] network-ssh-world-open in infra/sg.tf:24
  aws_security_group.web allows 0.0.0.0/0 to port 22. Any host on the
  internet can reach SSH; combined with the public subnet on this SG,
  the blast radius is full shell access to the instance.

  Current:
    ingress {
      from_port   = 22
      to_port     = 22
      cidr_blocks = ["0.0.0.0/0"]
    }

  Fix (scope to the bastion / VPN CIDR, or use SSM Session Manager):
    ingress {
      from_port   = 22
      to_port     = 22
      cidr_blocks = [var.admin_cidr]   # e.g. ["10.0.0.0/16"]
    }

If the user pastes a snippet without a path, refer to "the resource" and use line numbers within the snippet. Always name the exposure and the blast radius — that pair is the justification for the severity.

Severity scale

Summary only — full criteria, the deployment risk rating, and the effort scale are in references/severity-rubric.md.

• P0 Critical — exploitable now from the internet with high blast radius: unauthenticated data exposure or infrastructure takeover. Blocks deployment.
• P1 High — privilege escalation, lateral movement, or significant data exposure (often one precondition away from P0). Requires owner review before merge.
• P2 Medium — defense-in-depth gap; exploitable under specific conditions. Tracked as tech debt.
• P3 Low — best-practice deviation or compliance gap with no direct exploit.
• Informational — architectural recommendation or documentation note; no security impact on its own.

When it looks clean

After walking all categories, if nothing fires:

1. Say so explicitly. "No findings against the standard control set."
2. Note what was not checked: live cloud state and drift (the deployed resource may differ from this IaC), evaluated IAM permissions (the scanner reads policy documents, not the effective access graph), runtime container behavior, secrets injected outside the IaC, and anything in modules/charts not present in the scanned tree.
3. Recommend the user confirm against the deployed environment — a clean IaC read does not prove the running infrastructure is safe.

Safety and guardrails

1. Read-only against files. Never run terraform apply/plan -out, kubectl apply, helm install, aws cloudformation deploy, or docker build/run to "validate" a finding. This skill reasons about the IaC text, nothing more.
2. No credentialed access. Do not read ~/.aws/credentials, ~/.kube/config, environment secrets, or call any cloud API to confirm a finding.
3. Deterministic rules first. Severity decisions trace back to references/controls.md. Model judgment is for blast radius, false-positive suppression, and rationale — not for inventing rules.
4. False-positive reduction. Flag a finding only when the bad pattern is present and no compensating control is visible in the same scope (e.g. an explicit aws_s3_bucket_public_access_block, a default that sets encryption, a WAF in front of the open port). When a compensating control might exist outside the scanned tree, note the assumption.
5. Redact secrets. If the IaC contains live secrets, redact them in the report rather than echoing them.

Trigger phrases

Audit this Terraform for security issues: <dir>
Review these Kubernetes manifests before deploy: <dir>
Check this CloudFormation for public S3 buckets: <file>
Is this security group open to the internet?
Is this container running as root / privileged?
Pre-deployment security review of this IaC: <dir>
What's the blast radius if this Terraform is wrong?

Reference files

• references/controls.md — the control catalog: every rule with a stable id, category, severity, the bad and good pattern, and SOC-2/PCI-DSS/ISO-27001 mapping. Read it during Phase 2 to know what to check and how to rate it.
• references/severity-rubric.md — the P0–P3 + Informational definitions, how to choose between adjacent levels, the deployment risk rating, and the effort scale. Read it when scoring.
• references/remediation-playbook.md — bad→good fixes for the most common misconfigurations, each with a rationale and the looks-right-but-isn't pitfall. Read it when writing the fix, not just naming the gap.
• references/report-template.md — the structure of the output audit report. Read it when assembling the final document.

What this skill won't do

• It won't run terraform apply, kubectl apply, or deploy anything, and it won't read cloud credentials. The audit is the model reading the IaC plus a stdlib scanner.
• It won't require pip install, Docker, or network access. The scanner is standard-library only; if a format needs a real parser to disambiguate, the model reads the file directly.
• It won't rate a finding on the literal pattern alone — severity comes from exposure and blast radius, so the same pattern can land anywhere from P0 to P3.
• It won't replace a runtime posture tool (CSPM) or a live IAM access analyzer. It checks the IaC before it ships; it cannot see drift or the effective permission graph of the deployed account.
• It won't claim "secure" — only "no findings against this control set, and here is what a file read cannot cover."