TL;DR: Developer workstations are now a high-ROI entry point in supply chain attacks because malicious packages, extensions, and plugins can exfiltrate credentials before code reaches production, according to Aikido. The control gap is no longer just pipeline security; it is visibility and trust on the developer device itself.
At a glance
What this is: Aikido argues that developer machines, not just build pipelines, are now the preferred target in supply chain attacks because they can leak credentials at install time.
Why it matters: IAM, PAM, NHI, and endpoint teams need to treat the developer device as part of the trust boundary, because local installs can expose credentials before traditional pipeline controls ever see them.
Context
Supply chain risk is no longer confined to package registries and build systems. In this article, developer machines are the point of compromise because they sit closest to the credentials, tools, and extensions that developers trust every day, and that trust is often weaker than pipeline hardening.
That shift matters for identity governance because developer endpoints can expose GitHub credentials, API tokens, and other secrets before code is committed or packaged. Once the workstation becomes part of the attack path, endpoint security, identity controls, and software supply chain governance have to be treated as one control surface.
Key questions
Q: What breaks when developer machines are not governed as part of supply chain security?
A: When developer machines are left outside the control model, attackers can use trusted local installs to steal credentials before the pipeline ever sees malicious code. That turns a workstation compromise into authenticated access to source control, build systems, and cloud services. The failure is not only detection, but the assumption that the device itself is outside the supply chain boundary.
Q: Why do developer endpoints increase supply chain risk so quickly?
A: Developer endpoints concentrate trust. They often hold code-signing access, registry tokens, cloud credentials, and browser sessions that can be abused by malicious packages or extensions. Once those secrets are exposed, attackers can move from local installation to real access with very little friction, which is why the endpoint becomes a high-ROI target.
Q: What are the signs that developer machine controls are failing?
A: Warning signs include unknown packages, browser extensions, or IDE plugins appearing on developer devices without review, along with missing visibility into what was attempted versus what was approved. If EDR can describe the host but not the software trusted by the host, the control set is incomplete.
Q: Should teams manage developer workstation risk separately from CI/CD security?
A: No. CI/CD and developer endpoints are part of the same delivery chain, but the workstation now appears to be the more attractive entry point in many supply chain attacks. Teams should align endpoint, AppSec, and identity ownership so that local installation risk and pipeline risk are governed together.
Technical breakdown
Why developer devices are a supply chain control point
Developer machines sit upstream of the build pipeline and often hold the credentials that make the pipeline work. If a malicious package, IDE extension, browser plugin, or terminal download runs during installation, it can execute code immediately and harvest tokens or session material before any CI/CD control is involved. Traditional security tools tend to focus on installed applications and post-execution telemetry, which misses what happens inside the software a developer intentionally adds. The result is a trust gap between what teams believe they are approving and what the device actually executes.
Practical implication: monitor the developer device itself, not only the pipeline that receives its output.
Where EDR and MDM leave blind spots
Endpoint detection and mobile device management are built to observe device posture, applications, and policy compliance, but they do not always inspect the inner content of developer tools. That means packages, extensions, and embedded scripts can land with little visibility even when the outer application looks legitimate. Supply chain attackers exploit that gap because it lets them reach credentials at the moment of local installation, not after a later exploit chain. The security problem is therefore not just malware detection, but governance of what developers are allowed to install and run in their working environment.
Practical implication: add controls that inspect developer tooling and extensions, not only device health.
How local install-time compromise turns into identity exposure
A malicious install can trigger a post-install script, extension payload, or hidden dependency that reads environment variables, cached secrets, or authenticated browser and IDE sessions. In practice, that can expose source control credentials, cloud access tokens, and other non-human identities tied to developer workflows. This is where identity security intersects with supply chain security: the attacker is not trying to break the build first, but to steal the identity material that lets them act as a trusted participant later. Once those credentials are harvested, the attacker can move from local compromise to broader access with very little friction.
Practical implication: govern developer credentials as high-value NHI assets with tight issuance and revocation rules.
Threat narrative
Attacker objective: The attacker wants trusted developer credentials and local execution paths that let them compromise software delivery from inside the developer environment.
- Entry occurs when a developer installs a compromised package, extension, or plugin on a workstation they trust for daily work.
- Credential harvesting follows immediately if the payload reads stored tokens, session material, or environment variables during local install.
- Escalation happens when the stolen credentials are used to access source code, registries, or cloud resources under a trusted identity.
- Impact is supply chain compromise, because the attacker can poison software, exfiltrate secrets, or stage follow-on attacks through the development environment.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Developer machines have become a governance boundary, not just an endpoint category. The security model that protects production builds does not automatically protect the laptop where packages, extensions, and agentic tools are first installed. That matters because the earliest compromise point now sits before the pipeline, where identity material is already present and trusted. Security teams should treat the developer device as part of software supply chain governance, not as an IT support asset.
Local install-time compromise is the real failure mode. The important shift is not that attackers can reach the build system, but that they can steal credentials during the act of installation itself. That means the control assumption that a developer chooses safe software and the pipeline will catch the rest is no longer reliable. The practitioner response is to govern what can execute on the workstation and what secrets that workstation can expose.
Identity and endpoint security now overlap at the developer seat. Source control tokens, cloud credentials, browser sessions, and other machine-bound identities are being used on devices with uneven visibility and inconsistent approval controls. That is an NHI governance problem as much as a malware problem, because the attacker is abusing trusted credential material rather than exploiting code alone. Teams should classify developer credentials as high-value identities and manage them with tighter issuance, monitoring, and revocation.
Package-only thinking misses the broader device threat surface. The article shows that IDE extensions, browser plugins, and emerging AI tools can be just as important as package registries. That creates what we would call a developer trust gap, where the device contains more installation pathways than the security stack is designed to inspect. Practitioners need a unified view of installed software and trust decisions across the entire developer endpoint.
The market is moving toward device-level supply chain control. As attackers shift left from pipeline compromise to workstation compromise, point controls that only inspect CI/CD are becoming incomplete. This does not replace pipeline security, but it does validate a broader model in which developer endpoints, software provenance, and identity protection are governed together. Security programmes that do not account for this overlap will continue to miss the highest-ROI attack path.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Developer trust gap: the next control boundary is the workstation, because attackers are increasingly abusing software that developers intentionally install rather than breaking the pipeline first. That changes programme design: visibility has to extend to local install surfaces, not just CI/CD gates.
A supply chain programme that stops at build-time scanning will miss the most useful compromise point if developer endpoints can still execute unreviewed packages, extensions, and scripts. The practical response is to converge endpoint telemetry, identity protection, and software provenance into one operating model.
Where developer-held secrets are effectively non-human identities, the governance question becomes who can issue, observe, and revoke them when the workstation itself is the attack surface. That is now a core identity programme concern, not a niche AppSec issue.
For practitioners
- Inspect developer install surfaces Inventory and control what can be installed on developer machines, including packages, IDE extensions, browser plugins, and AI tools. The goal is to reduce the chance that trusted local software can execute hidden payloads before code reaches the pipeline.
- Treat developer credentials as high-value identities Classify source control tokens, cloud access tokens, and other developer-held secrets as sensitive identity assets. Scope them tightly, monitor their use, and revoke them quickly when a workstation or extension is suspected of compromise.
- Add guardrails at the local stage gate Move approval logic closer to the workstation so developers get a prompt before risky installs occur. A local gate should question unknown or suspicious software before it can reach cached credentials or authenticated sessions.
- Expand telemetry beyond EDR inventory Collect visibility into installed packages, extension inventories, and attempted installs across developer endpoints. Use that telemetry to identify machines with unusual software patterns and to spot emerging compromise paths earlier.
- Unify endpoint, AppSec, and identity ownership Create a single operating model for the intersection of developer endpoints, software supply chain risk, and credential governance. The control gap exists partly because these domains are split across teams that do not share one risk view.
Key takeaways
- Developer machines have become the earliest and often easiest compromise point in supply chain attacks because they expose trusted software, credentials, and sessions before code ever reaches production.
- The central evidence in this article is a control gap between what endpoint tools can see and what developers actually install on their machines, especially packages, extensions, and AI tools.
- Security teams need to govern developer endpoints as part of identity and supply chain risk, with tighter install controls, better telemetry, and faster secret revocation.
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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Developer machine compromise in this article centers on exposed credentials and tokens. |
| NHI-10 — Human Use of NHI | The article shows developers using machine credentials and trusted local sessions as attack paths. | |
| Recommendation — Scan developer endpoints for exposed secrets and revoke any credentials that local installs can reach. Separate human developer access from machine-held credentials and limit reuse across local workflows. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack pattern combines credential harvesting on the endpoint with movement into delivery systems. |
| Recommendation — Map developer-device compromise paths to credential access and lateral movement techniques in your detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is overexposed developer access that lets local compromise become trusted access. |
| Recommendation — Apply PR.AA-05 to tighten entitlements tied to developer workstations and the secrets they can reach. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Stolen developer tokens and session material are authenticator lifecycle failures. |
| Recommendation — Use IA-5 to govern issuance, storage, rotation, and revocation of developer credentials and tokens. | ||
Key terms
- Vendor trust gap: A vendor trust gap is the space between assuming an external partner is legitimate and actually verifying that the request is safe. In practice, it appears when business familiarity becomes a substitute for identity validation, especially in finance, procurement, and account-change workflows.
- Local Install-Time Compromise: A compromise that happens during the act of installing trusted software on a workstation, before code reaches a build system or production environment. This pattern matters because post-install scripts and embedded payloads can steal secrets immediately and bypass controls that assume the pipeline is the first risk point.
- Developer NHI: A developer NHI is a non-human identity used in software engineering workflows, such as API tokens, npm credentials, GitHub tokens, SSH keys, and automation secrets. These identities often have broad access and long lifetimes, which makes them high-value targets when build tools or developer machines are compromised.
- Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for teams that need to connect identity controls to broader attack paths.It helps IAM, PAM, and security practitioners translate identity risk into operational governance across modern environments.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org