Summary
- Mandiant says attackers are targeting trusted security tools, developer utilities, IDEs, and CI/CD infrastructure.
- Observed techniques include GitHub Actions cache poisoning, OIDC-token extraction, and abuse of mutable action tags.
- Compromise of build infrastructure can give malicious software legitimate-looking provenance and distribute risk downstream.
Attackers are increasingly targeting the systems used to build and release software rather than concentrating solely on vulnerabilities in finished applications, according to new guidance from Mandiant.
The Google-owned security business says recent campaigns have systematically targeted trusted security scanners, developer utilities, AI coding tools, developer workstations, integrated development environments, and continuous-integration and continuous-delivery infrastructure.
The techniques it highlights include GitHub Actions cache poisoning, extraction of OpenID Connect tokens, malicious developer extensions, theft of cryptographic keys and API credentials, and subversion of mutable action tags used by build workflows.
The common feature is trust. Development and build systems are deliberately granted access to source code, package registries, cloud environments, signing infrastructure, deployment credentials, and production pipelines. A tool that appears mundane from outside the engineering function can therefore hold enough authority to change what an organisation ultimately ships.
That changes the effect of compromise. An attacker who reaches a conventional workstation may gain the privileges of one user. An attacker who reaches a build pipeline may be able to alter artefacts consumed by customers, developers, cloud environments, or downstream systems at scale.
Software provenance does not automatically prevent that outcome. If malicious code enters before an authorised build or signing step, the resulting package may still carry legitimate cryptographic evidence showing that it passed through the organisation’s expected release machinery.
Mandiant consequently treats the engineering lifecycle as one connected security domain rather than a series of independent tools. Its recommendations span developer endpoints, repositories, dependency management, artefact stores, build systems, and release infrastructure.
The emphasis on identity is particularly important. CI/CD environments have historically accumulated long-lived secrets because automated systems require credentials that can operate without a human present. Federated identity approaches such as OpenID Connect can reduce that dependence by providing short-lived credentials based on workload identity instead of static keys.
Short-lived credentials are not sufficient if the workflow itself can be manipulated. A compromised build definition or mutable dependency may still request permissions, execute attacker-controlled code, or produce an artefact that appears to originate from the expected organisation.
Cyber Insider has previously examined how software supply-chain compromise is being connected with credential theft and extortion. Mandiant’s latest analysis widens the control surface to the development infrastructure that creates trusted software in the first place.
The growing use of AI developer tools adds another relationship. Coding assistants, automated scanners, and agents may be able to read repositories, propose changes, execute tools, or interact with issue trackers and build systems. The security question therefore extends beyond whether the model itself is trustworthy to what authority its integration possesses.
This is a supply chain problem in the literal sense: one compromised engineering component can affect organisations that never interacted directly with the attacker.
European regulatory frameworks are also increasing pressure on product and supplier governance. The Cyber Resilience Act, NIS2, DORA, and sector-specific regimes differ in scope, but each contributes to greater scrutiny of software dependencies and the controls supporting technology organisations buy or operate.
Mandiant’s publication is guidance synthesising patterns from recent campaigns rather than disclosure of one newly discovered breach. Its significance lies in the control point it identifies.
Software-security programmes have spent years improving vulnerability scanning of code and deployed applications. The systems that decide what becomes trusted software now require comparable scrutiny.
