Every engineering organization has them: dependencies that have gone untouched for months. Everyone knows they are there, but no one fixes them. Then a security vulnerability lands in one of those forgotten libraries. Suddenly, it is a fire drill.
The gap isn't awareness. It is friction. The people who set dependency policies and the developers who act on them rarely have a way to connect. There is no easy enforcement layer between policy and action.
The software supply chain generates data constantly. Every commit, build, scan, and deployment emits facts about how software is made. But these facts often land in separate tools that do not talk to each other.
These silos exist for good reasons. Each tool solves a specific problem for a specific team:
- Security teams keep Software Bill of Materials (SBOM) inventories.
- Platform teams watch build performance.
- Compliance teams run attestation frameworks.
Each tool captures a slice, but none capture the whole. When an audit occurs, the cost of this split becomes obvious. Finding facts becomes a manual task of stitching together data across consoles, exports, and ticket threads.
The industry has not yet applied the same close watch to the supply chain that it applies to running systems. Waiting until an audit to upgrade a dependency turns a routine task into a big investigation. The facts exist, but the tools to find them do not.
Production observability solved this for running systems. When a service fails, you do not have to rebuild the story from a dozen screens. You use one view that shows everything in one place, organized by time and service. The data stays in one place, and the view changes to show what you need.
You can apply that same lens to the supply chain. Build systems, scanners, and deployment platforms all emit facts. We provide the instrumentation to make those facts easy to find across the full artifact lifecycle and trustworthy enough to drive decisions.
Develocity Provenance Governor provides that instrumentation layer. It captures facts across the full software development lifecycle (SDLC). This includes build, Policy Scan™ evaluation, and production deployments. It binds those facts cryptographically to the process that produced them and shows them in a single view.
The triangle of trust has three edges. To check a piece of software, you must connect 'what' was built with 'who' built it. This happens in three steps:
- The build system sends a Build Scan® to Develocity. This records all the dependencies and tools used.
- Develocity Provenance Governor uses that build data and identity to create a signed attestation. This proves who built the software.
- Provenance Governor combines the 'what' and the 'who' into a single source of truth.
This ensures every fact in your dashboard is proven and real. Each part is a trust boundary. While most tools assume data is correct, the triangle of trust verifies it instead.
Every part uses short-lived access tokens to connect. This removes the need for permanent credentials or long-lived secret keys that could be stolen. The system automatically verifies the identity of every connection, so your team does not have to manage permanent credentials.
Provenance Governor checks the identity of the build system directly for attestation and evaluation. Trust is built in steps and managed at each gate. This allows your team to choose exactly where to check your software.
The link between Provenance Governor and Develocity adds more security. Even with valid credentials, the service only allows the specific actions it has been pre-approved to perform. This keeps your system safe even if someone gets hold of valid credentials.
Provenance Governor records different facts at each stage. When a build finishes, the system records everything about the environment. It records a complete list of every dependency and tool used during the build.
During a Policy Scan evaluation, the system records the digital proof that explains why it trusts the software. This includes:
- Workload identity claims: repository, branch, workflow, person.
- OIDC (OpenID Connect) issuer: the trusted identity provider that confirmed who is making the request.
- Access justification: why the rules were met.
- Decision metadata: who asked, who checked, and which rules were used.
- Verification timestamp.
At each gate, the system also records a fresh risk score. This is not just a temporary note. It is a signed fact permanently attached to the software.
When a customer asks about a piece of software, you don't need to guess if the information is correct. You just check if the digital facts are proven. The triangle of trust makes the data itself proof that it is correct.
Tools are useful because they show you what is happening. Develocity Provenance Governor combines signals that usually live in silos: Build Scan data, security risk (vulnerability) data, and who made the software.
Policy Scan gates allow you to instrument each step of the SDLC. You can place these gates at every stage, from development through to production. This creates a continuous record of your software's health. Each gate records the fresh risk score, the pass/fail status, and the specific policy rules in effect at that moment.
This works because the system records what dependencies are used while the software is being built. It watches the build tool directly as each dependency is added. It does not try to guess which dependencies were used by scanning files later. This stops the mistakes that happen when tools try to guess which dependencies are being used.
The recording is complete: every dependency, plugin, and toolchain version (such as Java or npm) is captured with cryptographic rigor. This fixes a common problem. You no longer have to guess which tools were used to build the software. The version of Java used to build the software becomes a known fact, not a guess.
A compromised build plugin becomes visible to Develocity Provenance Governor even when a runtime-focused scanner cannot see it.
This security covers the entire software building process. When a security risk is found, you can use proven facts to answer "are we at risk?" You don't have to piece together information from many different tools and logs. The answer comes from one place. The facts are either proven or they aren't.
Maven, Gradle, and other build tools use dependencies that use other dependencies. A security bug hidden deep in these dependencies can put the build at risk. Provenance Governor records every plugin and tool as a signed fact. These use the package URL (PURL) standard.
Many companies treat where they save data as a technical problem. They solve it using cloud tools. Develocity Provenance Governor makes it a rule-based choice. You manage it using the same settings you use to control who can see the data.
Strict rules ensure that data from different teams is saved in separate places, like different Amazon S3 buckets. Data from one team never gets mixed with another team's data, even if they use the same system.
Automated replication means that when a policy points to multiple stores, Provenance Governor fans out on both read and write. There is no separate setup for cross-region replication. Because write fan-out is inline with the publish operation, there is no replication lag. This simplifies multi-region disaster recovery and hybrid-cloud storage.
Provenance Governor never keeps permanent credentials to your systems. It uses IRSA (IAM Roles for Service Accounts) and STS (Security Token Service) to access your accounts. This keeps the work and the storage separate and safe. The rules you set for who can see the data also decide where it is saved. Everything else follows from that.
Updating software dependencies is a common task. The real challenge is how fast you can start using safe, new versions. How fast can your team remove a risky version after a security bug (CVE) is found?
Develocity Provenance Governor tracks three important times for each software dependency:
- Consumption: When it was first used in a build.
- Upstream release: When a new, safer version became available.
- Lifecycle transitions: When it was checked at each security gate.
These timestamps show when a bug was found and where the software was at that time. The score at each gate helps you decide when the risk was first seen.
The DependencyScoring policy is your main tool for this. It matches rules to software dependencies (using PURL) and scores them based on:
- Risk and updates: Security risk (VULNERABILITY) and needed updates (UPGRADE).
- Time-to-fix targets: How fast you need to fix things based on how dangerous the bug is.
- Upgrade strategies: How you choose to update (PATCH, MINOR, or MAJOR).
The PATCH plan only gives a low score when a simple fix is ready. This makes it safer to update without breaking anything. This helps teams make safe updates first.
This discipline applies to both open source and internal software dependencies. Internal software dependencies often lack vulnerability scanning, leaving organizations to rely on mandates that erode team autonomy. DependencyScoring brings observability-driven discipline to these dependencies, providing a facts-based way to track progress without top-down mandates.
Other tools tell teams to upgrade. Develocity Provenance Governor tells teams how well they are doing, measuring against their own policy, in facts an auditor can verify.
An observable supply chain lets you track your own metrics. Develocity Provenance Governor records the time at every gate. This lets you see how long things take and how often you ship software. You can see how long it takes for a new update to reach your users without using extra tools.
You can also track how often changes fail. This is another important metric called change failure rate. Just like other monitoring tools, this lets you create your own ways to measure success. For example, you can track how long it takes to fix a security bug using signed timestamps.
Software supply chain security is becoming more than just a checklist. New tools like observability and digital trust give companies a better way to stay safe. Develocity Provenance Governor is built around this change. The data is easy to see, the trust is proven by digital signatures, and the storage follows your rules.
These tools even watch the software used to build the software. Tools like Maven and Gradle are watched just like the dependencies they use. There are no blind spots; it is "turtles all the way down," with the triangle of trust securing every turtle.
Moving toward supply chain observability is a big change for the industry. Teams that start using these tools today will have the transparency and trust they need to secure their software before the next emergency happens. As AI continues to accelerate the pace of software delivery, having this automated, proven trust layer will be essential to keeping up safely.
