Details
How provenance, continuous evaluation, and pipeline-native policy enforcement establish artifact trust throughout the software delivery lifecycle.
Artifact security cannot begin after a build has already reached the registry. Teams need to establish an artifact’s identity, provenance, contents, security status, and approval history while it is being built, then carry that evidence through every subsequent stage of delivery.
In this session, Harness leaders Monish Advani and Shankar Hariharan explain why artifact trust is especially important as AI agents generate code, select dependencies, and trigger builds at greater speed. They discuss how SBOMs, signatures, attestations, continuous vulnerability evaluation, and pipeline-native policies help teams verify what they are deploying without turning security into a delivery bottleneck.
Teams cannot reliably reconstruct an artifact’s complete history from a binary after it has already entered a registry. Provenance, SBOMs, signatures, test results, and attestations should be generated during the build and attached to the artifact’s digest.
Capturing this evidence at build time gives downstream systems a verifiable record of where the artifact came from, how it was produced, what it contains, and which checks it passed.
AI agents increasingly write code, select dependencies, generate pull requests, and trigger builds. This automation makes the traditional question of who manually chose a package less useful.
The more important question is whether the resulting artifact has verifiable provenance and whether every automated decision can be traced through the pipeline. Agent-generated code is not inherently trustworthy or untrustworthy; the evidence surrounding its production determines whether teams can safely use it.
A vulnerability scan alone does not establish trust. Teams should be able to answer several questions about every artifact:
Where did it come from?
How was it built?
What dependencies does it contain?
Which security and quality checks did it pass?
Who or what approved it?
Has it changed since approval?
Is its signature valid?
Together, provenance, SBOMs, signatures, attestations, test results, approval records, and promotion history create a more complete trust record.
An artifact that satisfied policy when it was built may become unsafe when a new CVE or zero-day vulnerability is disclosed. Trust therefore requires continuous evaluation rather than a one-time scan.
Registries and pipelines should reassess stored and deployed artifacts as threat intelligence changes. Policies can then block promotion, prevent deployment, or initiate remediation when previously approved software no longer meets the organization’s requirements.
Security controls should not exist only as a final gate before production. Policies can be enforced when dependencies enter the organization, when code is committed, during builds, when artifacts are promoted, and immediately before deployment.
The required evidence should travel with the artifact so each system can make decisions from the same trusted record instead of rebuilding context from disconnected tools.
Finding a vulnerable package is only the beginning. Teams also need to determine which artifacts contain it, which applications use those artifacts, which versions are deployed, and whether the vulnerable code is reachable or exploitable.
A useful zero-day response moves quickly from detection to impact analysis and prioritization. Identifying 30 exposed production applications is more actionable than reporting that a package appears somewhere within 2,000 applications.
Security becomes a delivery bottleneck when teams manually collect evidence from multiple systems and reconcile inconsistent records. Automating evidence collection and policy decisions within the pipeline can reduce that manual work.
The goal is not simply to add more gates. It is to make trusted evidence available at every decision point so routine approvals can happen automatically while exceptions receive appropriate review.
Build-time evidence is more reliable than reconstructed evidence
Practical implication: Generate provenance, SBOMs, signatures, and attestations as part of the build, and bind them to the artifact’s immutable digest.
AI agents need governed access to dependencies
Practical implication: Apply enterprise policies before an agent or developer can introduce an open-source dependency into the software supply chain.
Security findings change over time
Practical implication: Continuously reevaluate stored and deployed artifacts whenever vulnerability intelligence or organizational policy changes.
Registries need deployment context
Practical implication: Connect the artifact registry with CI/CD and deployment systems so teams can determine where each artifact has been promoted and deployed.
Zero-day response requires prioritization
Practical implication: Combine vulnerability detection with production exposure, reachability, and exploitability data to identify the applications that need attention first.
Governance should be native to delivery workflows
Practical implication: Automate evidence collection and policy enforcement within the pipeline instead of requiring teams to assemble security records manually at release time.
Q: What does it mean to trust an artifact?
A: Trust means having verifiable evidence about where an artifact came from, how it was built, what it contains, which security and quality checks it passed, who or what approved it, and whether it has changed since approval.
Q: What is artifact provenance?
A: Artifact provenance is a record of an artifact’s origin and production history. It can identify the source commit, build pipeline, builder, dependencies, associated metadata, and other information needed to verify how the artifact was created.
Q: Why should provenance be captured during the build?
A: Build time is when the pipeline has direct access to the source, builder, dependencies, tests, and security results. Capturing provenance then produces evidence that can be verified later. Reconstructing that history after a binary has entered a registry is less reliable and may omit important information.
Q: Is scanning an artifact in the registry enough?
A: No. Registry scanning is valuable, but teams should also scan and enforce policies when dependencies enter the organization, when code is committed, during the build, during promotion, and before deployment. Evidence collected throughout the lifecycle provides a more complete picture than a registry scan alone.
Q: What information should travel with an artifact?
A: The session recommends carrying an immutable digest, build provenance, an SBOM, signatures and attestations, test and approval results, and lineage information such as the base image and promotion history.
Q: Why is an approved artifact not permanently trusted?
A: New vulnerabilities can be disclosed after an artifact has passed its original checks. A package that appeared safe during the build may later become a liability, so stored and deployed artifacts need to be continuously reevaluated.
Q: What does a strong zero-day response look like?
A: A strong response quickly determines whether the organization is affected, identifies the blast radius, distinguishes production exposure from theoretical presence, evaluates reachability and exploitability, and prioritizes the applications that require immediate remediation.
Q: How can artifact governance avoid slowing developers down?
A: Teams can automate evidence collection, policy evaluation, signing, promotion decisions, and deployment verification inside the CI/CD pipeline. This reduces the manual work of collecting records from separate tools and allows compliant artifacts to proceed without unnecessary intervention.
Q: How does agentic development change artifact governance?
A: AI agents can write code, choose dependencies, and trigger builds at much greater scale. Organizations therefore need policies governing what agents can introduce and verifiable evidence showing how every resulting artifact was produced.
Eric Minick: Good morning, good afternoon, or good evening, wherever you’re joining us from. I’m your host, Eric Minick, and I’m excited for today’s session.
We’re going to talk about artifact governance and why trust must travel with every build. Before we get started, there are a couple of housekeeping items.
First, we are recording this session, so it will be available to you afterward. You can share it with your friends. Second, there is a Q&A panel on the platform. Please send us your questions. We’re eager to hear from you and understand what you’re curious about.
Now, the stars of the show are our panelists and my good friends, Monish and Shankar. Monish, can you introduce yourself?
Monish Advani: Thank you for having me. I’m Monish. I run product management at Harness, primarily focused on shift-left security, agentic security, supply chain security, and artifact security.
Shankar Hariharan: Thanks for having me as well, Eric. My name is Shankar Hariharan, and I run product for Artifact Registry at Harness. I’ve been with Harness for about four years and have spent more than a decade working at several high-growth startups. I’m excited to be on the panel.
Eric Minick: This is great. We’ve all been together for more than three years, so I love doing a webinar with both of you.
Let’s get into this idea of artifacts, governance, and trust. When I talk to teams, I hear, “We already have code scanning, and we’re running security tools within our coding environments. Why are we talking about artifacts? Isn’t it already done by then? Why are we worried about the security of the artifacts themselves?”
Shankar, why don’t you get us started?
Shankar Hariharan: That’s a good question. If you think about where an artifact registry sits in the software development lifecycle, it sits right in the center. On the left, you have code scanning and build scans. On the right, you have runtime security.
Artifact governance has existed throughout this process, but it probably hasn’t been fully automated. Some form of human judgment has been involved every time. You have a manual checklist and check for certain things before you start deploying. Nobody necessarily counted that as a control.
You have people writing code, a person reviewing the pull request, a person choosing which dependency should be used, and a person approving the release. A lot of this judgment has been uncredited security work happening manually.
From an evidence standpoint, you can split this into two unequal halves. Everything that records a decision today—whether it is a review or a test sign-off—attaches to a commit or a build. What is attached to the artifact is mostly rederived from whatever is being scanned.
Think about what has changed in the AI era. The producer side is becoming completely automated. Agents are writing code, adding dependencies, and triggering builds. The answer to “Who decided to pull this package?” increasingly matters less at that point.
What matters is the artifact’s provenance. You have to understand and produce evidence rather than reconstructing everything after pushing the artifact to the registry. That is what artifact governance is, and it is a problem many companies face today.
Eric Minick: That’s interesting. You’re saying we need governance, provenance, and trust.
Monish, when we talk about trusting an artifact—these files moving around, getting deployed, and going into other builds—what does trust mean? What does it mean to trust this thing?
Monish Advani: Trust comes down to being able to answer a few basic questions with confidence:
Where did this artifact come from? What exactly is inside it? How was it built? Which security checks did it pass? Has anything changed?
Trust isn’t just saying, “I scanned this container, and I didn’t find anything critical.” It’s knowing the source, the build process, the dependencies included in the SBOM, the security results, the provenance, and the signature. All of that adds up.
One important thing to note is that trust isn’t permanent. Something that was completely trusted a few weeks ago can become risky tomorrow because a new CVE or zero-day vulnerability gets disclosed. A lot of that has changed with AI, but I’ll come back to that.
Eric Minick: That’s an interesting idea—how trust can change out from under us.
Shankar, Monish listed several important things. Were there any others you wanted to add?
Shankar Hariharan: I like how Monish phrased it. You pose a set of questions that you can answer with evidence, and that becomes trust.
You need to know the digest, who committed the code, which developer or agent was involved, which pipeline produced it, and so forth.
There is one important thing I want to highlight. When I run a scan, can I simply take the vendor’s database at its word? Trust is constantly changing because what you scan today may or may not remain applicable tomorrow.
There are two kinds of evidence. A scan result sitting in a tool’s database is a useful observation. A signed attestation is a claim that you can verify without access to that system.
In the agentic world, there is a new entry on this list. A human may have committed the code, but an agent may have generated the pull request or selected the dependency.
I would be careful about reducing all of this to a trust score. I’m not saying agent-written code is inherently good or bad. What ultimately matters is provenance. Provenance has to be captured at build time. That is where trust comes in, because you cannot recover provenance or establish trust after pushing a binary to a registry.
Eric Minick: I just saw a question come through. We’ve said “provenance” a few times. What do we mean by provenance? Can somebody provide a basic definition?
Monish Advani: I can take that. Provenance, by definition, is primarily knowing where an artifact came from. You need identity and metadata.
Think about any product or software application you buy or source from a vendor. You need provenance to establish where it came from.
Think about buying a car. You have a window sticker that shows its bill of materials. You can see what is inside the car, which factory it came from, where it was built, and its VIN. That kind of metadata and attestation is formatted as provenance, which a consumer can use to determine where software or an artifact was built.
Eric Minick: I know not only that we ran some scans against it and that it is secure, but also what it is and where it came from.
Monish Advani: Absolutely. Those are the basics.
Eric Minick: That makes sense.
Another thing that comes to mind is the emphasis we’ve put on understanding artifacts and scanning them in various ways. We’ve talked about container scanning.
Do I just put builds into my registry and scan them there, or do I need to perform other scans and checks outside the registry context? Monish, you probably have a perspective on this.
Monish Advani: You have to start early. As soon as code is committed, you need to start scanning it, whether an agent or a developer wrote it.
Everything that happens during pre-commit, commit, and the image build needs to be scanned as early as possible, before it moves into the registry for deployment.
Developers also use dependencies coming from the registry. Those dependencies need to be scanned as soon as approved packages are made available for developers to consume.
Before deployment, you need approval checks and additional scans to make sure an application is safe before it moves into production.
There are different stages where you need continuous evaluation and continuous scanning to ensure that something is safe to deploy.
Eric Minick: You’ve alluded to the idea that we aren’t only performing these scans and checks. We might also use them for decision-making or to enforce what is allowed.
Shankar, where might we put policies in place?
Shankar Hariharan: Scanning is one part of it. Monish explained why scanning only at one stage isn’t enough.
The key point is that you have to capture metadata as your artifact travels across the software development lifecycle. Reconstructing metadata from a binary will not always give you the correct information.
What decisions can you make in the pipeline, and what data do you need to make those decisions?
Five things should always travel with the artifact. First, everything should be tied to a digest. You need build provenance. You need an SBOM generated during the build. You need artifact signatures and attestations. You need the results from your test and approval cycles.
When it comes to artifact lineage, you also need information such as the base image and promotion history. All of these become decision points before deployment.
If you capture this metadata as the artifact travels across the software development lifecycle, you can build and enforce policies based on it. If you generate SBOMs, for example, you can have SBOM enforcement policies. The same applies to attestations and every other type of data captured across the lifecycle.
Eric Minick: Monish, is there anything you want to add about where these checks should happen?
Monish Advani: I think about applying checks wherever you can identify risk.
Imagine that you built an artifact three weeks ago and it passed certain security steps. You need a policy to make sure it was signed and approved before it was deployed.
Whenever a new CVE appears in a registry or dependency pool, you need a check. Wherever your artifact changes, you need the right checks and policies in place before you enforce a decision.
Eric Minick: If I see a new security finding, do I simply reject the artifact as a firm rule?
Monish Advani: You add enforcement on top of the finding. If you generate an SBOM, you can ensure that a dependency is blocked if it isn’t allowed. That philosophy applies to every new step you build.
Eric Minick: This sounds straightforward so far. We run our scans, establish provenance, make sure we know what the artifact is, and store it safely.
It gets a little less clear as we move toward an actual release. Approving an artifact doesn’t necessarily guarantee that it is exactly what we will ship to production.
Where do those concerns come from, and how do we ensure that what we release is what we actually ship? Monish, am I making this up, or is this a real concern?
Monish Advani: It is absolutely a real concern. I think of it as artifact integrity and tampering.
What gets deployed needs to have been signed and tested during the build. You also need enforcement checks to verify that it was signed by the correct signer and that the code was committed by known developers.
You need to understand all of this so you can detect whether an artifact has been tampered with.
If you look at supply chain attacks, attackers are increasingly targeting the build system. SolarWinds is a well-known example. Attackers try to compromise the build system, manipulate the artifact, and tamper with it before deployment to create a widespread impact.
Provenance, signing, attestations, and a complete audit trail are essential for knowing what came from the source before it is promoted for deployment.
Eric Minick: Attacks on build systems are interesting. We routinely see attackers targeting actions and other parts of the build process.
Shankar Hariharan: I’d like to add one point about enforcement. We’ve discussed what happens after the build, but agentic development is also creating an enormous increase in artifact growth. Much of that involves bringing open-source dependencies into the organization.
If you look at recent software supply chain attack campaigns, including Shai-Hulud and others, many have succeeded because unsecured open-source dependencies were introduced into an organization’s ecosystem.
Organizations need policies and checks to make sure incoming dependencies comply with enterprise-wide requirements. This is especially important in an agentic environment.
On the shift-left security side, securing open-source dependencies and having a way to enforce policies against them is critical.
Eric Minick: One common source of concern is that we’re talking about security, which is classically viewed as the department of “no”: You can’t do it. Stop. Wait. Let’s check everything.
How do we ensure that all this governance doesn’t become a major bottleneck?
Executives are saying, “Go faster. Why wasn’t this done yesterday? We have AI.” There’s pressure to accelerate.
How do we prevent governance from slowing us down, or at least keep it from slowing us down any more than necessary? Monish, why don’t you take the first pass?
Monish Advani: Given today’s expectations for how quickly software and code should be produced, the challenge remains deploying that software safely and securely.
AI helps teams write much more code, but we haven’t solved everything that happens after the code is written. Last year was about AI producing more code. Now that code enters the delivery funnel, and deployment becomes the concern.
Doing that at scale while doing it securely will continue to be a challenge. We have many services and artifacts being built through autonomous software delivery processes using agents from code creation through deployment.
Ensuring that the right checks are in place and understanding what agents or developers are doing at each stage is becoming more critical.
A tremendous amount of code is being written. Secure deployment at scale is the next major problem we need to solve.
Eric Minick: That makes sense. Shankar, is there anything you want to add about enforcing policies quickly?
Shankar Hariharan: Monish is right. Traditionally, customers have used different tools and then tried to stitch the evidence together at the end. That is what creates many of today’s bottlenecks.
You have data coming from multiple sources, and you are trying to assemble evidence showing that an artifact traveled through one system and then another before using that evidence to make a decision.
The solution will scale when organizations automate the collection of this evidence throughout the artifact’s journey—from the moment code is committed, through the build, and until it reaches production.
You shouldn’t think only about adding more gates. You should also consider how many hours of manual toil you can eliminate.
How do we automate the process? How do we bring all the information together? Can we automate the decision-making?
Eric Minick: That makes sense. I’m seeing messages reminding me that I said I would come back to something Monish mentioned.
You said that just because an artifact is approved now doesn’t mean it will necessarily be approved in the future. I thought we checked this thing. What’s going on?
Monish Advani: It is the drift happening around these artifacts.
As more code is written and a zero-day vulnerability appears in an artifact, things change dramatically. CISOs want to understand whether the organization is affected. Knowing only that a vulnerable package is present isn’t enough to answer that question.
Teams want to ship all this new code faster, but they also need to understand what has changed in an artifact. Often, this comes down to security issues. They need to know which new features have been introduced and whether security problems are causing breaking changes for those features.
Organizations need visibility into what changed, why it changed, and who or what made the change. Then they have to answer the same fundamental question: Can I continue to deploy this artifact safely?
Eric Minick: When you talk about zero-days, our minds always go to Log4j because it traumatized all of us.
Imagine that I have an older version of Log4j. The application is in QA, and we’re testing it. When we originally ran all the scans, it appeared safe.
Before we move to production, we learn that it has a serious vulnerability. At that point, we would say, “No, don’t ship that version to production. We want to ship the next build containing the patched version.”
Something that was acceptable is no longer acceptable.
Monish Advani: That’s correct.
I want to extend that point. When a zero-day vulnerability appears, the first question is whether you are affected while you determine how to upgrade to a newer version.
Understanding exploitability and reachability has also become important. Gone are the days when teams would simply say, “Give me the newer version of Log4j.” Now they want to know whether the current version is actually exploitable and whether the vulnerable code is reachable in their environment. Otherwise, they may not want to upgrade immediately.
These are more specific questions that customers and CISOs are asking. Application security and DevOps teams are struggling with vulnerability fatigue. Everything appears to be a vulnerability because more code is being written, sometimes unsafely.
When you add the number of open-source packages involved, you can’t simply upgrade everything and assume the problem is fixed. An upgrade might break other parts of the application.
Since Log4j, the conversation has progressed from visibility into vulnerabilities toward understanding their impact, reachability, and exploitability.
Eric Minick: I remember that Log4j could be difficult to exploit in some circumstances, but nobody initially knew whether it was exploitable in their environment, so organizations changed everything.
You’ve brought up zero-days several times. I want to talk about what a good zero-day response looks like.
Shankar, I’d like to start with you. How can the repository or artifact registry act as a central governing location when teams react to a newly discovered vulnerability?
Shankar Hariharan: I want to begin with what Monish said previously. Approval is a state. You made a decision at a particular point in time based on the data available to you.
An important posture for enterprises is therefore to maintain constant security evaluation—a consistent way to reevaluate artifacts.
When a zero-day vulnerability appears, the first thing you need to determine is whether you are affected. You need a quick way to understand the impact on your artifacts and whether those artifacts have been deployed to production.
The second step is identifying the blast radius. From conversations I’ve had with customers, roughly half the problem is understanding that blast radius. Teams can spend weeks trying to determine it.
This is an important problem to solve. When a zero-day vulnerability appears, can I quickly determine whether I am affected and what the blast radius is?
This becomes even more important in an agentic environment. When an agent writes code and selects dependencies, it often optimizes for successfully completing the build. It may introduce dependencies that are insecure.
Organizations need constant reevaluation that leads to a security posture in which trust is established through the continuous evaluation of artifacts.
Eric Minick: That makes sense.
You made an interesting point about knowing what has actually been shipped to production. It sounds as though there needs to be a close connection between the pipelines and the artifact registry so the registry knows what happened to its artifacts.
Shankar Hariharan: Absolutely.
Eric Minick: Monish, why don’t you expand on what a good zero-day response looks like?
Monish Advani: The CISO’s first question is whether the organization is affected.
There is a major difference between an application security or DevOps team saying, “We found this zero-day dependency in 2,000 applications,” and saying, “We found it in 30 production applications that are exposed and need attention first.”
That is how the conversation has shifted.
A good zero-day response moves from detection to impact analysis and prioritization very quickly. If you can do that correctly, you have a strong response.
A new zero-day vulnerability could appear tomorrow morning through a LinkedIn post or an announcement from one of the package managers. If you can assess it within 30 minutes or an hour across your environments and applications, you have reached an important goal.
Eric Minick: Suppose we’re a large organization with 5,000 applications. Two thousand contain the package, but 30 are in production and may contain reachable vulnerable code. Now I know what to fix.
Perhaps I can patch those applications in a more automated way than before. We’ve discussed agentic development, and I have CI/CD pipelines in place. I can route the changes through those pipelines and get the patch into production.
How quickly does that need to happen today? Are we talking about hours or days?
Monish Advani: Typical service-level expectations range from 24 to 72 hours for a highly critical zero-day vulnerability. That is what we try to solve for at Harness.
We help customers identify affected environments and applications that are exploitable, reachable, and exposed so they can address them first.
If an organization cannot respond within that timeframe, it may not have an effective zero-day program.
Eric Minick: We’re changing code here, so it isn’t only a matter of whether I can modify it. I also need to know whether the change is secure. I probably have to run all my tests and make sure everything still works.
Monish Advani: Absolutely. This is where a remediation agent comes into play.
It can help automate the code changes needed to upgrade dependencies or packages. It can also determine whether there are breaking changes and which regression tests need to pass.
Many approaches are probabilistic, so they can’t provide a guarantee. But when you have the full pipeline context, relevant code, Dockerfiles, container image, and the source from which the artifact came, you can combine that information to automate the process of fixing a zero-day vulnerability intelligently.
Once you discover the vulnerability, you need high confidence that you can fix it safely and move on to the next vulnerability or zero-day.
Eric Minick: I know we’re a little low on time, so I want to ask each of you one final question.
Imagine we’re talking to a DevSecOps or platform engineering team. They’re listening and thinking, “This makes sense. We should improve artifact trust and understand how artifacts flow through our systems so we can operate more safely.”
If they can change only one thing, where should they begin? What is the most important and impactful first step they should take tomorrow?
Monish Advani: I would start with artifact identity and provenance at build time.
If you know exactly what you built, where it came from, what is inside it, and which security checks it passed—and you attach that evidence to the artifact—everything downstream becomes easier.
Once you have that foundation, you can continuously evaluate the artifact for vulnerabilities. The registry can enforce promotion policies, continuous delivery can verify it before deployment, and when a zero-day vulnerability appears, you have an inventory you can trust.
If you don’t establish trust and identity when you build an artifact, you will spend the rest of its lifecycle trying to reconstruct that information, which is extremely difficult.
That is the first change I would recommend as a DevSecOps practice.
Shankar Hariharan: I would add one point. Trust must travel with the artifact.
On the shift-left side, I would also encourage enterprises to establish policies and gates that vet incoming open-source dependencies so their downstream impact is much lower.
Organizations need the ability to determine whether a dependency is acceptable, especially in an agentic environment where agents may pull thousands of dependencies every hour.
To establish secure and trustworthy artifacts across the software development lifecycle, one of the key starting points is securing open-source dependencies.
Eric Minick: We need to make sure that what we bring in is safe from the beginning. We also need to know what we have. When we perform builds, we need to understand exactly what each build is. That creates a foundation for governing everything downstream.
I love it. Let’s bring the session to a close.
I encourage our listeners to download the PDF we shared in the resources section. If you would like to learn more, we’re all from Harness, so visit harness.io.
We’d be happy to talk with you, give you a demonstration, or help you start a free trial. However you would like to engage with us, we’d love to hear from you.
Thank you, everyone, for attending.
Shankar Hariharan: Thank you.
Monish Advani: Thank you.
Presenters:
Shankar Harihan
Product Director, Harness
Monish Advani
Sr. Director of Product Management, Harness
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
