Practice : Security as Code
Purpose and Strategic Importance
Security as Code embeds security practices, policies, and controls directly into source code, infrastructure definitions, and automation pipelines. It transforms security from a gatekeeper function into a collaborative, scalable, and proactive engineering discipline.
This approach enables faster development, consistent enforcement, and early detection of risks - reducing vulnerabilities, ensuring compliance, and building trust with customers and stakeholders.
Description of the Practice
- Policies, validations, and configurations are defined in code - version-controlled, testable, and reviewable.
- Security checks run automatically in CI/CD pipelines and infrastructure provisioning tools.
- Tools include Open Policy Agent (OPA), HashiCorp Sentinel, Checkov, TFSec, and custom linters or compliance scripts.
- Common examples: enforcing encryption, validating access controls, scanning IaC, verifying API security headers, or checking dependencies.
How to Practise It (Playbook)
1. Getting Started
- Identify repeatable security checks that can be automated (e.g. IAM misconfigurations, open ports, dependency vulnerabilities).
- Choose tools that fit your stack and integrate into your developer workflow.
- Write policy rules as code and test them against your current infrastructure or codebase.
- Include basic static security scans in your CI pipelines (e.g. secrets detection, SAST).
2. Scaling and Maturing
- Adopt policy-as-code platforms for fine-grained access, compliance, and environment-specific enforcement.
- Treat security findings like any other defect - triaged, prioritised, and fixed by development teams.
- Define tiered enforcement: warn in dev, block in production.
- Pair automated checks with alerts, dashboards, and audit trails for visibility.
- Collaborate with security champions or embedded security engineers for continuous improvement.
3. Team Behaviours to Encourage
- View security as a shared responsibility - shift it left, embed it everywhere.
- Keep rules visible, explainable, and peer-reviewed.
- Promote experimentation - start with observation mode, then move to enforcement.
- Celebrate prevention - stopping issues before they reach production.
4. Watch Out For…
- Tool sprawl - too many disconnected scans or inconsistent policies.
- Blocking flows too early without developer buy-in or remediation support.
- Stale policies that no longer match system behaviour.
- Treating security findings as noise - they require triage and ownership.
5. Signals of Success
- Security issues are caught and resolved early in the development lifecycle.
- Policy enforcement is automated, consistent, and transparent.
- Teams write, maintain, and improve their own security controls.
- Risk posture improves without slowing down delivery.
- Security shifts from reactive to proactive, and from siloed to integrated.