Source code now functions as infrastructure, not just intellectual property

At a glance

What this is: This analysis argues that source code has become infrastructure because repositories now define secrets, identity policy, and deployment paths that shape production outcomes.

Why it matters: It matters because IAM, PAM, and NHI governance now have to cover developer identities, repository access, and CI/CD trust paths, not just production systems.

Context

Source code now acts as a control plane for modern environments because infrastructure is increasingly defined in repositories rather than only in servers and networks. That changes the identity problem: access to code can translate directly into access to production behaviour, secrets, and deployment trust.

The governance gap is that many programmes still treat repositories as intellectual property stores instead of critical infrastructure assets. Once code contains identity access policies, hardcoded secrets, and build logic, compromise of the repository becomes a path to downstream operational control.

Key questions

Q: What breaks when source code repositories are treated like ordinary intellectual property stores?

A: The control boundary breaks. Repositories often contain infrastructure definitions, identity policy, secrets, and release logic, so treating them like passive IP storage misses the fact that a compromise can alter production behaviour and downstream trust. IAM teams need to govern repository access as infrastructure access, not as a low-risk collaboration function.

Q: Why does source code exposure increase lateral movement risk?

A: Source code exposure increases lateral movement risk because repositories often contain credentials that authenticate to cloud services, CI systems, databases, and package registries. Once attackers recover those secrets, they can move from the code layer into adjacent systems using valid access rather than noisy exploitation. The risk is amplified when the same credentials are reused across environments.

Q: How do security teams know whether repository governance is failing?

A: Look for secrets in commits, weak separation between contributor access and release authority, and changes to pipeline or signing logic that are not clearly owned and reviewed. Those are signs that the repository is functioning as an uncontrolled control plane rather than a governed asset.

Q: What should teams do if a developer identity can reach both source control and CI/CD signing paths?

A: They should treat that identity as a high-impact trust bridge and tighten approval, logging, and review around it before a compromise can move from code access to signed release output. The key risk is not the login itself, but the ability to convert repository access into trusted distribution.

Technical breakdown

Why repository compromise becomes infrastructure compromise

Infrastructure as code moves configuration, policy, and deployment logic into source repositories. That means the repository is no longer just a storage location for application code, but a source of truth for how systems are built and controlled. If an attacker gains persistent access to the repository, they can alter what is deployed, how it is deployed, and which identities or secrets are trusted in the pipeline. The security boundary shifts from the server to the codebase itself, which is why classic perimeter thinking misses the real control point.

Practical implication: Treat repository access as infrastructure access and govern it with the same rigor as production administrative access.

Why secrets in source code are still the highest-value exposure

Hardcoded credentials, API keys, and certificates turn code into a credential repository as well as an application repository. When those secrets are embedded in code, the attacker does not need to exploit a runtime weakness to move laterally or authenticate elsewhere. Source code also reveals trust relationships and business logic, which can expose paths that are hard to infer from external observation alone. The result is that a single repository breach can combine credential theft, architecture discovery, and supply-chain abuse in one incident path.

Practical implication: Scan for secrets continuously and assume any exposed credential in code can be reused before rotation catches up.

How trusted build pipelines turn code modification into downstream compromise

The most dangerous change is not theft but silent modification. If an adversary can alter source before review, the CI/CD pipeline can compile and sign malicious logic as if it were legitimate. That converts the repository into a trusted distribution mechanism, especially when builds and release signing inherit the organisation's own trust. In practical terms, the pipeline does not just move code forward; it propagates whatever identity and content controls were already missing upstream.

Practical implication: Verify repository integrity, commit provenance, and release signing paths before build automation can turn code changes into trusted artifacts.

Threat narrative

Attacker objective: The attacker wants trusted access to the software supply chain so they can exfiltrate secrets, alter code, and distribute malicious or backdoored releases downstream.

1. Entry begins with compromise of a developer environment or repository rather than a hardened production server, which gives the attacker access to code and related trust material.
2. Credential access follows when the repository exposes hardcoded secrets, API keys, certificates, or other reusable credentials that can be applied elsewhere.
3. Escalation occurs when the attacker uses repository access to modify code, trust relationships, or build inputs so the CI/CD pipeline produces attacker-influenced output.
4. Impact arrives when signed or trusted releases carry the malicious change into production or customer environments without a direct server compromise.

Breaches seen in the wild

• New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Source code is now part of the identity perimeter: Once repositories define infrastructure, access to code is no longer a developer convenience issue. It becomes a governance problem for IAM, PAM, and NHI controls because the repository can carry secrets, trust relationships, and deployment authority in one place. Security teams that still separate application code from infrastructure are missing where control now actually lives.

Developer identity is the new leverage point: The article correctly shows that attackers target the identity with the shortest path to repository, CI/CD, and signing trust. That is not just a phishing or account-takeover story, it is an access-path story about who can change the blueprint of production. The practitioner consequence is that developer access cannot be assessed only by endpoint posture or production segregation.

Secrets in source code create identity blast radius, not just leakage risk: When a repository contains credentials, the breach is not limited to the codebase itself. The exposed secret becomes a live authentication artifact that can connect the attacker to other systems, making source code a multiplier for credential abuse. The practical question is not whether secrets exist in code, but how far those secrets can reach once they are found.

Source code as infrastructure: This is the right named concept for the shift the article describes. The phrase captures the fact that repositories now encode control logic, deployment paths, and trust assertions, not just intellectual property. Practitioners should use it to reset governance assumptions about code review, repository access, and release integrity.

AI compresses the time between compromise and supply-chain impact: The article is right that AI does not create the target, but it does reduce the cost of exploiting it. Once a developer identity is compromised, AI can help map secrets, surface trust paths, and draft plausible code changes faster than manual review can keep up. That means review depth and identity telemetry both become part of supply-chain defence, not optional extras.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Source code as infrastructure: Security programmes need to stop assuming repositories are passive intellectual property stores. When code defines infrastructure, secrets, policy, and release logic, repository access becomes a production control issue and should be governed accordingly.

The change also collapses the old separation between developer tooling and infrastructure security. Teams that only review server hardening but not repository privilege, build trust, and signing paths will miss the place where a compromise can be turned into a trusted release.

Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), according to the State of Secrets Sprawl 2026, which makes repository scanning and credential revocation a governance task, not a nice-to-have hygiene step.

For practitioners

• Treat repositories as privileged infrastructure Classify source control systems as production-critical assets and apply privileged access governance to repository admins, maintainers, and release approvers.
• Hunt and remove embedded secrets Scan repositories, commits, and build logs for hardcoded credentials, API keys, and certificates, then revoke any exposed secrets immediately.
• Separate commit access from release trust Require stronger controls for merge, build, and signing actions than for ordinary contribution access so one compromised identity cannot move code straight into release paths.
• Monitor repository activity for trust-path changes Watch for unusual edits to pipeline definitions, deployment manifests, and identity policy files because those changes can redirect production behaviour without server access.

Key takeaways

• Repository compromise is now an infrastructure risk because source control can define the systems, policies, and trust paths that shape production.
• The main exposure is not only stolen code but the secrets, release logic, and identity relationships embedded inside it.
• Governance has to move upstream into repository access, secret discovery, and build trust controls before attackers can turn code into a delivery channel.

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.
• Repository Trust Path: The chain of permissions, build steps, and signing relationships that turns a code change into a trusted release. When this path is weakly governed, a compromised developer identity can move from source access to downstream delivery without ever touching a production server.
• Developer Identity Context: The set of permissions, tokens, and authenticated sessions available on a developer workstation or in a build environment. When that context is too broad, malicious code can move from local execution into source repositories, registries, or cloud services.
• Embedded Secret: An embedded secret is a credential, token, API key, or certificate that has been placed inside an image, file, or configuration bundle. Once exposed, it can outlive the original control that created it, so revocation and rebuilds become necessary even if the underlying system is later patched.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.