Observe
Accelerate
Troubleshoot
Did you know that over 20,000 new software security vulnerabilities were disclosed in just the first half of 2025? And since February 2025, the volume of disclosed vulnerabilities has increased by more than 3x.
Although AI is opening up vast opportunities for innovation, it’s also introducing new risks, and in some cases, being used to attack the software toolchain itself. As a result, we need a more comprehensive approach that extends far beyond traditional security measures. For DevOps and software supply chain professionals, understanding and implementing robust Governance, Risk, and Compliance (GRC) is becoming essential for protecting an organization’s most critical business systems.
Several recent examples underscore how our existing defenses have some critical blind spots. Take the malicious Nx packages in the ‘s1ngularity’ attack or the compromising of popular npm packages like ‘debug’ and ‘chalk’. There’s no doubt that the threat landscape is evolving, and with the help of AI, doing so more rapidly than ever.
Moving beyond traditional security: The GRC imperative
Traditional security products typically detect and mitigate threats directly at runtime or build time, focusing on confidentiality, integrity, and availability. Examples of this are virus scanners, CVE scanners, and firewalls. While many security products may have some GRC components, their primary purpose remains security.
GRC products, by contrast, focus on defining and automatically enforcing governance policies — controlling who can do what — and maintaining the evidence and audit trails needed for compliance reporting. Automating these controls in what we call Continuous GRC not only strengthens governance but also reduces the manual effort required to prove compliance.
GRC in the world of DevOps encompasses three core pillars that are imperative in today’s AI-driven software world:
- Governance: This involves setting directions, defining decision rights, and enforcing policies to align engineering activities with corporate strategies. Enforcing compliance, efficiency, or cost requirements often drive corporate governance policies, and extend well beyond security alone.
- Risk: While security is a significant aspect of risk, it’s not the only concern. Risk also includes delivery risk (e.g., hitting release deadlines) and operational risk (e.g., service downtime). A robust GRC approach aims to massively reduce time to detection and recovery, thereby significantly cutting overall risk, including residual risk.
- Compliance: When we talk about compliance, we’re talking about ensuring software conforms to external regulations and laws, as well as internal standards. Compliance requires not only adhering to these standards but also being able to provide verifiable evidence of that conformance through audit trails and controls. Without demonstrable proof, an organization is not truly compliant.
Uncovering blind spots in the supply chain
Historically, GRC efforts in the SDLC have concentrated on external runtime dependencies (e.g. third-party libraries) and services shipped with software. But we’ve seen two significant blind spots emerge within internally-facing systems:
- Internal toolchain dependencies: These include build systems (e.g., Gradle Build Tool, Apache Maven, npm), plugins, JDK versions, and binary repositories. These components require governance due to their essential nature for building production software as well as the increasing threat of toolchain attacks.
- Internal runtime dependencies: These include internal utility and core modules that require different GRC flows than external dependencies. For example, an internal library vulnerability would not be reported externally. How do you find out where these affected components are used at build time or in production?
Solutions like Develocity Provenance Governor eliminate these blind spots by enabling organizations to detect deployed software built with a given toolchain and prevent the deployment of software built with corrupted systems. This also extends to proactively detecting and enforcing policies against unwanted toolchain dependencies early in the SDLC—from local development to pull requests and IDEs—long before deployment.
Real-world examples: The Nx and npm attacks
The need for advanced supply chain governance has only been further underscored by recent attacks.
The ‘s1ngularity’ attack on Nx
The maintainers of the open-source Nx build system alerted users to a supply chain attack involving the publication of malicious versions of the nx npm package and other auxiliary plugins. These malicious packages contained code designed to scan file systems, collect credentials (including GitHub, Cloud, and AI credentials), and exfiltrate them to public GitHub repositories.
Over 2,349 distinct secrets were leaked, primarily GitHub OAuth keys and Personal Access Tokens, along with credentials for Google AI, OpenAI, AWS, and more. The attack’s root cause was a vulnerable workflow that allowed executable code injection via specially crafted pull request titles, exploiting the elevated permissions of the pull_request_target trigger to steal npm tokens. What was new in this attack was the exploitation of installed AI CLI tools (like Claude Code, Google Gemini CLI, and Amazon Q CLI) to search for secrets on developers machines as an attack vector directed at the supply chain itself.
Compromise of npm’s ‘debug’ and ‘chalk’ packages
In a separate incident, 18 very popular npm packages—including debug (357.6 million weekly downloads) and chalk (299.99 million weekly downloads)—with over 2 billion total weekly downloads in all, were updated to contain malicious code. This malware acted as a browser-based interceptor, hijacking network traffic and application APIs like fetch, XMLHttpRequest, and common wallet interfaces. It silently rewrote values in requests and responses, redirecting sensitive identifiers such as payment destinations or approval targets to attacker-controlled accounts without the user’s knowledge. The maintainer was compromised through a phishing email.
These attacks demonstrate the critical vulnerabilities in how software components are built and managed, emphasizing that the toolchain itself has become a prime target.
Taking action: Continuous GRC and Develocity Provenance Governor
Develocity Develocity Provenance Governor lets you enforce policies on every artifact and every build across your SDLC
A shift towards continuous GRC, supported by specialized tools, will address the escalating sophistication of supply chain attacks. Develocity Provenance Governor provides this continuous governance by focusing on critical blind spots within the software supply chain.
As a GRC product with a focus on DevOps practices, Develocity Provenance Governor helps prevent future attacks from harming production systems by focusing on the following areas:
- Proactive policy enforcement: It allows organizations to define policies that proactively prevent the use of compromised build systems or unwanted toolchain dependencies before deployment. This shifts governance left in the SDLC, catching issues much earlier. For instance, in the case of the npm attack, a policy could have prevented the use of the corrupted package versions.
- Comprehensive provenance and attestation: Develocity Provenance Governor records how an artifact was produced (provenance) and enables the creation of signed, verifiable claims (attestations) about artifacts. Build Scan® provides unique and comprehensive provenance data, which is then published to evidence stores. This data forms an “evidence chain,” a set of attestations that document the build process.
- Policy engine for verification: A specialized policy engine, using a declarative language, evaluates these provenance-based policies against the collected evidence. This engine can be invoked anywhere in the SDLC to determine if an artifact complies with defined policies. This provides objective, verifiable proof of compliance or non-compliance.
Using a tool like Develocity Provenance Governor for continuous GRC can have an outstanding organizational impact.
- Risk reduction: By providing the ability to quickly detect which deployed software components were built with a compromised toolchain, Develocity Provenance Governor drastically reduces the time to detection and recovery. This significantly cuts overall risk, including the residual risk associated with not being 100% sure if all affected components have been identified. For example, if a Gradle plugin were compromised, the tool could immediately identify all services built with that specific version, preventing the need to take down all services as a precautionary measure.
- Addressing toolchain blind spots: Develocity Provenance Governor directly tackles the blind spot of internal toolchain and runtime dependencies, which are increasingly exploited by attacks. This capability allows organizations to not only detect past usage of compromised systems but also to prevent the deployment of software built with them in the future.
- “Shift-left” opportunities: While the current implementation for Develocity Provenance Governor focuses on post-artifact publication, our vision includes extending policy enforcement even earlier in the SDLC, such as in developer IDEs, local builds, and pull requests. This shift-left approach significantly reduces delivery and security risks, as issues are caught and fixed when they are much cheaper to resolve. This aligns with the DORA capability of pervasive security across the entire SDLC.
To move beyond reactive security measures, organizations must implement a continuous GRC framework—with the help of a specialized tool like Develocity Provenance Governor—that proactively governs the entire software supply chain. By adopting this approach, you can ensure policy enforcement, reduce risk, and maintain verifiable evidence of compliance to build more resilient systems for the future.
Read on about Develocity Provenance Governor and then connect with a Gradle team member to learn more.