Source code now functions as infrastructure, not just intellectual property

At a glance

What this is: This analysis argues that source code should be treated as infrastructure because repository access can expose secrets, alter deployments, and compromise downstream trust.

Why it matters: IAM, PAM, and NHI teams need to govern developer and pipeline identities as production control points because code repositories now influence infrastructure, signing, and release integrity.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read ClearVector's analysis of why source code now acts as infrastructure

Context

Source code has become part of the control plane for modern infrastructure, especially where infrastructure as code defines networks, servers, databases, and identity policy. That means a repository compromise is no longer just an intellectual property loss, it can become a direct path into production change control and release integrity.

In identity terms, developer accounts, repository credentials, signing keys, and CI/CD tokens behave like high-value non-human identities because they can shape runtime outcomes without ever logging into a production server. The governance gap is not just code theft, it is the assumption that repository access is still separate from infrastructure authority.

ClearVector uses the Microsoft Midnight Blizzard incident and the later F5 source-code theft to show how adversaries value repositories as leverage points. The starting position is no longer atypical for software-led organisations, it is increasingly the default risk surface.

Key questions

Q: How should security teams govern developer identities in the SDLC?

A: Security teams should treat developer identities as privileged non-human and human access paths inside the delivery pipeline. That means using verified identities for repository writes, restricting branch access, logging every change, and reviewing who can approve builds or signing operations. The goal is to make code provenance traceable from commit to release.

Q: Why do source repositories create outsized identity risk in IaC environments?

A: Because repository content can define infrastructure, policy, and deployment behaviour. A compromise can therefore expose secrets or alter runtime configuration without direct access to production servers. When infrastructure is encoded in code, the repository becomes part of the control plane and must be governed accordingly.

Q: What breaks when secrets are left inside generated code?

A: Hardcoded secrets turn code into a credential repository, which expands exposure through source control, logs, build systems, and copied templates. Once a secret is embedded, rotation becomes harder and discovery often lags compromise. The better model is runtime retrieval from a managed secret store with scoped access.

Q: How do security teams reduce supply chain impact from compromised code access?

A: They should enforce identity attribution across repository, CI/CD, and signing systems so suspicious changes can be isolated before release completion. The goal is to break the chain between commit, build, and trust inheritance. That requires monitoring, separation of duties, and rapid revocation of the compromised identity.

Technical breakdown

Source code as infrastructure in IaC environments

Infrastructure as code turns repository content into operational authority. Templates, policy files, deployment manifests, and configuration logic can create networks, workloads, permissions, and trust relationships at build time or deployment time. When that code is controlled through versioning and automated delivery, the repository becomes more than storage. It becomes an execution path that can shape production behaviour without direct console access. That is why source code compromise has a governance impact similar to control-plane compromise, especially when identity policy itself is encoded in code.

Practical implication: treat repositories that define infrastructure as production systems and apply stronger access, review, and audit controls than standard development code.

Why secrets in source code expand attacker leverage

Source repositories often contain hardcoded credentials, API keys, certificates, and trust links that were meant to be temporary but became durable. Once exposed, those secrets can enable access to cloud services, internal APIs, signing services, or third-party platforms. Even when the code itself is not modified, the presence of embedded secrets turns one compromise into a broader identity problem. Attackers do not need to brute-force the environment if the repository already contains reusable trust material.

Practical implication: find and eliminate embedded secrets before they become reusable access paths across infrastructure and delivery pipelines.

Developer identity and CI/CD trust chains

Developer identity is a high-leverage identity because it can authenticate to the repository, influence code review, trigger pipelines, and inherit signing or deployment authority. In many environments, the same identity path can reach source control, build systems, and release automation. That creates a trust chain in which a single compromised account can change code, package it, and distribute it under normal operational trust. The risk increases when repository activity, build actions, and signing events are not correlated back to the originating identity in real time.

Practical implication: correlate developer actions across source control, CI/CD, and signing so anomalous repository activity can be isolated before release.

Threat narrative

Attacker objective: The attacker wants durable leverage over infrastructure and release trust by using source code access as a path into production and the supply chain.

1. Entry occurs through compromise of a developer or test tenant identity, which gives the attacker access to source control rather than production infrastructure directly.
2. Escalation happens when repository access reveals hardcoded secrets, trust relationships, or the ability to modify code that later flows through CI/CD and signing.
3. Impact is achieved when altered or exposed source code is used to enable lateral movement, deploy backdoors, or weaponise trusted releases downstream.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Source code has become an identity-governed control surface, not just developer output. When code defines infrastructure, the repository becomes a place where access decisions turn into operational change. That collapses the old boundary between development and production, and it means identity governance must extend into source control, build, and signing workflows. Practitioners should treat repository authority as infrastructure authority.

