PS Product SecurityKnowledge Base

📦 Local Artifact Repository Scanning and JFrog Xray

Intro: Build output is part of the attack surface. If you only scan source code and container images, but ignore packaged artifacts, you miss a practical layer of software supply chain risk.

What this page includes

  • what “local artifact storage” means in real teams
  • key risks in post-build artifacts
  • tool choices for local and central repository scanning
  • a practical local scan flow using Trivy, Syft, and Grype
  • what JFrog Xray is, where it fits, and how Watches and Policies work

What people usually mean by “local artifact storage”

This phrase can mean different things. In practice it is usually one of these:

  1. a local build output directory such as dist/, build/, target/, out/, or exported packages;
  2. a local package or binary cache created by the build tool;
  3. a local Docker registry or file share where build outputs are staged before publishing;
  4. a central artifact manager such as Artifactory or Nexus where those artifacts are pushed after build.

Security review becomes easier if you separate these two questions:

  • how do we scan the artifact before publication?
  • how do we govern and monitor the artifact after publication?

Why post-build artifacts matter

A build artifact can carry risk even when the source repo looked clean.

Typical risks:

  • vulnerable dependencies included in the final package;
  • secrets accidentally packed into archive files;
  • unsafe configuration files bundled into release ZIPs or JARs;
  • license and compliance surprises only visible in the built artifact;
  • malicious or tampered artifact replacement in a local repository;
  • stale artifacts kept around and consumed long after they should have expired;
  • lack of provenance: nobody can prove which workflow built the file.

Common artifact types worth scanning

  • container images
  • JAR / WAR / EAR
  • wheel / egg / Python build outputs
  • node_modules packaged into archives
  • ZIP / TGZ / TAR build bundles
  • binaries and installers
  • SBOM files already generated by build

Practical tool choices

Best for local directories and quick post-build checks

  • Trivy
  • Grype
  • Syft for SBOM generation

Best for centralized binary governance

  • JFrog Xray with Artifactory
  • similar classes of tooling can exist in other repository managers, but Xray is the best-known example in this category

Typical pairing that works well

  • local CI scan before publish with Trivy or Grype;
  • central policy and repository watch in Artifactory/Xray after publish.

Fast developer or CI flow

  1. generate SBOM from the artifact or build output;
  2. scan the directory or SBOM;
  3. fail for critical rules you actually enforce;
  4. publish only if the artifact meets the policy.

Central repository flow

  1. publish artifact into Artifactory;
  2. let Xray index and analyze it;
  3. attach repository or build to a Watch;
  4. trigger policy violations, tickets, dashboards, or block-download rules if used.

Practical local example using Trivy

Trivy is one of the most common tools for quick local scanning because it can scan:

  • filesystem directories;
  • container images;
  • repositories;
  • SBOM files.

See: snippets/artifacts/trivy-local-artifacts.sh

Scan a local build directory

trivy fs   --scanners vuln,secret,misconfig   --severity HIGH,CRITICAL   --format table   ./dist

JSON output for CI ingestion

trivy fs   --scanners vuln,secret,misconfig   --severity HIGH,CRITICAL   --format json   --output trivy-dist-report.json   ./dist

SARIF output for code-scanning style upload

trivy fs   --scanners vuln,secret,misconfig   --severity HIGH,CRITICAL   --format sarif   --output trivy-dist-report.sarif   ./dist

When this is useful

  • release ZIP or TGZ produced by build;
  • target/ or dist/ output from CI;
  • staged package folder prior to upload.

Limits of local-only scanning

A local scan does not replace central repository governance. It tells you what you are about to publish, not how it is reused later, what other repos consume it, or whether later-introduced intelligence should change its risk status.

Practical SBOM-first flow with Syft and Grype

See:

Generate an SBOM

syft ./dist -o cyclonedx-json > sbom.cdx.json

Scan the SBOM

grype sbom:sbom.cdx.json -o table

Why this flow is valuable

  • it decouples inventory from policy;
  • you can archive the SBOM as release evidence;
  • another tool can rescan the same SBOM later with newer vulnerability intelligence.

Risks specific to artifact repositories

