Skip to content
Craftifact

CRA-relevant supply-chain workflows

How to map Craftifact artifact, SBOM, vulnerability, access, backup, and API workflows to CRA-relevant technical preparation.

Use this guide as a workflow map for technical preparation around CRA-relevant supply-chain evidence. It is not legal advice, does not make a compliance decision, and does not replace product risk assessment, vulnerability disclosure ownership, statutory reporting, or update delivery to users.

The goal is narrower: keep release artifacts, SBOMs, vulnerability context, access controls, and operational continuity information connected enough that your own CRA preparation and audit-support workflows have reliable technical inputs.

Quick path

  1. Identify the release artifacts or OCI digests that belong to the software version you are reviewing.
  2. Attach CycloneDX SBOMs to those subjects or let Craftifact generate them.
  3. Review dependency and component visibility from the effective SBOM.
  4. Review vulnerability findings, scan state, and freshness before treating the result as current.
  5. Record suppressions only with narrow scope, expiry, and a rationale another reviewer can understand.
  6. Verify access through RBAC, groups, robot accounts, and scoped tokens.
  7. Use APIs to resolve artifact IDs, upload SBOMs, retrieve persisted vulnerability reports, and export technical evidence bundles for explicit subject sets.
  8. Use backup and restore documentation as operational continuity context for the repository data behind those workflows.

Evaluator checklist

Use this section when you need to answer evidence questions about used dependencies, known vulnerabilities, licenses, suppressions, or access for a concrete release. Apply each item to one concrete release, artifact set, or OCI digest set.

  • Release subjects: identify the exact package artifacts or OCI digests in Browse and record the release set you reviewed. Keep release membership, support periods, and product-risk decisions in your own release record; Craftifact evidence exports work from explicit package artifact and OCI subject sets.
  • SBOM coverage: check whether each subject has an uploaded or Craftifact-generated SBOM and whether processing is ready. Craftifact supports CycloneDX JSON today, with generated SBOMs for selected hosted Maven and OCI content.
  • Component review: use Browse -> detail panel -> Insights -> Dependencies for the components declared by the effective SBOM. Treat broader repository searches as context, not as proof that a release set is complete.
  • Vulnerability state: use Findings -> Vulnerabilities to review severity, KEV, EPSS, scan state, and freshness. Pending, failed, invalid, skipped, or stale states require follow-up.
  • Suppression rationale: review active suppressions for scope, expiry, and rationale. A suppression preserves a triage decision; it does not prove that the risk is legally acceptable.
  • Access and automation: review RBAC, groups, robot accounts, token scopes, and identity-provider setup for the repositories behind the release workflow. Customer-side access review and release acceptance remain outside Craftifact.
  • Policy decisions: use license policies, pull gates, held artifacts, Fast-track decisions, and the decision log where those policies are configured. These signals support release review and can be included as technical evidence context where Craftifact has captured them.
  • Continuity context: include backup and restore boundaries when repository availability or recovery expectations matter to the evaluation. Backups support continuity; they do not prove vulnerability handling by themselves.

Craftifact can store and export technical evidence bundles for explicit package artifact and OCI subject sets. Keep release membership, product-risk decisions, legal conclusions, and formal release acceptance in your own review system, and use Craftifact as the source for artifact, SBOM, finding, access, policy, and technical evidence inputs.

1. Identify release subjects

Start with the exact package artifacts or OCI digests that make up the release under review. Avoid broad repository-level claims when the real question is about a concrete version, image, or digest.

In Craftifact, use Browse to inspect known artifacts and OCI content. If automation needs the package artifact identifier before an SBOM upload or report lookup, use the Artifact lookup API to resolve the artifact_id from repository-scoped coordinates, path, filename, or digest.

Keep your external release record separate from Craftifact when it needs product-level metadata such as support periods, customer availability dates, or product risk decisions. Craftifact provides the artifact and supply-chain data layer, not the whole product-release governance system.

2. Attach or generate SBOMs

For CRA-relevant preparation, the important technical step is that each reviewed subject has a usable SBOM in a common machine-readable format. Craftifact supports CycloneDX JSON.

Use Generate SBOMs with client tools for the practical package and OCI workflows:

  • Maven and Gradle can often publish a CycloneDX sidecar.
  • Poetry, Twine, npm, and OCI workflows usually publish first and upload the SBOM afterward.
  • Craftifact can generate SBOMs for supported hosted Maven and OCI content.

