GitHub apps are usually visible through the platform’s administrative controls and are easier to inventory and govern. Shadow integrations built with API keys, SSH keys, webhooks, or service accounts are less structured, often harder to discover, and more likely to escape security review. That makes them harder to monitor, scope, and revoke when risk changes.
Why This Matters for Security Teams
The difference is not just packaging. GitHub Apps are designed to be discoverable, permissioned, and reviewable within the platform’s governance model, while shadow integrations built on API keys or SSH keys often bypass that model entirely. That creates an identity problem as much as an access problem, because the organisation loses visibility into who or what is acting, what scope it has, and whether that access still matches business need.
This matters because secret-based integrations are a common path for silent privilege growth. NHIMG’s Guide to the Secret Sprawl Challenge shows how unmanaged credentials accumulate outside formal control, and GitGuardian’s The State of Secrets Sprawl 2025 found that 4.6% of public GitHub repositories contain at least one hardcoded secret. Once a key exists outside platform governance, revocation and scoping become reactive rather than deliberate. The current guidance in OWASP Non-Human Identity Top 10 is clear that unmanaged machine credentials deserve the same scrutiny as human access.
In practice, many security teams discover shadow integrations only after a leaked key, an unusual push, or an unexpected webhook has already created exposure.
How It Works in Practice
A GitHub App is installed with explicit, scoped permissions and visible lifecycle controls. Administrators can usually see where it is installed, what repository access it has, and when it was granted. That does not make it risk-free, but it does make it governable. By contrast, shadow integrations often rely on long-lived API keys, deploy keys, SSH keys, or service account tokens that live in scripts, CI jobs, personal laptops, and legacy automation. Those credentials may authenticate successfully for months without any platform-level signal that they exist.
From a security operations perspective, the difference is operationally important. A well-governed app can be reviewed against least privilege, rotated through normal change processes, and revoked centrally. A shadow integration usually has to be found first, then classified, then attributed to an owner before any cleanup can happen. That is why NHI governance increasingly treats these keys as workload identities rather than simple secrets. NIST’s Security and Privacy Controls emphasise access control, auditability, and configuration management, all of which are easier to apply when the integration is registered.
- Prefer GitHub Apps for integrations that need repository-scoped, reviewable access.
- Use short-lived tokens where possible instead of static API keys or reusable SSH keys.
- Inventory secrets and deploy keys as NHI assets, not just developer convenience artifacts.
- Map each credential to an owner, purpose, expiry, and revocation path.
NHIMG’s 52 NHI Breaches Analysis repeatedly shows that the failure is rarely the authentication method alone; it is the absence of lifecycle control around it. These controls tend to break down in fast-moving engineering environments where teams can create new automation faster than security can inventory and approve it.
Common Variations and Edge Cases
Tighter control over integrations often increases engineering friction, requiring organisations to balance developer velocity against revocation speed and auditability. Not every SSH key or API key is automatically bad, but current guidance suggests treating long-lived credentials as an exception that needs explicit justification. The tradeoff is especially visible in legacy deployments, third-party CI/CD pipelines, and cross-account automation where a GitHub App cannot yet cover the workflow.
There is no universal standard for this yet, but best practice is evolving toward ephemeral credentials, scoped workload identity, and continuous review of inactive integrations. In some cases, a deploy key may be acceptable for a narrowly defined repository workflow. In others, the same pattern becomes a shadow integration because no one can prove ownership, rotation, or effective use. That is why security teams should distinguish between “registered but constrained” and “unregistered and unmanaged.”
NHIMG’s BeyondTrust API key breach is a reminder that the problem is not limited to GitHub itself; any secret that can impersonate a system becomes a governance issue once it is copied into unofficial tooling. The practical test is simple: if the organisation cannot reliably enumerate, scope, and revoke the credential, it should be treated as a shadow integration until proven otherwise.
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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shadow integrations are unmanaged NHI credentials that evade inventory and ownership. |
| NIST CSF 2.0 | PR.AC-4 | This is about least privilege and access governance for machine identities. |
| NIST Zero Trust (SP 800-207) | SC-7 | Registered, revocable integrations fit Zero Trust better than static shadow keys. |
| NIST SP 800-63 | AAL3 | Strong assurance is relevant where keys impersonate privileged systems. |
| NIST AI RMF | Agentic or automated integrations need governance, accountability, and lifecycle risk treatment. |
Establish governance, measure risk, and monitor automated access as an ongoing AI risk activity.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between reviewing human access and reviewing NHIs?
- How should security teams govern API keys used for generative AI access?
- What is the difference between protecting applications and protecting access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
