Topic starter
11/06/2026 11:36 pm
TL;DR: Source code repositories are frequently carrying plaintext secrets, and Orca Security cites 85% of organisations with secrets embedded in source code, alongside the 2024 breach cost average of $4.88 million and 1,732 breaches in H1 2025. That combination makes source code a governance problem, not just a developer hygiene issue.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Securing Your Source Code: A Critical Defense Against Modern Threats”.
Key questions
Q: What breaks when secrets are committed to source control?
A: The main failure is that a credential becomes reusable outside the developer workflow and can authenticate directly to cloud storage, APIs, or SaaS integrations.
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.
Q: How do identity teams know whether secrets governance is actually working?
A: Identity teams know secrets governance is working when they can prove that every active secret has an owner, an approved scope, and a tested revocation path.
Practitioner guidance
- Implement secret scanning in repositories and pipelines Scan source, commits, pull requests, and build logs for API keys, tokens, certificates, and database credentials, then block merges when live secrets are detected.
- Rotate exposed credentials as a mandatory response Treat any secret found in source code as compromised and revoke or rotate it before the credential can be reused in downstream systems.
- Separate credentials by environment and workload Use different secrets for development, staging, and production so a repository leak does not automatically expand into full production access.
Bottom line: Plaintext secrets in source code create a reusable identity exposure that repository controls alone do not contain.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 8:20 am
Source code secrets are now an identity security problem, not a developer mistake. The article is right to frame plaintext secrets as a governance failure because the asset being exposed is not code in the abstract but reusable authentication material. Once secrets live in repositories, the organisation has already lost control of their lifecycle. Practitioners should treat source control as part of the credential estate, not a separate engineering domain.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: What should teams do when a secret is compromised outside a code repository?
A: Teams should rotate the compromised key immediately, then trace where it was shared and used so related systems can be contained. They should also review adjacent tools and accounts for secondary exposure, because one leaked secret often reveals a wider trust path. Fast containment matters because remediation is resource intensive and affects engineering as well as security.
👉 Read our full editorial: Source code secrets are driving lateral movement and supply chain risk