Security as Code

Security as Code means defining, deploying, and managing security controls through code rather than manual configuration. It brings the benefits of software engineering (version control, testing, CI/CD) to security.

What to Codify

• IAM Policies: version-controlled in Git, deployed via CI/CD
• SCPs: organization guardrails managed as code
• Security Group Rules: network access defined in CloudFormation/Terraform
• Config Rules: compliance checks as Lambda functions or CloudFormation Guard
• WAF Rules: web application firewall rules as code
• Detective Controls: GuardDuty custom threat lists, EventBridge rules for automation

Benefits

• Reproducibility: identical security posture across all environments
• Auditability: Git history shows who changed what and when
• Testability: validate security policies in CI before deployment
• Speed: security controls deploy alongside application code
• Drift Detection: Config/CloudFormation detect when reality diverges from code

How It Goes Wrong in Practice

The most common failure is the console backdoor, usually called click-ops. The team manages everything in Terraform or CloudFormation, then an incident happens at 2 a.m. and someone opens a security group by hand to restore service. The change works, the incident closes, and the manual edit is never backported into code. Now there are two sources of truth: the next pipeline run either silently reverts a change someone depends on, or the drifted rule lives on invisible to every code review and security scan. Both outcomes are bad, and the second is worse because it is quiet. The discipline that fixes it is mechanical: emergency manual changes are allowed, but each one opens a ticket, gets backported within a defined window, and drift detection runs continuously so unbackported changes surface on their own instead of during an audit.

The second failure is secrets in the code path. Security-as-code repositories and their artifacts (Terraform state files in particular, which record resource attributes in plaintext) are a natural place for database passwords and API keys to accumulate. A repo that defines your security controls but leaks your credentials is a net negative. Keep secrets in Secrets Manager or SSM Parameter Store, reference them at deploy time, and scan the repositories and state storage as hostile inputs.

Third, the pipeline itself becomes the crown jewels. A deployment role powerful enough to create IAM policies and SCPs is a privilege-escalation target: whoever can merge to the repo or modify the pipeline effectively holds those permissions. Protect the pipeline with mandatory reviews, restricted iam:PassRole, and separate roles per pipeline stage.

A Practical Check

Validation belongs in CI, before anything reaches an account. IAM Access Analyzer will lint a policy document and return findings you can fail the build on:

aws accessanalyzer validate-policy --policy-document file://policy.json --policy-type IDENTITY_POLICY

The --policy-type value also accepts RESOURCE_POLICY, SERVICE_CONTROL_POLICY, and RESOURCE_CONTROL_POLICY, so the same gate covers bucket policies and organization guardrails. Wire it as a pipeline step: render the policy from your IaC, validate, and block the merge on errors and security warnings. It is one command and it catches an embarrassing share of policy bugs before they ship.

Frequently Asked Questions

Which AWS-native tools support security as code? CloudFormation and CDK (or Terraform) carry the infrastructure definitions; CloudFormation Guard expresses policy-as-code rules against templates; IAM Access Analyzer validates policy documents in CI; AWS Config rules and conformance packs verify the deployed reality continuously; and EventBridge rules codify the automated responses. The pattern is the same at every layer: the control is text, the text is reviewed, and a machine checks it twice, once before deploy and once after.

If everything is code, do I still need drift detection? Emphatically yes. Code defines intent; drift detection verifies reality. Consoles, SDKs, break-glass access, and other tools can all mutate resources outside the pipeline, so the codebase alone proves nothing about the live environment. Config rules and CloudFormation drift detection are what close that loop, and their findings are your earliest warning that the click-ops backdoor is in use.

How should emergency manual changes be handled? Design the exception path instead of pretending it will not happen. A break-glass role with strong authentication and full session logging makes the emergency change possible and attributable; a standing rule that every manual change gets backported to code within a fixed window keeps the repository truthful; and drift detection acts as the enforcement mechanism for that rule. Teams that forbid manual changes without designing this path do not eliminate them, they just stop hearing about them.