Cloud security still feels heavily deploy → detect → respond, so I wanted to try flipping the workflow.
You connect an AWS account, Emfirge pulls infrastructure state across 18+ AWS services and builds a topology graph: SG → EC2 → IAM Role → S3 → RDS etc.
Then i keep two copies, One is real state and the other is Clone for mutations like staging environment for your security posture.
When you open a tf Pr I parse the diff, apply it to the clone and rebuild the graph, run BfS from internet. New path from internet to your database? Kinda this shows up in the PR comment before merge.
Same for simulation add any component of cloud and mutate on the actual Infrastructure.
Example:
If a change introduces a new internet → database path, it shows up during PR validation before merge.
Then I introduced 3 phases all powered by the same graph:
NOW
Current attack paths, blast radius, infra exposure, breach simulation
WHAT IF
Add/mutate cloud components and simulate security consequences before deployment
TIMELINE
Infrastructure drift, posture changes, and historical attack-path evolution over time
Still very early and exploring the direction. Curious what cloud/devops/security engineers think about infrastructure consequence simulation becoming part of CI/CD workflows.
Top comments (0)