• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

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.
Associated Standards
  • Policy enforcement is automated across environments
  • Operational tasks are automated before they become recurring toil
  • Product and engineering decisions are backed by live data
  • Developer workflows are fast and frictionless
  • Systems recover quickly and fail safely
Associated Measures
  • Compliance Coverage
  • Percentage of Services Scanned
  • Time to Remediate Vulnerabilities

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering