The practice of expressing policy checks, validation, and control evidence as repeatable code within delivery pipelines. It helps teams make security measurable and consistent rather than dependent on manual interpretation.
Expanded Definition
Security as code is the practice of encoding policy checks, control logic, and evidence collection into versioned, repeatable artifacts that run alongside software delivery. In NHI and IAM programs, this usually means defining guardrails for secrets handling, identity permissions, attestations, and deployment approvals as executable rules rather than one-time review tasks.
Its value is strongest when security requirements need to be enforced at machine speed across pipelines, infrastructure, and agent workflows. That makes it closely related to policy as code, but not identical. Policy as code often focuses on declarative rules, while security as code includes the broader operational pattern of testing, enforcing, and recording security outcomes in the delivery process. The idea aligns well with the NIST Cybersecurity Framework 2.0 emphasis on repeatable governance and risk treatment. Definitions vary across vendors, especially where platform teams bundle security scanning, runtime controls, and audit evidence into the same workflow.
The most common misapplication is treating security as code as a scanning add-on, which occurs when teams write checks but fail to wire them into enforcement and evidence retention.
Examples and Use Cases
Implementing security as code rigorously often introduces pipeline complexity and maintenance overhead, requiring organisations to weigh faster, more consistent control enforcement against the cost of keeping rules current.
- Pipeline rules block deployment when a service account is granted broad permissions without an approved exception, turning least privilege into an automated gate.
- Infrastructure templates fail builds if secrets are committed in code or passed into CI/CD variables without approved vault integration, reducing credential exposure.
- Control evidence is generated automatically during releases, so audit teams can review who approved a change, what policy was checked, and whether the check passed.
- Runtime admission controls verify that an AI agent or workload can only use approved identities and tools before it reaches production.
- Security teams codify rotation and expiry expectations for API keys so drift is detected before long-lived credentials become an incident.
These patterns matter because NHIs are often managed inconsistently across teams. NHI Mgmt Group research shows that 30.9% of organisations store long-term credentials directly in code, and the Ultimate Guide to NHIs notes that 96% store secrets outside secrets managers in vulnerable locations. For implementation guidance, teams often map these checks to the NIST Cybersecurity Framework 2.0 outcomes so policy logic can be traced to a broader risk model.
Why It Matters in NHI Security
Security as code matters because NHIs and agentic systems change too quickly for manual review alone. If policy is encoded and versioned, organisations can detect misconfigurations before they become dormant privileges, leaked tokens, or unapproved machine-to-machine access. This is especially important where secrets, certificates, and service accounts are created by automation and then reused across multiple environments. NHI Mgmt Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes control consistency a practical requirement rather than a process preference.
It also supports better accountability. When security requirements are expressed as code, teams can test them in pull requests, review them like application logic, and preserve evidence for audit and incident response. That pattern aligns with governance models described in the Ultimate Guide to NHIs, especially around lifecycle control, rotation, and visibility. Organisations typically encounter the need for security as code only after a secrets leak, an over-privileged deployment, or a failed audit exposes that manual controls were never enforceable at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO | Security as code operationalises policy and governance into repeatable technical checks. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Secrets and credential controls are a core use case for code-driven enforcement. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agent tool access and runtime guardrails fit security-as-code enforcement patterns. |
| NIST AI RMF | Map | AI risk management calls for repeatable controls, testing, and traceable evidence. |
| NIST Zero Trust (SP 800-207) | PA | Zero Trust requires policy enforcement that can be automated and continuously verified. |
Translate AI and automation risk checks into versioned controls with measurable outcomes.
