Why checking your infrastructure-as-code for misconfigurations is not enough – How ...
summary
Claims that scanning infrastructure-as-code for misconfigurations alone misses architectural risk, and that keyword-based rule engines (Terraform/terraform modules, AWS checks) catch flags but not emergent design failures. Cites 60,000 exposed DoD files and 136 GB exposed for 300,000 customers as motivation, notes typical deployments span 10,000–50,000 lines of IaC and thousands of resources, and shows a demo pattern: map ELB → S3 logs → serverless ingestion (Splunk) to reveal permissions, KMS/DynamoDB choices, and why security as code plus visualization and threat modeling must run alongside linting.
AI-written summary · about
chapters (12)
- 0:00Intro
- 2:16Software & Infrastructure Delivery PAST
- 2:43Modern Infrastructure Development
- 5:35Cloud Native Applications Today
- 10:48Trends in Modern Software Development
- 16:47Complex Systems and Emergent Properties
- 17:59Security is an emergent property
- 19:12Types of Emergence
- 26:26Limitations of Misconfiguration checking
- 29:04Addressing Cloud-Native Security
- 43:39Loadbalancer. Logging
- 45:36Managed Inspection Points for Database Interactions
related talks
36mInfrastructure as Code Done Right: Discovering and Fixing Common Missteps
18mInfrastructure as Code Security Best Practices & Strats
05mAvoiding IaC misconfiguration (on multiple platforms)
21mPitfalls of Infrastructure as Code (And how to avoid them!)
37mStatic Code Analysis of Terraform based Infrastructure as Code IaC scripts
26mStandard Classification: Introducing graph theory to Policy-As-Code
33mSecurity scans for terraform templates
22mSecurity vs Dev Experience Threat … or Opportunity