Code repositories are a common source of unintentional corporate credential leakage.

Developers may inadvertently commit sensitive information, such as API keys,

passwords, or private certificates, directly into source code or configuration files that

are then pushed to version control systems like Git. If these repositories are public, or

even private but improperly secured or accessed, these embedded credentials become

exposed. This type of leakage is typically accidental, stemming from oversight or a lack

of awareness of secure coding practices for managing secrets.

· B. Dark web: The dark web is a marketplace or forum where already compromised

credentials are often sold or shared, not the initial source of an unintentional leak.

· C. Threat feeds: Threat feeds provide intelligence about known threats,

vulnerabilities, and compromised data, including credentials. They report on leaks

rather than being the origin of the unintentional leakage.

· D. State actors: State actors are sophisticated threat entities that may actively seek to

steal credentials. While they can cause credential exposure, they represent an

intentional actor, not a passive source of unintentional leakage like a mismanaged

repository.

· E. Vulnerability databases: These databases (e.g., CVE) list known software or

system vulnerabilities. A vulnerability might be exploited to cause a credential leak, but

the database itself is not the source of the leaked credentials.

1. AWS Security Best Practices - Managing Secrets: While not a direct statement about

repositories being the most common, AWS documentation frequently warns against

hardcoding secrets. For instance, the "AWS Well-Architected Framework - Security

Pillar" emphasizes using services like AWS Secrets Manager to avoid hardcoding

secrets in application code. This implicitly acknowledges the risk of secrets ending up in

code.

o URL: https://docs.aws.amazon.com/wellarchitected/latest/securitypillar/sec_manage-secrets.html (Refer to sections on "Managing secrets" and avoiding

hardcoding.)

2. NIST Special Publication 800-160, Volume 2, Revision 1: Developing Cyber

Resilient Systems: A Systems Security Engineering Approach: This document

discusses secure software development practices. While it may not explicitly state

"code repositories are the most common source," it emphasizes the need to protect

sensitive information throughout the system development lifecycle, and accidental

commitment of secrets is a failure in this area.

o URL: https://csrc.nist.gov/publications/detail/sp/800-160/vol-2-rev-1/final (See

Appendix F, Security Design Principles, specifically related to protecting sensitive

information and secure defaults which apply to how code and configurations are

managed).

3. Meli, M., McNiece, M., & Reaves, B. (2019). How Bad Can It Git? Characterizing

Secret Leakage in Public GitHub Repositories. In NDSS. The Internet Society. This

peer-reviewed academic paper directly investigates and quantifies the problem of

secret leakage in public code repositories.

o DOI: https://doi.org/10.14722/ndss.2019.23286

o Specifically: The abstract and introduction highlight the prevalence of secrets (API

keys, credentials) being accidentally committed to public GitHub repositories.

4. Zulkarnain, A., & Kauri, K. (2021). An Empirical Study of Accidental Secrets

Exposure in Public GitHub Repositories. IEEE Access, 9, 65839-65853. This is

another academic publication that studies the phenomenon.

o DOI: https://doi.org/10.1109/ACCESS.2021.3075187

o Specifically: The paper confirms that developers frequently leak secrets to public

repositories, making it a significant source of unintentional credential exposure.