Who is accountable when a malicious marketplace plugin steals secrets from developers?

Why This Matters for Security Teams

A malicious marketplace plugin is not just a software supply chain issue. It is an identity and secrets exposure event that can turn ordinary developer tooling into a credential theft path. Once a plugin can read local files, environment variables, browser sessions, or CLI caches, it can exfiltrate secrets faster than manual review can react. That is why accountability extends beyond the attacker to the teams that allowed high-trust execution without enough guardrails.

This is the pattern highlighted in NHIMG’s Shai Hulud npm malware campaign analysis, where a package-level compromise became a secrets exposure event. The underlying control lesson aligns with the OWASP Non-Human Identity Top 10: secrets are not safe simply because they are issued to legitimate tooling. In practice, many security teams encounter the blast radius only after keys are already in attacker infrastructure, rather than through intentional pre-publication review or runtime containment.

How It Works in Practice

Accountability should be assigned by control plane, not by blame alone. The marketplace operator is responsible for moderation, takedown, abuse response, and package provenance controls. The organisation that permitted the plugin to run is responsible for endpoint policy, developer workstation hardening, secrets storage, and rapid revocation. Security teams are then responsible for detection, scoping, and incident response once exposure is suspected.

The practical response starts with revoking any credential the plugin could have touched, then checking where those secrets were valid. That includes API keys in CI/CD, cloud console tokens, signing credentials, and service account material. NHIMG’s Guide to the Secret Sprawl Challenge reinforces why this matters: fragmented secrets management makes it harder to know what was exposed and harder to invalidate it quickly. Current guidance from NIST also supports moving toward tighter control of secrets lifecycle and access governance, especially where developer endpoints are treated as trusted by default, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls.

• Disable or quarantine the malicious plugin and preserve endpoint telemetry for forensics.
• Rotate every potentially exposed secret, not only the one originally suspected.
• Invalidate sessions and tokens tied to developer tools, cloud consoles, and automation.
• Search for secondary use of exposed credentials across production, staging, and personal environments.
• Block known attacker infrastructure and add detections for reuse of the leaked values.

Accountability is shared, but it is operationalised through the party that can revoke access fastest, and through the team that failed to prevent an untrusted plugin from inheriting secrets in the first place. These controls tend to break down when secrets are long-lived, cached locally, and reused across multiple systems because there is no single owner who can prove full exposure scope in time.

Common Variations and Edge Cases

Tighter plugin control often increases friction for developers, requiring organisations to balance delivery speed against the risk of secret exposure. That tradeoff is especially visible in environments that rely on permissive marketplace installs, shared workstations, or unmanaged personal devices. In those settings, the right answer is usually not a broader trust policy, but narrower execution scopes and shorter-lived credentials.

There is no universal standard for this yet, but current guidance suggests three practical variations. First, if the plugin only ran on a single endpoint and secrets were well segmented, the incident may be contained to a limited set of accounts. Second, if the plugin touched CI runners or browser profiles, the blast radius is often much larger because those environments commonly hold higher-value tokens. Third, if the same secrets were embedded in multiple tooling layers, revocation must be coordinated across them all or attackers will simply shift to the next valid path.

NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is relevant here because static credentials create long-tail exposure long after the plugin is removed. The most defensible approach is to treat developer tooling as a high-risk execution environment, not a benign extension of the workstation. In the real world, incidents escalate when teams assume deletion of the plugin ends the problem, while attackers still hold valid credentials from before the takedown.

Related resources from NHI Mgmt Group

• Who is accountable when a malicious dependency steals secrets from CI runners?
• Who is accountable for removing GitHub Actions secrets that can be replaced with OIDC?
• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?