Skip to main content
Application Security Standards
Category: DevSecOps

Security as Code

Also known as: SaC, Security-as-Code
Simply put

Security as Code is an approach where security policies, controls, and procedures are written and managed as code rather than applied manually after software is built. This means security checks and requirements are embedded directly into the development process and automated tooling. The goal is to make security a consistent, repeatable part of how software is built and delivered.

Formal definition

Security as Code (SaC) is a software development discipline in which security policies, controls, procedures, and compliance requirements are codified and version-controlled alongside application and infrastructure code, enabling automated enforcement throughout the software development lifecycle. SaC integrates security protocols directly into DevOps tools, pipelines, and workflows, typically through automated scanning, policy-as-code enforcement, and infrastructure security configuration, so that security measures are applied consistently at each stage of development rather than as a manual, post-development activity. SaC is a foundational building block of DevSecOps, mapping security requirements to code and infrastructure changes to ensure that key practices are enforced programmatically across all components of the software delivery process.

Why it matters

Manual security reviews applied after software is built create predictable gaps: controls are inconsistently applied, findings arrive too late to be fixed cheaply, and the same classes of vulnerability recur across releases because there is no programmatic enforcement preventing them. As development cycles have accelerated through CI/CD adoption, the window available for manual security gates has narrowed to the point where post-deployment remediation has become the norm rather than the exception for many teams. Security as Code addresses this by making security enforcement a structural property of the pipeline rather than a scheduled activity.

The consistency benefit is significant beyond speed. When security controls are written as code and version-controlled alongside application and infrastructure code, every change to those controls is auditable, reviewable, and testable. Teams can trace when a policy was introduced, who approved it, and whether it was enforced during a given build. This auditability is particularly relevant for compliance requirements, where demonstrating continuous enforcement is typically more defensible than point-in-time audit evidence.

Securing the software supply chain has raised the stakes for pipeline integrity specifically. Automated, codified controls that govern how dependencies are ingested, how builds are executed, and how artifacts are promoted through environments reduce the surface area available to attackers who target the build and delivery process itself. Without codified enforcement at these stages, individual human reviewers become the primary control, and human controls do not scale consistently across large engineering organizations.

Who it's relevant to

Security Engineers and AppSec Teams
Security as Code shifts the security team's role from manual reviewer to policy author and tooling maintainer. Rather than reviewing individual pull requests for security issues, security engineers codify the controls they care about and deploy them as automated checks that run at scale across the engineering organization. This requires skills in scripting, pipeline configuration, and policy languages alongside traditional security knowledge.
DevOps and Platform Engineers
Platform engineers who own the CI/CD pipeline and infrastructure tooling are often the primary implementers of Security as Code in practice. Integrating scanning tools, policy enforcement gates, and secrets detection into shared pipeline templates requires understanding both the delivery infrastructure and how security controls interact with build performance and developer workflow.
Software Developers
Developers interact with Security as Code through the feedback it produces during their normal workflow. Codified security checks that surface findings at pull request time give developers actionable security feedback in the context where they are already working, rather than through a separate process. Developers benefit from understanding how the controls are configured so they can interpret findings accurately and avoid both ignoring real issues and being blocked by false positives.
Compliance and Risk Professionals
For teams operating under regulatory frameworks, Security as Code provides evidence of continuous control enforcement rather than periodic attestation. Compliance requirements that call for documented, auditable security processes can typically be addressed more efficiently when controls are version-controlled and their execution is logged by the pipeline, supporting audit workflows without requiring separate manual documentation efforts.
Engineering Leadership and CISOs
Security as Code is relevant to engineering and security leadership as a mechanism for scaling security coverage without scaling headcount proportionally. When security controls are codified and applied automatically across all teams using a shared pipeline, leadership gains consistent visibility into policy adherence and can demonstrate that security requirements are enforced programmatically rather than depending on individual reviewer judgment.

Inside SaC

Security Policy Definitions
Formal, machine-readable expressions of security requirements and rules, such as allowed network traffic, permitted configurations, and access control constraints, stored in version-controlled files.
Infrastructure as Code Security Controls
Security configurations embedded directly within infrastructure provisioning templates (such as Terraform or CloudFormation), ensuring that resources are deployed with required security settings from the outset.
Automated Security Tests
Scripts and test suites that encode security acceptance criteria and are executed within CI/CD pipelines to validate that code and infrastructure changes do not introduce regressions in security posture.
Compliance Controls as Code
Machine-readable representations of regulatory or organizational compliance requirements, enabling automated checking of whether systems and configurations satisfy those requirements.
Secrets and Credential Management Configurations
Code-defined integrations with secrets management systems that govern how credentials, keys, and sensitive values are accessed, rotated, and scoped, rather than hardcoded or manually managed.
Threat Model Artifacts
Structured, versioned documents or data files representing threat models for applications or systems, enabling threat modeling outputs to be reviewed, tracked, and updated alongside code changes.
Pipeline Security Gates
Declarative or scripted checkpoints within CI/CD pipelines that enforce security requirements, such as blocking deployments when vulnerabilities exceed a defined severity threshold or when policy violations are detected.

