Who is accountable when a malicious dependency exposes cloud and Kubernetes credentials?

Why This Matters for Security Teams

When a malicious dependency exposes cloud and Kubernetes credentials, the failure is rarely just “bad code.” It is a shared control breakdown across package provenance, runtime isolation, secrets handling, and identity governance. The exposure can turn a single dependency update into infrastructure compromise, which is why NHI Management Group treats this as an identity and privilege problem as much as a supply chain problem.

This is also where static trust assumptions fail. Once credentials are embedded in build artifacts, environment variables, or shared secret stores, an attacker can pivot from the dependency to cloud APIs, cluster-admin actions, or lateral movement across services. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Guide to the Secret Sprawl Challenge both point to the same operational reality: secret location and privilege scope matter as much as secret strength. In the 2026 Infrastructure Identity Survey, 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic and automated workloads.

In practice, many security teams encounter credential exposure only after a dependency has already been pulled into CI/CD, deployed to a cluster, and granted more access than intended.

How It Works in Practice

Accountability should be mapped to the control plane that could have prevented the blast radius, not just to the team that wrote the application. Dependency owners are responsible for provenance, version pinning, and vulnerability response. Platform engineering is responsible for constraining runtime permissions, pod-to-cloud access, and Kubernetes service account scope. IAM and secrets teams are responsible for where secrets live, how they are issued, and how quickly they are revoked.

Operationally, the safest pattern is to avoid long-lived static secrets wherever possible. Use workload identity to bind the workload to its permissions, and issue short-lived credentials only when a trusted workload needs them. That aligns with current best practice in NIST SP 800-63 Digital Identity Guidelines, even though there is no universal standard for every cloud and Kubernetes implementation yet. For secrets-heavy environments, the 2024 Non-Human Identity Security Report shows the maturity gap clearly: 88.5% of organisations say their non-human IAM practices lag human IAM or are only on par, and 59.8% see value in dynamic ephemeral credentials.

• Use provenance checks and dependency signing before deployment.
• Bind pods and services to workload identity instead of shared static credentials.
• Scope cloud and Kubernetes permissions to the minimum runtime action set.
• Store secrets in a managed vault with short TTLs and automatic revocation.
• Log secret access and correlate it with package, pod, and identity telemetry.

This guidance tends to break down in legacy clusters that rely on shared service accounts, embedded kubeconfigs, or manually rotated cloud keys because revocation is slow and attribution is weak.

Common Variations and Edge Cases

Tighter secrets controls often increase deployment friction, requiring organisations to balance faster delivery against lower compromise risk. That tradeoff becomes more visible in polyglot microservices, third-party operators, and workloads that must talk to multiple clouds or clusters.

One common edge case is a dependency that does not directly steal credentials but exfiltrates them from build logs, mounted volumes, or environment variables. Another is a compromised package that triggers token minting through overly broad service account permissions. In these cases, the accountable parties are still the same, but the control failures may sit in different layers. NHIMG’s 52 NHI Breaches Analysis and the 230M AWS environment compromise both show how quickly compromised non-human access expands when privileges are too broad.

Where current guidance is still evolving is the exact handoff between AppSec, platform, and IAM for shared responsibility metrics. Best practice is to define ownership by control type: package integrity, runtime privilege, secret lifecycle, and incident response. That keeps accountability from disappearing into a “shared” label that no one can operationalise.

Related resources from NHI Mgmt Group

• Who should own containment when a dependency attack exposes cloud and repository credentials?
• Who is accountable when a managed Terraform platform exposes secrets or misapplies policy?
• Who is accountable when compromised credentials are used to access personal or infrastructure accounts?
• Who should be accountable when an MCP integration exposes cross-tenant data?