Staying in Control: Auditing and Reporting with Harness Artifact Registry | Harness Blog

At some point, every engineering team gets asked a version of the same uncomfortable question: "Where exactly are we using this package?"

Maybe it comes after a CVE drops. Maybe it's a compliance audit. Maybe it's just a principal engineer trying to clean up years of accumulated technical debt. Whatever the trigger, the answer is almost always the same: a lot of shoulder shrugging, Slack messages to people who might know, and a mad scramble through repos.

This is what happens when artifact management has no well-defined governance. Packages get pulled, images get built, dependencies pile up, and nobody has a real record of any of it.

Harness Artifact Registry is built with this problem front and centre. Alongside storing and distributing your artifacts, it gives your organization genuine visibility into what's happening with them, through audit trails and compliance-ready reporting.

Let's walk through what that actually looks like.

Every Action, Recorded

The foundation of auditing in Harness Artifact Registry is simple: nothing happens silently.

Every push, pull, deletion, policy evaluation, and quarantine action is logged, along with who or what triggered it and when. That applies to human users, automated pipelines, and service accounts alike. If something touched an artifact, there's a record of it.

Because Harness Artifact Registry is natively integrated into the Harness platform, these logs don't exist in isolation. When a pipeline pulls an image during a deployment, the audit trail connects that download to the specific pipeline run, the environment it deployed to, and the user or trigger that kicked it off. You're not just seeing that something was downloaded. You're seeing the full context around why.

Try it yourself: If you have Harness Artifact Registry set up, you can check the audit trail for your account right now. Navigate to Account Settings > Audit Trail, and filter by module:

Module: Artifact Registry
Resource Type: ARTIFACT_REGISTRY

You'll see every registry-level event with the actor, timestamp, and action. For pipeline-linked events, click through to see the full execution context.

You can also query audit events programmatically via the Harness API:

curl -X POST 'https://app.harness.io/v1/audit-events' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Harness-Account: YOUR_ACCOUNT_ID' \
  -H 'Content-Type: application/json' \
  -d '{
    "filterType": "AuditEvent",
    "modules": ["CORE"],
    "resourceTypes": ["ARTIFACT_REGISTRY"],
    "startTime": 1714003200000,
    "endTime": 1714089600000
  }'

This matters enormously during incident response. If a vulnerability surfaces in a package, you don't need to start guessing or digging through repos manually. You pull up the artifact, check its audit history, and you have a clear map of every pipeline and service that has consumed it. What might otherwise take days to piece together becomes a focused, time-bounded task.

Compliance Without the Scramble

For teams operating in regulated environments, audit trails aren't just useful, they're mandatory.

Harness Artifact Registry is built to support compliance with SOC 2, HIPAA, PCI-DSS, and other regulations out of the box. The audit trail covers the full artifact lifecycle, so when an auditor asks for evidence of access controls, artifact provenance, or quarantine procedures, you're not building that record from scratch. It's already there

‍

Access to artifacts is governed through Harness's role-based access control (RBAC). Harness Artifact Registry supports three pre-built roles, Viewer, Contributor, and Admin, allowing you to define who has permission to push, pull, or manage artifacts at the registry level. Every access event is logged against those permissions, giving you a traceable, defensible record of who was allowed to do what and what they actually did.

What the RBAC roles look like in practice:

These roles can be assigned to individual users, user groups, or service accounts. To check your current role assignments via the Harness CLI:

# List all role assignments for a specific registry project
harness role-assignment list \
  --account-id YOUR_ACCOUNT_ID \
  --org-id YOUR_ORG \
  --project-id YOUR_PROJECT

When Security Meets Auditability

One of the more distinctive things about Harness Artifact Registry is how tightly it integrates with the platform's security modules. Artifact Registry doesn't try to be a scanner or a policy engine on its own. Instead, it plugs directly into Harness Security Testing Orchestration (STO) for vulnerability scanning and Harness Supply Chain Security (SCS) for SBOM generation, policy enforcement, and compliance checks. The result is that security findings flow straight into the artifact record rather than living in a separate tool.

Through integration with Harness Security Testing Orchestration (STO) and Harness Supply Chain Security (SCS), every container image that lands in the registry can be automatically evaluated for vulnerabilities and compliance. If an image fails a security or policy check, can be quarantined automatically, before it can be consumed by any downstream pipeline.

Critically, all of that is auditable. Every quarantine action, every policy evaluation outcome, and every SBOM generated through SCS is logged, timestamped, and tied to the artifact in question. So your audit trail doesn't just tell you who accessed what; it tells you what the security posture of every artifact was at the time it was accessed.

Seeing it in action: On any artifact's detail page, you'll find dedicated tabs for security and supply chain data:

• SBOM tab - Full bill of materials including dependency lists, software suppliers, and package managers (requires the SCS module)
• Vulnerabilities tab - Security test results from STO scans (requires the STO module)
• Deployments tab - Which environments this artifact has been deployed to and how many instances are running (requires the CD module)

For example, to check the supply chain posture of a specific artifact version using the Harness API, you can query its chain of custody:

# Step 1: List artifact sources registered in SCS
curl -X GET 'https://app.harness.io/v1/orgs/{org}/projects/{project}/scs/artifact-sources' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Harness-Account: YOUR_ACCOUNT_ID'

# Step 2: Get the chain of custody for a specific artifact
curl -X GET 'https://app.harness.io/v1/orgs/{org}/projects/{project}/scs/artifacts/{artifact_id}/chain-of-custody' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Harness-Account: YOUR_ACCOUNT_ID'

The chain of custody shows every orchestration event (SBOM generation, policy enforcement, signing) that has occurred for that artifact, giving you a full security timeline.

Understanding Usage: What's Available Now

Beyond the transactional audit log, Harness Artifact Registry gives you practical tools to understand and manage how your artifacts are actually being used.

The Deployments tab on any artifact shows which environments it has been deployed to and how many instances are running, so you can answer "where is this version live?" without leaving the registry. Cleanup policies let you automatically remove artifacts based on age, usage, tags, or custom rules, keeping your registry lean without manual housekeeping.

You can also attach custom metadata to artifact versions, such as build IDs, Git commit SHAs, approval status, and environment tags. This makes it possible to query and reason about your artifacts in ways that reflect your actual workflow, rather than just generic registry metadata.

Custom metadata in practice: You can tag artifact versions with whatever context matters to your team. For example, after a build pipeline runs:

# Example: Harness pipeline step to push with metadata
- step:
    type: BuildAndPushDockerRegistry
    name: Build and Push
    spec:
      connectorRef: my_ar_connector
      repo: my-registry/my-app
      tags:
        - <+pipeline.sequenceId>
      labels:
        build-id: <+pipeline.executionId>
        git-commit: <+codebase.commitSha>
        branch: <+codebase.branch>
        approved-by: <+pipeline.triggeredBy.email>

Once metadata is attached, you can filter and search artifacts by these fields in the UI, making questions like "which version was approved for production?" answerable without digging through pipeline logs.

The Bigger Picture

What's worth stepping back to appreciate is that auditing and reporting in Harness Artifact Registry isn't a separate module or a dashboard you check once a quarter. It's woven into how the registry works. Every interaction generates a record, every security evaluation produces an insight, and all of it is accessible within the same Harness platform your pipelines already run on.

For teams that are new to centralised artifact management, this is one of the most immediately valuable things you gain. Not just control over your artifacts, but actual visibility into them.

And when the next CVE drops, that visibility is going to matter.

New to Harness Artifact Registry? Check out the quickstart guide to get up and running.