When artifacts are stored centrally, additional risks appear:

  • overwritten or mutable tags;
  • repo-level permissions too broad;
  • developers can publish directly to prod repo without review;
  • build info is missing or incomplete;
  • no retention policy, so old vulnerable versions linger;
  • no provenance or signature verification;
  • no policy attached to the repo, so analysis exists but no one acts on it.

What JFrog Xray is

JFrog Xray is the analysis and policy engine tightly integrated with Artifactory. In practical terms, it is most useful when you already store artifacts, images, builds, or release bundles in JFrog and want:

  • vulnerability analysis;
  • license and compliance policy;
  • Watches and Policies tied to repositories or builds;
  • violation reporting and dashboards;
  • build-to-build comparison and impact analysis;
  • SBOM-related workflows.

What Xray is good at

  • central visibility across repositories and builds;
  • policy-driven governance after publication;
  • understanding “which repos/builds are affected?”;
  • reporting and notifications for repository or build policy violations.

What Xray is not best at

  • ultra-lightweight local developer scanning on a laptop with no repository manager;
  • very fast single-directory checks where a local tool like Trivy is simpler.

Xray core objects you should know

Policy

Defines the rule. Examples:

  • block critical CVEs;
  • notify on GPL license;
  • alert on secrets or exposures where supported in your tier.

Watch

Attaches policies to resources. Examples:

  • local Maven repo;
  • Docker repository;
  • build pattern;
  • project scope.

Violations

The output you act on when a policy condition matches.

Reports / scans list

Where teams view repository, build, or artifact-level findings and status.

Typical Xray workflow for a local repository in Artifactory

UI-oriented flow

  1. Publish artifacts to an Artifactory local repository.
  2. In Xray, create a Policy for vulnerability and/or license rules.
  3. Create a Watch.
  4. Attach the Watch to the relevant local repository or build resources.
  5. Apply on existing content if you need a backfill scan.
  6. Review Violations and Scans List.
  7. Wire notification, ticketing, or block-download behavior according to policy.

Practical meaning

If your build uploads company-maven-local or company-docker-local, a Watch can attach policy to that repository, so newly indexed content starts producing violations and reports.

JFrog CLI examples

The exact command set can vary by JFrog CLI version and licensed capabilities, so treat these as common working patterns rather than a promise that every older deployment has every command.

See: snippets/artifacts/jfrog-xray-rest-and-cli-examples.sh

Configure CLI

jf config add art-prod   --url https://artifactory.example.com   --user "$JF_USER"   --password "$JF_PASSWORD"

Audit current working directory dependencies

jf audit

Audit with JSON output

jf audit --format=json > jf-audit-report.json

Docker image scan pattern

jf docker scan my-app:1.2.3

Build info publish, then analyze centrally

jf rt build-collect-env my-build 42
jf rt build-publish my-build 42

The main idea here is that local CLI checks and central Xray analysis complement each other.

How to think about “local artifact scanning” defensively

Before publish

Use local scanning to answer:

  • are we about to publish something obviously risky?
  • did the build package a secret or a vulnerable dependency?
  • did we produce a useful SBOM?

After publish

Use repository governance to answer:

  • which repos and builds are impacted now?
  • which older artifact versions are still vulnerable?
  • which teams must rotate or rebuild?
  • should download or promotion be blocked?

What used to be common vs what is stronger now

Older pattern Why teams did it Stronger pattern now
scan only source repo easiest starting point scan source, artifact, image, and SBOM
publish artifact first, scan later “when there is time” delivery pressure fast pre-publish gate plus central post-publish governance
keep mutable “latest” packages forever convenient immutable versions, retention, provenance
rely on one scanner output simplicity inventory + scan + policy + repository governance
treat build output folder as temporary and unimportant operational habit treat it as release evidence and a security object

Minimal practical control set

If you want the smallest useful starting point:

  1. generate an SBOM for release artifacts;
  2. scan the build output directory in CI;
  3. fail on a small number of agreed rules;
  4. publish build info;
  5. attach repository or build policy in Xray if you use Artifactory;
  6. review violations and retention regularly.

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.