A governance model in which repository content directly defines or materially shapes runtime environments, deployment behavior, and trust relationships. In this model, source control is not only development tooling but a control surface that can alter production if identity and pipeline access are compromised.
Expanded Definition
Source code as infrastructure describes a governance model where repository contents do more than document how systems are built. They can directly shape runtime configuration, deployment paths, trust boundaries, and access control decisions. In NHI and IAM practice, that makes the repository a control surface, not just a development asset.
The term overlaps with infrastructure as code and policy as code, but it is broader in one important way: code may define what is deployed, who can approve it, which identities are created, and how secrets or certificates are consumed at runtime. Definitions vary across vendors, and no single standard governs this yet, so the practical meaning depends on how much operational authority a repository has. NIST’s Cybersecurity Framework 2.0 is relevant because it frames governance, access control, and change management as security functions rather than purely engineering choices.
The most common misapplication is treating repository access like ordinary developer collaboration, which occurs when privileged merge rights can alter production-facing identities, secrets, or deployment rules without separate approval.
Examples and Use Cases
Implementing source code as infrastructure rigorously often introduces approval and traceability overhead, requiring organisations to weigh deployment speed against the risk that a single commit can alter production trust relationships.
- A Git repository defines Kubernetes manifests, ingress rules, and service account bindings, so a pull request can create or widen access if merged by the wrong identity.
- Pipeline code stores deployment logic and secret references, making CI/CD compromise a direct path to runtime control, as seen in cases like the CrewAI GitHub Token Leak.
- Infrastructure definitions include certificate issuance, rotation triggers, and environment-specific trust settings, which means code review must cover identity effects as well as functional changes.
- Repository history becomes an audit trail for operational authority, so teams can reconstruct who approved changes that affected production access or secrets handling.
- Access to source repositories is restricted with stronger controls, informed by the same governance concerns highlighted in the Ultimate Guide to NHIs, while patterns like the Twitter Source Code Breach show how source exposure can become infrastructure exposure.
Practitioners often pair these controls with deployment safeguards described in the NIST Cybersecurity Framework 2.0 so repository changes cannot bypass review, logging, or least privilege.
Why It Matters in NHI Security
When source code governs infrastructure, compromise of the repository can become compromise of identities, secrets, and runtime trust. That is especially dangerous for NHI because service accounts, API keys, CI/CD tokens, and workload identities are often instantiated or referenced directly from code. NHIMG research shows that 30.9% of organisations store long-term credentials directly in code, and 96% store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes repository hygiene a first-order security issue rather than a developer preference.
This is why source code as infrastructure must be managed as part of security architecture. Attackers who gain repository write access can inject hidden permissions, redirect deployments, or rebind secrets to malicious targets. The risk is amplified when merge approval is weak, branch protection is inconsistent, or pipeline identities are over-privileged. The governance lesson from incidents such as the Slack GitHub Breach is that source systems and production systems are often separated in theory but tightly coupled in practice. The most relevant identity boundary may not be the server, but the commit that controls it.
Organisations typically encounter this problem only after a poisoned pipeline, leaked token, or unauthorised merge has already changed production, at which point source code as infrastructure becomes operationally unavoidable to address.
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, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling risks when code directly references credentials and tokens. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and least privilege govern who can change infrastructure-defining code. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification even for identities that can modify deployment logic. | |
| CSA MAESTRO | Agentic and automated workflows need explicit governance when source drives runtime behavior. | |
| OWASP Agentic AI Top 10 | Agent workflows often use repositories and pipelines as execution pathways into production. |
Restrict repository and pipeline privileges so code changes cannot silently alter production trust.
