For years, software supply chain security has focused on a relatively simple idea: stop vulnerable packages before they enter the ecosystem.
At first glance, this sounds perfectly reasonable. Products such as JFrog Curation and Sonatype Repository Firewall emerged around this principle, promising to block vulnerable or unapproved dependencies at the point of ingress. The idea is noble. If risky software never enters the organization, the organization remains safe.
The problem is that DevOps software delivery no longer behaves like a static perimeter with a single fortified gate. In many ways, traditional repository governance risks becoming the Maginot Line of software supply chain security, heavily fortified against yesterday's threat model while DevOps software delivery evolves around it. The idea is still valid, but it is no longer sufficient.
The challenge becomes even more significant as AI accelerates software creation and artifact movement throughout the software development life cycle (SDLC). As change velocity, dependency churn, and audit surface area expand, trust can no longer be a one-time decision made at the gate.
DevOps delivery now resembles a Zero-Trust system. Trust is no longer established once and assumed forever. Every artifact, dependency, build, promotion, deployment, and runtime transition must be continuously verified as conditions change. A dependency that appears trustworthy today may become a "zero-day" tomorrow. A build that satisfies policy in development may fail compliance before production. Trust becomes a perpetually evaluated property rather than a one-time decision.
This creates the foundation for Just-in-Time GRC (Governance, Risk, and Compliance): the continuous evaluation of software trust at every SDLC gate. Just as Zero-Trust in Production assumes trust is never permanent and must be reverified, Just-in-Time GRC reevaluates trust as software moves through development, CI, QA, governance, release, deployment, and production.
Rather than asking whether a dependency should ever enter the organization, enterprises can instead evaluate whether an artifact is safe to progress to the next SDLC gate at a specific moment in time. Development environments may be fine with a short AI hackathon. QA environments may require stronger guarantees. Production environments may enforce zero-tolerance policies around critical vulnerabilities or unsigned attestations.
Governance no longer exists solely at the perimeter. It exists at every stage across the lifecycle.
Provenance is established the moment an artifact gets its "birth certificate" - when third-party software transitions from a package into a governed OSS asset, and when first-party and second-party artifacts first acquire governed identity. Once an organization decides to curate, consume, and manage an artifact throughout its lifecycle, that asset needs a durable identity that supports governance, compliance, risk evaluation, and trust verification.
This is where the concept of a Strongly Identifiable Binary (SIB) becomes critical.
A SIB is not simply a binary, identified by a hash key, with extra metadata attached. It is a software artifact with a strong binary identity established at the point where human-readable source code is transformed into machine-executable binary instructions. That identity is formed by coupling three immutable elements:
- Provenance metadata
- Cryptographic hashes of the binary
- The original binary storage location within the artifact repository
This is also where the distinction from traditional curation matters most. A SIB establishes a strong identity, with provenance, across every class of artifact an organization governs:
- 3rd-party - External software the organization didn't build: OSS packages and vendor dependencies pulled in from outside.
- 2nd-party - Internal software built by another team in the organization and shared across team boundaries (internal libraries, SDKs, framework components).
- 1st-party - Software the team builds from its own source code.
Traditional curation focuses on 3rd-party/OSS packages but provides no identity. Furthermore, many current Zero-Trust implementations remain incomplete in the development phase of the SDLC for the same reason. Enterprises have invested heavily in establishing strong identities for users, devices, services, workloads, and network interactions, yet the deployed binaries themselves, especially the 1st-party and 2nd-party artifacts an organization builds, are often still weakly identified by names, versions, repository paths, or container tags. Those identifiers are useful, but they are not strong enough to prove which exact binary it is, where it originated, how it was produced, or whether it has changed.
A SIB changes that model across all artifact types. By establishing immutable binary identity, a SIB allows both OSS assets and 1st-party/2nd-party artifacts alike to be explicitly verified at every stage of the SDLC. The platform can verify the artifact's cryptographic hash, validate its provenance metadata, confirm its original storage location, and determine whether it was built from authorized source code using approved toolchains, dependencies, processes, and CI infrastructure.
That is what makes SIBs foundational to Just-in-Time GRC. Trust is no longer granted because an artifact has passed through a repository once. Trust is reverified through the artifact's strong identity as it moves from build to promotion to deployment.
If SIBs provide the provenance layer, the other half of Just-in-Time GRC is the operational telemetry it generates: the policies, attestations, and facts captured every time trust is reevaluated.
The outcome of Just-in-Time GRC is Artifact Observability: an always-queryable view of each software asset's identity, lineage, policy posture, and chain of custody across the SDLC. Once software assets can be strongly identified and curated at every stage, organizations can trace where they came from, how they were built, which policies were evaluated, where they moved, and whether they remain trustworthy.
Production observability changed how organizations run systems. Instead of reconstructing incidents across disconnected logs and tools, observability platforms created continuously queryable views across services, infrastructure, metrics, traces, and events. The same shift is now happening in the software supply chain.
One of the biggest misconceptions in DevOps software delivery is treating a software build as a single action. A build is actually a process: dependency resolution, toolchain initialization, plugin execution, compilation, testing, packaging, signing, policy evaluation, and artifact promotion. DevOps CI/CD systems generate operational context across every one of those steps, yet most governance tools still inspect only isolated checkpoints at the perimeter. Risk doesn't come only from the dependency itself. It can emerge from compromised transitive dependencies, malicious build plugins, inconsistent toolchains, unsigned artifacts, policy drift, ephemeral CI environments, or AI-generated code changes.
Instead of focusing solely on package ingress, Toolchain & Artifact Observability continuously captures and correlates facts about:
- What was built
- Who built it
- How it was built
- Which dependencies and toolchains were used
- Which policies were evaluated
- Where the artifact moved
- How risk posture evolved over time
Development, CI, QA, governance, release, staging, and production become part of a cryptographically verifiable chain of custody. Policy evaluations become signed attestations. Promotion decisions become observable lifecycle transitions. Risk posture becomes measurable in real time rather than statically enforced. Together, these produce artifact observability, artifact lineage, and a chain of custody for every asset.
Just-in-Time GRC sounds like a straightforward concept. In practice, it requires a fundamentally different architecture.
Traditional repository-centric solutions assume the repository itself is the system of record for software trust. Governance decisions are tied to a specific repository, occurring primarily at the point of acquisition. Just-in-Time GRC requires something broader. Trust must be continuously evaluated across the entire software delivery lifecycle, often spanning multiple repositories, evidence stores, compliance systems, deployment platforms, and attestation frameworks.
This requires separating governance from storage.
The data plane is where software is built, stored, promoted, approved, and deployed. Repositories, build systems, CI/CD pipelines, IT service management (ITSM) workflows, and the software and dependency curation processes all participate in moving software through the SDLC.
The control plane serves a different purpose. It establishes identity, lineage, policy, governance, observability, and trust across those systems, not by replacing existing delivery infrastructure, but by providing a consistent governance layer that reevaluates software assets as they move through heterogeneous enterprise environments. The control plane is where three things live:
- Provenance, where the SIB for every 1st-party, 2nd-party, and 3rd-party artifact is recorded.
- Fact Store, where the observability telemetry produced by Just-in-Time GRC, policy scans, facts, and evidence is collected.
- DASM (DevOps Artifact Service Management), which manages provenance, fact store, the artifact inventory and footprint, and lifecycle policies.
This approach manages policies centrally while allowing attestations and software facts to remain distributed across existing enterprise infrastructure. It enables organizations to standardize governance without forcing them to centralize all software supply chain data into a single repository. Because the control plane indexes identity, facts, and lineage in one light-weight layer, it can answer trust and analytics queries far faster than reaching into the distributed data plane systems directly.
More importantly, it is what makes Just-in-Time GRC operationally possible. Because governance lives in the control plane rather than the repository, a newly published vulnerability can automatically trigger policy reevaluation at the next lifecycle gate. This is not simply a feature curation that firewalls happen to be missing. It is a gap their architecture cannot close.
This separation is what turns the control plane into an engine for Continuous GRC. Just-in-Time GRC's observability telemetry is the operational foundation for Governance, Risk/Security, and Compliance, the control plane's core use cases, with Just-in-Time GRC as the executor.
It also makes governance proactive and measurable. Policies become SLIs, gates can be assigned with SLOs, and metrics like CVE remediation time, policy pass rates, and promotion flow turn governance into operational DORA metrics. Like production observability, it lets organizations catch drift and proactively prevent trust failures before they become incidents, audit findings, or outages, aligning engineering, security, compliance, and leadership around a single model.
Continuous trust evaluation generates a new class of operational data. Strongly Identifiable Binaries, attestations, policy evaluations, governance decisions, artifact lineage, deployment history, and risk posture together create an ever-evolving record of software trust throughout the SDLC. Managing that information becomes an operational challenge of its own.
DASM represents one of the missing pieces of traditional Software Asset Management (SAM). SAM established how enterprises govern software licenses, applications, vendors, and technology assets. But it was never designed to manage the software artifacts themselves, the binaries, dependencies, attestations, provenance records, and trust relationships that move through DevOps software delivery systems. DASM extends those same asset-management principles to the artifacts.
Governing those artifacts as assets matters as much as governing the software products they ultimately compose. DASM emerges not as the discipline itself, but as the operational system for the telemetry, governance data, and GRC processes produced by DevOps software delivery. It serves as the system of record for software governance, risk, and compliance.
Curation and repository firewalls solved a first-generation problem: controlling how third-party software enters the enterprise. But as artifacts become long-lived assets moving through the full SDLC, organizations must govern trust across their entire lifecycle, not just at acquisition.
This is the vision behind Develocity as the universal platform for Toolchain & Artifact Observability. Toolchain Observability gives visibility into the systems producing software; Artifact Observability gives visibility into the artifacts themselves. Together forming the foundation for DASM.
In this model, SIBs provide identity, Artifact Observability provides evidence, Just-in-Time GRC provides the governance model and executor, and the control plane continuously evaluates trust across the SDLC. Organizations that adopt this model early won't just improve security posture, they'll achieve Zero Trust from source code to production, and just as importantly, the ability to prove it.