Common questions

Answers to the questions practitioners most commonly ask about SaC.

Is Security as Code just another term for DevSecOps?
No. Security as Code is a practice within the broader DevSecOps philosophy, not a synonym for it. DevSecOps describes a cultural and organizational shift that integrates security responsibilities across development and operations teams throughout the software lifecycle. Security as Code is a specific technical implementation approach within that culture, focused on expressing security controls, policies, and configurations as versioned, machine-readable artifacts. DevSecOps can exist without Security as Code, and Security as Code artifacts can be written without a mature DevSecOps culture, though the two reinforce each other when combined.
Does adopting Security as Code mean security is fully automated and requires no human review?
No. Security as Code automates the enforcement and verification of controls that have already been defined and codified, but it does not replace human judgment in threat modeling, policy design, or the evaluation of novel risks. Automated pipelines can enforce known policy rules and flag deviations, but decisions about what policies to write, how to handle exceptions, and how to respond to ambiguous findings still require human expertise. Security as Code shifts human effort toward policy definition and exception review rather than eliminating human involvement.
How should an organization prioritize which security controls to codify first?
Organizations typically begin by codifying controls that are frequently applied, error-prone when performed manually, or required by compliance frameworks. Common starting points include infrastructure hardening baselines, secrets management policies, and network access rules. Controls that are already documented in runbooks or checklists are generally good candidates for early codification because the policy intent is already defined and the work involves translation rather than design. High-risk or high-frequency controls tend to deliver the most immediate value from automation.
What tooling is typically required to implement Security as Code in a CI/CD pipeline?
A practical Security as Code implementation in a CI/CD pipeline typically involves a combination of policy-as-code engines (such as Open Policy Agent or HashiCorp Sentinel), infrastructure-as-code tools (such as Terraform or Pulumi), static analysis tools for scanning codified policies and infrastructure templates, secrets management systems, and pipeline orchestration platforms that can enforce gates based on policy evaluation results. The specific toolchain varies by environment, cloud provider, and organizational standards. Integration points between these tools require careful design to avoid gaps in coverage or inconsistent enforcement across environments.
How is Security as Code tested and validated before deployment?
Security as Code artifacts are typically tested using unit tests for individual policy rules, integration tests that evaluate policies against representative resource configurations, and pipeline-level tests that verify enforcement behavior in staging environments. Policy unit tests check that a given rule produces the expected allow or deny outcome for known inputs. Integration tests may use synthetic or anonymized production configurations to surface edge cases. Some organizations also employ mutation testing techniques to verify that policy logic is not trivially bypassed. Like application code, security policy code benefits from peer review and version-controlled change history.
What are the most common failure modes when organizations first adopt Security as Code?
Common failure modes include writing policies that are too broad or too permissive due to pressure to avoid blocking deployments, resulting in controls that exist in code but do not meaningfully restrict risk. Organizations also frequently encounter drift between codified policies and the actual runtime state of environments when enforcement is inconsistent or applied only at initial provisioning. Another common issue is treating Security as Code tooling as a substitute for understanding the underlying security requirements, which leads to policies that are syntactically valid but logically incorrect. Insufficient testing of policy logic, particularly for edge cases, is also a recurring problem.

Common misconceptions

Security as Code means simply running security scanning tools in a CI/CD pipeline.
Running scanners in a pipeline is one component, but Security as Code encompasses a broader practice of expressing security policies, controls, compliance requirements, and tests as versioned, auditable, and peer-reviewed code artifacts that are systematically maintained alongside application and infrastructure code.
Adopting Security as Code eliminates the need for human security expertise or review.
Security as Code automates enforcement and consistency, but the quality of the security controls depends on the expertise used to define them. Human review of policy definitions, threat model artifacts, and control logic remains necessary to ensure the codified rules are correct, complete within their scope, and appropriate for the context.
Security as Code provides complete security coverage because everything is automated.
Security as Code typically covers controls that can be expressed and evaluated statically or through automated testing. Certain classes of issues, such as complex business logic vulnerabilities or runtime-only behaviors, may require additional testing approaches beyond what automated code-based controls can detect.

Best practices

Store all security policy definitions, control configurations, and automated security tests in the same version control system used for application and infrastructure code, and require peer review for changes through pull or merge request workflows.
Treat security control code with the same software quality standards applied to application code, including linting, testing, and documentation, to reduce the risk of misconfigured or ineffective controls being silently deployed.
Define explicit, documented scope boundaries for each codified security control, specifying what categories of issues it is designed to detect or enforce and what categories fall outside its scope, to prevent false confidence.
Integrate pipeline security gates with clearly defined, versioned threshold policies so that enforcement criteria are transparent, auditable, and updated through the same review process as other security artifacts.
Regularly audit and update codified compliance controls and security tests to reflect changes in regulatory requirements, threat landscape shifts, and evolving organizational policies, treating them as living artifacts rather than static configurations.
Pair Security as Code practices with runtime monitoring and manual security review processes, acknowledging that static and pipeline-based controls address a subset of the overall security risk surface.