For automation, keep the exact request contract in the SBOM upload API. The upload target should be one package artifact_id or one OCI digest plus repository.

3. Review components

After SBOM processing completes, use Explore dependencies to inspect the components declared by the effective SBOM.

The most reliable path starts from the concrete subject:

  1. Open the artifact, OCI tag, or OCI digest in Browse.
  2. Use Insights -> Dependencies in the detail panel.
  3. Review the subject-specific Dependencies view.
  4. Use consumer and findings handoff links only when you need broader context.

This keeps component review tied to the exact artifact or image you are evaluating.

4. Review vulnerabilities and freshness

Use Review vulnerability findings when the subject has an effective SBOM and you need vulnerability context.

Before using the result in an audit-support workflow, check:

  • whether the scan is ready, pending, failed, invalid, skipped, or stale,
  • whether generated SBOM data or vulnerability database data is marked stale,
  • whether priority signals such as KEV or EPSS were available when the result was produced,
  • whether active suppressions change the visible risk picture.

Automation can read the same subject-scoped report through the SBOM vulnerability report API. Treat pending, failed, invalid, skipped, or stale states as context that needs follow-up, not as evidence that no relevant issue exists.

5. Document suppressions narrowly

Suppressions are useful only when they preserve the reasoning behind an accepted or deferred finding. Use them for documented triage decisions, not as a permanent hiding mechanism.

For CRA-relevant preparation, a suppression should have:

  • the narrowest practical scope,
  • an expiry date,
  • a rationale that explains why the risk is accepted, deferred, or not applicable,
  • enough context for a later reviewer to understand the decision without asking the original author.

Suppression actions require findings-management permissions. The vulnerability findings guide explains the UI flow and permission boundary.

6. Verify access and automation credentials

CRA-relevant evidence is weaker if repository access is unclear. Review who can publish, read, administer, and automate access to the repositories behind the release workflow.

Use these documentation paths:

When automation retrieves artifact, SBOM, or vulnerability data, prefer scoped robot-account tokens over personal credentials.

7. Use APIs and exports for audit-support workflows

For repeatable evidence collection, use APIs where possible instead of screenshots:

  • Artifact lookup API resolves existing package artifact IDs from repository-scoped coordinates or file attributes.
  • SBOM upload API uploads CycloneDX SBOMs and binds them to one package artifact or OCI subject.
  • SBOM vulnerability report API reads the persisted vulnerability report for one SBOM-backed package artifact or OCI subject.
  • Evidence snapshots API creates technical evidence snapshots for explicit package artifact and OCI subject sets.

When a reviewer needs a downloadable bundle for an existing snapshot, export it through GET /api/evidence/snapshots/{snapshot_id}/export/. When the reviewer needs a fresh single-subject snapshot from the current Browse or Dependencies selection, create it with the UI action. Craftifact opens the new snapshot in the Evidence view, where the reviewer can download the bundle. Suppression actor, rationale, and scope fields are capture-time opt-ins. Leave them off for least-privilege evidence; include them only when the reviewer has findings:suppress for every selected repository and intends those values to be visible to later snapshot viewers. AI-assisted workflows can use MCP for evidence gathering with mode=evidence_review and the craftifact_collect_evidence_snapshot prompt.

Use exported bundles when an external audit-support workflow, release archive, or reviewer needs a portable copy of Craftifact’s technical evidence. The bundle is technical evidence for the explicit subject set, not a statement that the set is the complete product release or that a regulatory obligation is satisfied.

8. Keep operational continuity in view

Backups do not prove vulnerability handling by themselves, but they matter for continuity around the repository data that supports those workflows.

Use Backup and restore to understand current backup availability, defaults by plan, manual backups, restore paths, and restore limits. Include those boundaries in your own operational evidence when repository availability and recovery expectations are part of an evaluation.

Boundary checklist

Use Craftifact for the technical supply-chain layer:

  • artifact and OCI subject identification,
  • CycloneDX SBOM upload, binding, parsing, and selected generated SBOMs,
  • component visibility from SBOM data,
  • vulnerability findings with freshness state and suppressions,
  • RBAC, groups, robot accounts, and scoped tokens,
  • APIs for repeatable artifact and vulnerability workflows,
  • technical evidence snapshots and exports for explicit package artifact and OCI subject sets,
  • backup and restore context for repository continuity.

Your organization still owns product-level security engineering, legal interpretation, release acceptance, coordinated disclosure policy, mandatory external processes, and user communication. No single artifact repository workflow produces the full regulatory outcome for a manufacturer.