A source credential is a secret or authentication artifact used to connect a build service to a source repository. In practice, it controls access to code inputs and must be managed carefully because exposure or misconfiguration can disrupt builds and increase security risk.
Expanded Definition
A source credential is the NHI secret or authentication artifact that lets a build service read from a source repository, such as a Git server or code hosting platform. It is distinct from deployment credentials because its purpose is limited to code intake, not runtime access or production changes. In secure engineering practice, the credential should map to a narrowly scoped service identity, with access constrained to the minimum repositories and actions required. Guidance varies across vendors on whether this should be a long-lived token, a short-lived token, or a federated workload identity, but the security objective is consistent: reduce blast radius and eliminate hidden reuse. NIST’s NIST SP 800-63 Digital Identity Guidelines are useful when teams need to reason about assurance and authentication strength, even though the document is not specific to CI systems. The most common misapplication is treating a source credential as a generic developer token, which occurs when the same secret is reused across human and machine workflows.
Examples and Use Cases
Implementing source credentials rigorously often introduces pipeline complexity, requiring organisations to weigh tighter repository access against the operational overhead of rotation and federation.
- A CI runner authenticates to a private Git repository using a dedicated token that can only read one project and cannot push code.
- A build system uses a short-lived federated identity instead of a stored secret, reducing exposure if the runner is compromised, a pattern aligned with the principles discussed in the OWASP Non-Human Identity Top 10.
- A monorepo pipeline separates source access by component so a compromise in one job cannot enumerate unrelated repositories, which is a recurring theme in the Guide to the Secret Sprawl Challenge.
- A software supply chain review replaces hard-coded source tokens with dynamic credentials after exposure in build logs or YAML files, similar to cases documented in Reviewdog GitHub Action supply chain attack.
- A release engineering team audits all source access paths after discovering that a credential was also usable against non-source systems, creating unnecessary lateral movement risk.
These use cases show why source credentials should be treated as workload credentials with explicit lifecycle controls, not as convenience secrets embedded in automation.
Why It Matters in NHI Security
Source credentials are a high-value target because they sit at the entry point to software creation. If an attacker steals one, they can poison builds, read private code, harvest downstream secrets, or insert malicious changes that appear legitimate. NHIMG research shows that 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which makes source credential exposure more likely during handoffs and troubleshooting. The risk is amplified by CI/CD sprawl, where a single credential may be copied into logs, variables, runners, and developer notes. This is why NHIMG’s reporting on the 2024 Non-Human Identity Security Report matters: a large share of organisations still lag in non-human IAM maturity, even as their build systems depend on precise repository access. Practitioners should also review the NIST SP 800-53 Rev 5 Security and Privacy Controls for control expectations around access management and system integrity. Organisational exposure typically becomes obvious only after a build compromise, at which point source credential governance 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 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-63, 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 | Source credentials are workload secrets whose scope and storage must be tightly controlled. |
| NIST SP 800-63 | Provides assurance concepts for authentication strength, useful when evaluating source credential trust. | |
| NIST CSF 2.0 | PR.AC-1 | Access to repositories should be limited to authorized identities and approved paths. |
| NIST Zero Trust (SP 800-207) | Zero trust principles support per-request verification and least-privilege source access. | |
| CSA MAESTRO | Agentic and automated workflows must control tool and data access, including source repositories. |
Use assurance-based authentication choices and avoid shared long-lived tokens for build access.
