Accountability should not sit with tooling alone. Security, engineering, and platform teams need clear ownership for dependency approval, vulnerability response, license review, and exception handling. Organisations should define remediation timelines, approval rules, and audit responsibilities so third-party risk is governed as a shared operational control rather than an ad hoc developer task.
Why This Matters for Security Teams
When third-party components enter a build, accountability shifts from a simple developer choice to a control problem spanning engineering, security, and platform operations. The risk is not limited to vulnerable packages; it also includes exposed secrets, unreviewed transitive dependencies, and supply chain compromise that can reach CI/CD runners and production environments. NHIMG’s research shows how quickly this can escalate in real systems, including the 52 NHI Breaches Analysis and the Reviewdog GitHub Action supply chain attack.
Security teams often assume software composition analysis or a dependency scanner creates accountability. It does not. Governance only exists when someone can approve risk, enforce remediation timelines, and decide when an exception is acceptable. That accountability should be aligned with the control expectations in the NIST Cybersecurity Framework 2.0, especially where software resilience and third-party risk management intersect. In practice, many organisations discover ownership gaps only after a malicious package, leaked token, or build-system compromise has already propagated into multiple environments.
How It Works in Practice
Clear accountability usually starts with a shared operating model. Engineering owns whether a dependency is technically needed, security owns the risk criteria, and platform or DevOps teams own enforcement in pipelines. For third-party components, that means defining who can approve new packages, who reviews license and vulnerability findings, and who must act when a supplier is compromised. The OWASP Non-Human Identity Top 10 is useful here because dependency risk often becomes identity risk once builds, agents, and automation systems rely on tokens, secrets, or service credentials.
Practically, teams should treat the introduction of third-party code as a governed event, not a passive import. A workable model includes:
- pre-approved dependency sources and package repositories
- ownership for vulnerability triage and patch scheduling
- documented exception handling for unpatched or high-risk components
- audit trails for who approved the component and why
- automatic revocation or rotation steps when exposed secrets are detected
NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces the operational reality that identities and secrets linked to software components must be managed through their full lifecycle, not only at deployment. That becomes especially important when third-party packages are introduced through CI/CD, because runners and automation accounts often have broader reach than individual developers. Current guidance suggests pairing this with controls from NIST SP 800-53 Rev 5 Security and Privacy Controls to make ownership, review, and corrective action auditable. These controls tend to break down in fast-moving release environments where teams ship dependency changes directly from ephemeral build pipelines without a named approver.
Common Variations and Edge Cases
Tighter third-party controls often increase release friction, requiring organisations to balance delivery speed against assurance. That tradeoff becomes sharper in open-source-heavy stacks, AI-enabled build workflows, and distributed platform teams where dependencies are updated constantly. There is no universal standard for this yet, but best practice is evolving toward risk-tiered approval rather than one blanket process for every package.
One common edge case is transitive dependency risk, where the component added by a developer is not the component that creates the exposure. Another is vendor-provided SDKs that bundle authentication material or telemetry endpoints, which means the accountability question extends beyond code review into secrets handling and runtime trust. NHIMG’s JetBrains Marketplace AI Plugin Campaign and Mastra npm Supply Chain Attack both show why “approved source” is not the same as “trusted outcome.” Organisations should also use Top 10 NHI Issues to frame how automated identities, build tokens, and service credentials expand the blast radius when supply chain risk is introduced. In the real world, this guidance fails most often where exception approvals are informal and no one is empowered to block a release.
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 SP 800-63, NIST AI RMF 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-01 | Third-party packages often introduce unmanaged machine identities and secrets. |
| NIST CSF 2.0 | ID.IM-1 | Supply chain ownership depends on defined governance and risk management roles. |
| NIST SP 800-63 | Identity assurance matters when build systems and automation accounts access trusted assets. | |
| NIST AI RMF | GOVERN | Governance is needed when AI-assisted tooling changes dependency risk decisions. |
| NIST Zero Trust (SP 800-207) | SC-3 | Third-party components expand trust boundaries and require explicit access control. |
Apply strong identity proofing and authentication to automation accounts that can introduce or update components.
Related resources from NHI Mgmt Group
- Who is accountable when a third party breach leads to internal data exposure and potential supply chain risk?
- Who is accountable when a release ships with incomplete software supply chain evidence?
- Who should be accountable for third-party non-human identity risk when business tools request elevated access?
- Why do overpermissioned third-party integrations increase supply chain risk?
