Find real ATTACK PATHS in Infrastructure-as-Code (Terraform, CloudFormation, Kubernetes) — not a linter. Give it your IaC files (a map of filename→content, or a single source blob) and it parses them into a resource graph, resolves cross-resource relationships, and searches for chains from the public INTERNET to your crown jewels (data stores, secrets, admin). It returns a BREACHABLE / EXPOSED / HARDENED verdict and the concrete multi-hop routes an attacker would walk — e.g. 'open security group (SSH 0.0.0.0/0) → EC2 instance-profile role → iam:PassRole privilege escalation to admin → S3 exfiltration'. Understands AWS managed-policy permissions, 20+ IAM privilege-escalation primitives, public security groups / RDS, and Kubernetes LoadBalancer/NodePort exposure + privileged pods + cluster-admin ServiceAccounts. Use it before applying IaC or in a PR to catch breach paths a per-resource linter misses. Heuristic static analysis of declared IaC.

DIFFERENTIAL attack-path analysis for a change to Infrastructure-as-Code — the CI/CD gate. Give it the IaC BEFORE and AFTER a change (e.g. a pull request's base and head trees, each a map of filename→content) and it builds the full resource graph + runs the internet→crown-jewel reachability search on BOTH states, then reports exactly what the change did to your attack surface: which breach chains it INTRODUCES (e.g. 'this PR opens a NEW Internet→admin route via a newly-public security group + an over-broad IAM grant'), which it ELIMINATES, and which it AGGRAVATES (makes more exploitable). Returns an INTRODUCES_BREACH / REDUCES_RISK / NEUTRAL / MIXED verdict — the single check to wire into PR review so a change that opens a path to your data/secrets/admin is caught before merge. This is something a per-file linter or a single-state scan cannot answer: it needs both graphs and a semantic cross-state path match. Heuristic static analysis of declared IaC.