Filesystem Assets

A filesystem asset is created by analyzing a local directory tree and attaching the resulting SBOM to an app version. Use this path when the software you want to track is a build output, an unpacked archive, a virtual machine root, or any directory of files that does not live inside a container image.

Filesystem Assets in the Anchore Enterprise GUI

The GUI surfaces a filesystem asset once an app version asset add filesystem job completes — it appears in the version’s asset list alongside any other assets, with its type displayed as filesystem. For an ad-hoc upload of a pre-generated filesystem SBOM, use the GUI’s Add Asset → SBOM action with the asset type set to filesystem.

Add a Filesystem Asset with AnchoreCTL

Use app version asset add filesystem to analyze a directory and upload the resulting SBOM. AnchoreCTL runs Syft locally to generate the SBOM, then submits it to Anchore Enterprise as a job.

The directory path is the positional argument. The parent app, version, and asset name are required:

anchorectl app version asset add filesystem ./dist \
  --app my-service \
  --version 1.4.0 \
  --asset cli-binary

The asset type defaults to filesystem, so you typically do not need to set --type explicitly.

Set SBOM Document Author and Supplier

The generated SBOM document carries an author and a supplier field that downstream consumers (and SBOM quality checks) use to identify provenance. Both default to unknown. Set them with --author and --supplier:

anchorectl app version asset add filesystem ./dist \
  --app my-service \
  --version 1.4.0 \
  --asset cli-binary \
  --author "Platform Team <[email protected]>" \
  --supplier "Example Corp"

--author follows the common Name <email> form. Both fields are free-text; pick values that match what your organization publishes for software provenance.

Annotate the Asset

Attach build metadata at create time with --annotations. The full merge and clear semantics are documented under Add Assets to an App Version:

anchorectl app version asset add filesystem ./dist \
  --app my-service \
  --version 1.4.0 \
  --asset cli-binary \
  --annotations "owner=platform-team,commit=a3f7c01"

Wait for the Job to Complete

By default the command submits the job and returns immediately, leaving you to track progress through the asset list or job endpoint. To block until the job reaches a terminal state — useful in CI pipelines where you want the job’s outcome to gate later steps — add --wait:

anchorectl app version asset add filesystem ./dist \
  --app my-service \
  --version 1.4.0 \
  --asset cli-binary \
  --wait

Add a Filesystem Asset with the API

Filesystem analysis happens on the AnchoreCTL host; only the resulting SBOM is sent to Anchore Enterprise. Under the hood, AnchoreCTL uploads the SBOM through the same job type used for any externally produced SBOM:

• POST /apps/{app_id}/jobs/add-sbom-asset — the multipart request carries the asset name, the parent version ID, the SBOM payload, and an asset_type of filesystem.

The full request and response schemas are in the API browser; search for the App Jobs tag. If you are integrating directly with the API rather than using AnchoreCTL, you are responsible for running an SBOM generator (Syft or equivalent) against the filesystem and submitting the resulting document.

A few conventions worth knowing as you call this endpoint:

• Job state transitions are documented in How It Works.
• The job response carries a job_id; poll GET /apps/{app_id}/jobs/{job_id} to track status.
• Cross-account requests are scoped via the x-anchore-account header or, from AnchoreCTL, the ANCHORECTL_ACCOUNT environment variable. See Account Scoping for the full mechanism.