Developer identity is the leverage point because it links code, pipeline, and release trust. The article correctly shows that attackers do not need a production login when they can influence the repository that builds production. That makes developer identity a high-impact non-human-adjacent control point even when a human owns the account. The practical conclusion is that access paths must be correlated across source control, CI/CD, and signing.

Secrets in source code create trust debt that outlives the original commit. Hardcoded credentials, certificates, and API keys turn a repository into a reusable access reservoir. That risk is not solved by code review alone because the problem is lifecycle persistence, not just malicious intent. The discipline needed here is repository-level secret governance tied to rotation and revocation.

AI compresses the time between repository compromise and supply chain impact. ClearVector is right that AI does not create the target, but it accelerates exploitation of it. Once code or credentials are exposed, AI can help map trust relationships, surface secrets, and draft plausible malicious changes faster than manual attacker workflows. That changes the meaning of incident response: identity attribution and rapid isolation now matter before a change reaches the pipeline.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• That governance gap is why OWASP NHI Top 10 and identity lifecycle controls now matter across code, pipeline, and runtime trust.

What this signals

Source code governance is now an identity programme problem. As repositories absorb infrastructure logic, the boundaries between IAM, PAM, and engineering controls get thinner. Teams should expect more audit pressure around who can change code, who can sign release artefacts, and which identities can move from development into production trust paths.

Trust-chain visibility is becoming the new control plane requirement. If you cannot correlate source control activity, pipeline execution, and signing events to a single identity record, you cannot reliably explain how a change reached production. That gap is exactly where stealthy repository abuse turns into downstream compromise.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, the same repository and pipeline governance weaknesses will be amplified as AI starts touching code and build systems. The control question is no longer whether identity can be managed, but whether the programme can see machine-mediated change before it ships.

For practitioners

• Classify repository access as infrastructure authority Map which source control accounts, tokens, and service identities can change production-relevant code, build artifacts, or signing inputs. Apply stronger approval, monitoring, and separation of duties to those identities than to ordinary developer access.
• Scan and revoke embedded secrets continuously Run secret discovery across active branches, tags, forks, and build logs, then rotate or revoke any credential exposed in code, comments, environment files, or pipeline variables before it can be reused.
• Correlate developer actions across the delivery chain Tie repository commits, pull requests, pipeline triggers, signing events, and deployment actions back to the originating identity so suspicious activity can be isolated before trusted release.
• Separate code review from release authority Require different identities for code approval, build execution, and signing where practical, so a single compromised developer identity cannot both modify and publish trusted software.
• Harden non-production tenants and test identities Treat test environments and legacy tenants as entry points into source control and corporate data. Enforce least privilege, MFA where applicable, and regular access review for every identity that can reach repositories or linked systems.

Key takeaways

• Source code now functions as infrastructure, so repository access must be governed as production authority.
• Secrets in code, developer identity, and CI/CD trust chains combine to create a broad supply chain blast radius.
• The control that matters most is identity attribution across the delivery pipeline before release trust is inherited.

Key terms

• Source code as infrastructure: 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.
• Developer Identity Assurance: Developer identity assurance is the practice of verifying that engineering actions come from the intended person on a trusted device with valid credentials. It matters because modern development depends on tokens, keys, and automation that can behave like non-human identities if left unmanaged.
• Trust Chain: The trust chain is the set of delegated relationships that lets one system, token, or integration act on behalf of another. In NHI security, it is often the real attack surface because compromise travels through legitimate permissions instead of obvious malware.
• Secrets in source code: Credentials, tokens, keys, or certificates embedded in code, configuration, comments, or build artefacts. Once exposed, they often remain reusable beyond the original context, creating a lifecycle problem that requires discovery, rotation, and revocation rather than simple code cleanup.

What's in the full article

ClearVector's full blog covers the operational detail this post intentionally leaves for the source:

• The Microsoft Midnight Blizzard and F5 source-code theft references in more detail, including the specific attacker behaviour described by ClearVector.
• The repository and CI/CD trust-chain examples that show how code changes can inherit production credibility.
• ClearVector's argument for treating source code as infrastructure across developer identity, secrets, and release governance.
• The source article's full discussion of AI as an accelerant for code analysis and malicious modification.

👉 ClearVector's full post covers the repository compromise path, CI/CD trust chain, and AI-driven supply chain risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.