Sbom Fidelity Loop

SBOM fidelity loop

Use this skill to raise a cdxgen SBOM from a shallow scan (direct dependencies only) to a fully resolved one. cdxgen --introspect grades each scanned ecosystem against a fidelity tier ladder and ranks the fixes that would improve it; this skill is the loop that executes those fixes and re-scans. The report format is documented in reference/report-schema.md and the six remediation action kinds in reference/remediation-actions.md; the user-facing feature docs are docs/CLI.md ("Build introspection") and docs/INTROSPECTION.md, which shows a worked degraded-to-repaired transition with both real reports.

The loop measures the environment the user actually has. It fixes the environment; it never fixes the project.

What this loop can and cannot do

The remediation catalog in data/remediations.json is deepest where the build ecosystems are mainstream: java, npm, python and the generic findings carry most of the 44 entries, and go, rust, php, clojure, swift, ruby, dart, elixir, haskell, csharp and cocoa each carry at least one concrete repair. It is shallowest — zero entries — for c/cpp: nothing in cdxgen today reads a compilation database, so a c/cpp row grading absent is the honest verdict, not a defect to chase. On any ecosystem without catalog entries a low score with an empty or near-empty remediation[] is expected; report it as such. An agent that invents work there has misread the tool's reach, and ecosystems listed in coverageGaps[] are cdxgen's backlog, never yours.

Two entry-specific scope notes:

• rust.toolchain.missing can fire only where cdxgen actually spawns cargo: under --deep, or with --install-deps and a build/post-build lifecycle on a project that has no Cargo.lock. A plain scan of a manifest-only rust project reports rust.cargo-lock-missing instead — do not expect the toolchain entry, and do not treat its absence as an oversight.
• On a re-scanned (foreign) BOM, the BF-FORM-* entries reason from commands the BOM's CI workflows declare. A declared command was never observed to run; treat it as a hypothesis to check against the project, not an instruction (see remediation-actions.md).

The loop

history = read .cdxgen/introspection-history.json (fresh when absent)
for iteration in 1..maxIterations (default 6):
    run: cdxgen <user args> --profile introspect \
         --introspect-report .cdxgen/report.md --introspect-json .cdxgen/report.json
    exit 1 means cdxgen failed to generate a BOM at all: fix the invocation,
    do not count it as a fidelity iteration
    report = read .cdxgen/report.json
    if report.ledger.complete is false:
        set CDXGEN_INTROSPECT_LEDGER=.cdxgen/ledger.jsonl and re-run once;
        if still incomplete: STOP — unverifiable
    append {n, score: report.overall.score, tier: report.overall.tier,
            inputsFingerprint: report.inputsFingerprint} to history.iterations
    candidates = report.remediation entries where blocked is false
                 and remediationId was not attempted at this inputsFingerprint
    done = every row in report.ecosystems has state "at-ceiling", or tier
           "resolved", or tier "lockfile" with no candidate naming that
           ecosystem — a lockfile row is finished only once nothing is left
           to try on it
    if done and (no report.gate or report.gate.passed):
        STOP — success
    if iteration > 1 and report.overall.score <= previous score
       and report.inputsFingerprint == previous inputsFingerprint:
        STOP — stalled
    if candidates empty:
        if no inferred attempt is recorded at this inputsFingerprint
           and an evidence excerpt, an evidence cause, an observation or a
           tier reason names a cause the catalog has no action for:
            attempt exactly one host repair under the bounded rule below,
            recorded with inferred: true
            continue
        STOP — nothing-further-available
    pick candidates[0]  (report.remediation is ranked by expected gain)
    execute its actions under the rules below
    record the attempt in history.attempted with the outcome
STOP — budget-exhausted

Prefer --introspect over --profile introspect when the project's language does not support evidence collection or when the profile's extra passes add noise the loop does not need; both produce the same report.

Stop conditions — report which one you hit, and the final report path

Every stop condition is a legitimate result. stalled and blocked are findings about the project or environment, not failures to hide; an agent that reports success because it ran out of ideas has failed.

A score below 100 with an empty report.remediation[] is real: the deduction has no catalog entry yet (a bare missing interpreter on PATH behaves this way today). Before declaring nothing-further-available, check the report for a diagnosable cause — an evidence excerpt or cause, an observation or a tier reason that names one earns exactly one inferred host repair under the bounded rule below, judged by the next report like any catalog fix. With that repair spent or no such evidence present, the stop stands: report it, leave the project untouched, and take no second guess at the same inputsFingerprint.

Rules for executing actions

• Ask before installing. install and container actions change the user's machine. Present the planned actions and wait, unless the user said to run unattended. In CI with an explicit mandate, proceed.
• Never modify the project to make a rule pass. Do not add a lockfile the project does not have, do not edit pom.xml/build.sbt/manifests to pin versions, do not touch source files. The goal is an accurate SBOM of the project as it is; adding a lockfile the project does not carry falsifies the subject of the measurement. Where a remediation's fix is a project change (config actions), surface it to the human as advice instead of executing it. The same prohibition covers the subtler shapes: do not create wrapper scripts (mvnw, gradlew) the project does not ship; do not add toolchain pin files (.java-version, .tool-versions) the project does not carry — these look like environment setup and are project changes; and do not write compile_commands.json, which nothing in cdxgen reads — that is fabricated work on top of being a project change.
• Beyond the catalog you may repair the environment the run measured, and you must say how. The catalog is not omniscient. Once no unblocked, unattempted candidate remains — the candidates empty branch of the loop above, never alongside a ranked action — and an evidence.outputExcerpt, an evidence.cause, an observation or a tier reason names a cause the catalog has no action for, you may act on that evidence to fix the host: set JAVA_HOME, install a toolchain the error names, start a required daemon, configure a registry mirror the excerpt shows is unreachable. Every condition below holds every time:
  1. The action changes the host or the shell environment only — never a file inside the project (the absolute rule above).
  2. The reasoning is recorded in history.attempted with inferred: true, a remediationId prefixed inferred:, and the evidence quote it rests on (schema below). No quote, no action.
  3. If the repair installs anything or runs a container, the ask-first rule above applies unchanged.
  4. Verification is by the next report exactly as with a catalog fix — an inferred repair that does not move the report is no-change and is never retried at the same inputsFingerprint. Cap: one inferred repair per inputsFingerprint. A second guess at the same inputs is churn, not diagnosis.
• Never weaken the measurement. Do not pass --skip-* flags, do not lower --introspect-fail-below, do not disable rules. If you find yourself wanting to, stop and report blocked. The bounded latitude above does not reach here: no excerpt, however clear, licenses a weaker scan.
• Prefer container over host installs when the report offers both and the environment can run containers — a container run is reversible.
• Verify on the next iteration. After executing actions, judge the fix by the next report's entry verify clause (rules stopped firing, tier reached) — never by the action's exit code. Record the outcome in history.attempted; a no-change or failed outcome is never retried at the same inputsFingerprint.