Supported inputs

This matrix is generated from the recognized-input catalog, so it is the exact truth of what a default sbomflow analyze/audit run reads — not a hand-written promise. "Supported" means corpus-tested: the parser has a regression corpus, nothing more. A recognized-but-unparsed input is detected, hashed into the artifact manifest, and surfaced with a stable warning — it is never silently ignored. Anything not listed here is not recognized as inventory in the default scan.

Parsed by default (75 tested)#

Dependency scope and kind#

Every observed component carries two orthogonal scope axes, and SBOMFlow only fills in what the lockfile actually states. Neither is ever guessed.

• dependency_scope — the relationship: direct, transitive, or unknown.
• dependency_kind — how the dependency is used: runtime, dev, or optional. Empty means the lockfile does not record it, not "runtime".

Notes on the honest edges:

• A pnpm transitive package in a v6/v9 lockfile records no kind. Propagating a parent's kind down the graph would be a guess, so it stays empty.
• npm marks a package devOptional when it is reachable through both a dev and an optional edge. npm cannot say which edge installed it, so SBOMFlow records the weaker shipping claim, optional.
• Poetry: a package in main and dev ships, so main wins. An unrecognized group is left empty rather than collapsed into dev.
• When several sources describe one component, runtime wins, then optional; dev is the answer only when every source that stated a kind said dev.
• A dev kind is removed — to no kind, never to runtime — when something observed says the component may ship: a Cargo.toml or package.json that contributed to it declares the same name as a normal dependency (measured: one manifest's devDependency and another's dependency used to merge to dev), or, for Cargo, whose lock states no kind, a dependency edge reaches it from a component that is not itself dev (a dev-dependency tokio also reached through reqwest ships). An edge from the product root says nothing either way. The same rule holds when the dev comes from a supplier SBOM given with --import-sbom (a CycloneDX scope: excluded, an SPDX development or test role): it is removed when the tree's own manifest or lockfile says the component ships, and kept where nothing observed contradicts it.

Kind informs policy only. A dev dependency is still observed, still in the SBOM, and still matched against advisories — it is never dropped from the composition. In CycloneDX the kind maps to the standard scope field (runtime→required, optional→optional, dev→excluded); when the kind is unknown, no scope is asserted at all.

Opt-in scope-aware gating#

By default the release gate blocks on every scope, exactly as before. A gate policy may set:

policy:
  exclude_dev_dependency_findings: true

With that set, a finding whose component was positively observed as a dev dependency no longer blocks the release. It is still reported in evidence-pack.json and issues.json, and the exemption is recorded in release-gate.json under dev_dependency_exempt_ids and shown by sbomflow explain <dir> --gate. A component whose kind is unknown always still blocks — the policy can only waive what the lockfile positively identified.

Recognized but not parsed yet (77 warn, never silent)#

Each surfaces an actionable warning naming the exact file; use the matching opt-in importer where one exists, or review the recorded file manually.

Imported by explicit flag (2)#

These are not auto-discovered by the scan — SBOMFlow reads them only when you pass the flag, so nothing is picked up implicitly. Each is offline, local-file-only, and hashed into the artifact manifest as provenance. Imported components carry imported provenance and never overwrite a locally-observed component; a version conflict is surfaced for a reviewer. What each reader does with every field of a document, measured on a fixture, is in the BOM family census.

Declaration files named by a config key (1)#

A file named under a sbomflow.yaml key is read only because the key names it; the scan never picks it up. The operator produces the file, and SBOMFlow reads it from local disk.

What the walk refuses to read#

• A symlink whose target resolves outside the scan root — file or directory — is never read and never descended. Each one is named by its path inside the root under symlink_outside_root and counted in observation-coverage.json as refused_symlink, so the inventory states what it did not read. The target path is written into no artifact. A symlinked directory that resolves inside the root is not followed either, and earns no warning: its content is read once, under its real path.
• A scan root that cannot be listed is not an empty product. observation-coverage.json reads indeterminate, scan-warnings.json carries coverage_indeterminate, and the summary names the root, says coverage is unknown, and closes with Fix: instead of Next:. The exit code is unchanged (warn, never refuse); --strict=coverage_indeterminate makes such a run fail.

Monorepos and workspaces#

Release one member of a workspace or multi-module repository in one of three ways. Each is supported; the run records which one it was.

1. Scan from the workspace root when one lockfile pins every member. npm, yarn and pnpm workspaces, Cargo workspaces, uv workspaces and Dart pub workspaces keep a single lockfile at the workspace root and none in the members. sbomflow analyze . at that root reads it and records every member's resolved dependencies, attributed to no member: a root run inventories the whole workspace, and SBOMFlow never guesses which service a dependency belongs to.
2. Scan one member by pointing at its directory (sbomflow analyze services/a). The walk never leaves the scan root, so the lockfile at the workspace root is not read. When the member declares dependencies of an ecosystem that no lockfile inside the scan root covers, and a lockfile of that ecosystem sits between the scan root and the repository root, the run says so with the lockfile_above_scan_root warning, naming the lockfile by its path relative to the scan root (../../package-lock.json). The inventory is then partial for that ecosystem: the member's declared ranges are recorded and the versions the lockfile resolves are not. Whether that lockfile pins the member is not determined — the run never opens it — so a directory that is an independent project below a lockfile-holding directory gets the same warning, and a reviewer can accept it there.
3. Give the member its own lockfile, and a per-member run is complete on its own terms: no warning, and the scope below is still recorded.

What the run records about its scope. When the scan root lies below its repository's root, release-record.json carries scan_scope: subtree (the scan root relative to the repository root, POSIX form, e.g. services/a, with subtree_relative_to: repository_root), repository_root_levels_above_scan_root, and lockfiles_above_scan_root — one row per lockfile the warning names, with path, family, levels_above_scan_root, manifests_without_a_lockfile_in_scope and read_by_this_run: false. Which files the run parsed is already recorded per component (source_files) and per input (artifacts in evidence-pack.json). scan_scope is written into the release record only, never into the evidence pack, so it does not move the evidence digest an approval binds to. A run whose scan root IS its repository's root writes no scan_scope key and its record is the one it always wrote; so does a run for which no repository root was found.

Why the subtree is safe to record. An absolute scan root is recorded in target_path as its final component only, so that no artifact publishes the host's directory layout. subtree keeps that promise: it names only directories inside the repository, it is identical on every checkout of the repository, and nothing above the repository root is ever recorded.

How far it looks. The ascent walks the scan root's parents as the path was given (a symlinked scan root is not resolved) and stops at the first directory holding .git or .hg (a .git directory in a clone, a .git file in a worktree), or after WORKSPACE_ASCENT_MAX_LEVELS (8) levels. Above the scan root it only lstats named entries: no file there is opened, no symlink is followed, a directory named like a lockfile is not a lockfile, and an entry it cannot examine stops the ascent. Without a repository root within 8 levels nothing above the scan root is looked for at all, so a per-member scan of an unpacked archive is not warned about: scan such a tree from its workspace root.

Which lockfiles and manifests. Derived from the lockfile parsers in the first table and the manifest rows of the same ecosystem families, never listed by hand. go.mod is itself a parsed lockfile (its requirements are exact versions), so a Go module is never declared without a lock, and go.work is not a parsed input. A lockfile whose family has no manifest row in the catalog is not looked for, because nothing in the scanned tree could be declared without it: bun.lock, deno.lock, dependencies.lock, go.mod, go.sum, packages.config, packages.lock.json, project.assets.json, renv.lock. Among them, a Bun or Deno workspace member (whose package.json or deno.json is catalogued under another family, or not at all) is not reported yet.

What a repeated JSON key does#

JSON lets an object state the same key twice, and a parser keeps the LAST value without a word, so a reader of the file and SBOMFlow could disagree about what it says. Every JSON read SBOMFlow makes is classified, site by site, in a roster derived from the code; a new read with no class fails the build.

• Decisions, trust anchors and records being verified are refused. The gate policy, waivers, reviews and claims read back from a store, match disputes, SSVC context, licence conclusions, a trust policy, entitlements, regime profiles, requirement catalogs, CRA manufacturer inputs, store seals and reissue plans, a batch job's network posture, GitHub and tracker responses under sync --apply, and any sealed, stored or handed-over record being verified, replayed or cut into a passport, supplier package or lifecycle-event export. The document is never read with either value: the command stops with the error a malformed document gets there and writes nothing, or, where the document is one input among several, it becomes a named unusable input.
• Files found in the scanned tree and third-party tool output are reported unreadable, and the scan continues. The input's own unreadable or malformed warning names the file and the repeated key.
• Imported SBOMs, supplier VEX, external scanner reports, the AI manifest, --vulnerability-reviews, the product config, and KEV, NVD and EPSS data keep the last value and warn. duplicate_json_key (duplicate_config_key for the config) names the file, the JSON path and the key; nothing is changed or suppressed. A later verification that replays those reviews refuses them, because it cannot say which of the two it vouched for. A staged feed counts a record that repeats a key as non-conformant and still imports it; a repeat in the feed's wrapper, which could discard a whole list of records, refuses it.
• Files this run wrote a moment earlier, data shipped inside the package, and reads of key names only are not re-checked. The packaged files are proven free of repeated keys, and an object's key names are the same whichever repeated value wins.
• Not covered, by design: a file the scan did not recognise is sampled for worklist signals, and those samples are never echoed into a warning, so a repeated key there is not named.

Compared by digest when sbomflow.yaml names them#

covered_software: names files of the release tree by path, each with the SHA-256 you recorded for it (reference_sha256) from the record that identifies it. These files are not new scan inputs: each is hashed and compared with its recorded digest, and nothing is parsed from it. The path is relative to the tree analyze scans; an absolute path, a host path, or a .. segment refuses the config. A symbolic link anywhere on the path is never followed and reads path_not_regular_file. The result is covered-software.json: identical means the bytes carry the recorded digest, and SBOMFlow reads no scheme rule and decides nothing about re-certification.

Findings from an assessment report (--assessment-findings)#

analyze and audit read one local file named by --assessment-findings PATH, never discovered by the scan: the findings an assessment report listed (a penetration test, a lab evaluation, a process audit, a bug-bounty programme; any assessor), restated by you. The file is {"schema_version": "sbomflow-assessment-findings-v1", "source": {"id", "report_sha256"}, "findings": [...]}, each finding {id, title, severity_as_supplied, component_hint?, first_reported_version?}; its published JSON Schema is listed by sbomflow schema list. The source.id and each finding id are 1 to 64 letters, digits, dot, underscore or hyphen, because they form the finding's review key assessment:<source id>:<finding id>; text is bounded (title 512, severity_as_supplied 128, component_hint 256, first_reported_version 128 characters). The report itself is never read: its digest is looked up among the preserved artifacts the run declares. A file that cannot be read refuses the run with E015; one that is read and is not such a document (not JSON, a repeated JSON key, an unknown top-level or source key, a malformed source id or digest, findings not a list) refuses it with E016. An entry that is not a well-formed finding is skipped and named (assessment_findings_malformed), never repaired. The result is assessment-findings-ledger.json; see outputs.

Per-component support files named by sbomflow.yaml#

component_support.declarations names local JSON files, each relative to the directory of sbomflow.yaml. They are not scan inputs: nothing in the release tree is read for them. Each file (schema_version: sbomflow-component-support-declaration-v1) lists entries that name one component by identifier (a Package URL, or a CPE) with a support_level (actively_maintained, no_longer_maintained or abandoned), an optional support_ends date and an optional note. A declaration matches by identifier equality only; nothing is inferred from registry metadata, dates or names. The result is component-support.json, with a row for every component: not_declared when nobody declared one, and undetermined with the declared value kept when a level or date cannot be read.

component_support.snapshots names local lifecycle snapshots, also relative to sbomflow.yaml and also never scan inputs: an operator snapshot (schema_version: sbomflow-component-support-snapshot-v1, entries of {identifier, cycle, support_ends, source_url, retrieved}) or a public lifecycle API's product document saved locally (schema 1.x; its generated_at, result.identifiers of type purl or cpe, result.links.html and each release's name, eolFrom and isEol are read, nothing else). The run fetches nothing; sbomflow component-support fetch --product <name> --output <dir> is the separate, explicit network step that saves such documents with a manifest of their URL, retrieval time, SHA-256 and the source's licence notice. Each component's lifecycle_snapshot reads maintained, eol, not_mapped or unknown, and is never read from its declared level.

Devices named in identity.devices#

Industrial, energy and building-automation advisories name a device by vendor, product name, model number and firmware range, almost never by a purl. To see what the CSAF advisories you already hand to a run (supplier_vex: or --supplier-vex) state about a device you ship or integrate, declare it, spelled exactly as the advisories spell it:

identity:
  devices:
    - id: rtu-main                  # lowercase letters, digits, . _ -; unique
      vendor: "Example Controls"    # or a list of the spellings advisories use
      model_numbers: ["EC-100-2A"]  # the concrete model; no ? * or \
      firmware_version: "4.2.1"     # as advisories name it; never product.version
    - id: gateway-module
      vendor: ["Example Controls", "Example Controls AG"]
      product_name: "EC-200 Gateway"
      firmware_version: "V2.012"
      relates_to: product           # or the purl of a component of this run

Each entry needs id, vendor, firmware_version and at least one of product_name or model_numbers. Values are kept verbatim: no case folding, no Unicode normalisation, no v stripping. An unknown key, a repeated id, an empty value, surrounding whitespace or a line break, a repeated list entry, or a declared model number holding ?, * or \ refuses the config (E010); it is never repaired. The key is file-only. The result is device-advisory-context.json: observations for a person to read, never findings; see outputs.

Package lists embedded in binaries (opt-in)#

With binary_inventory.enabled and binary_inventory.read_embedded_package_metadata both true, each binary the inventory selected (ELF, PE or thin Mach-O) is also read for the module list its toolchain embedded: Go build info (.go.buildinfo, __go_buildinfo, or the first read/write data section of a PE file) and cargo-auditable's zlib-compressed .dep-v0 JSON. Each declared module becomes a pkg:golang or pkg:cargo component, the Go toolchain pkg:golang/stdlib, each with a binary_embedded_metadata record naming the binary, its SHA-256 and the section. What the binary declares is recorded, never verified. A region that is malformed (binary_buildinfo_malformed) or over a cap (binary_buildinfo_truncated) yields no component from that binary; a universal Mach-O file is not read.

Firmware blobs listed in linux-firmware's WHENCE (opt-in)#

With binary_inventory.enabled, a firmware blob under a lib/firmware/ directory is inventoried by its content hash: no purl, no version, licence NOASSERTION. SBOMFlow also reads the WHENCE index linux-firmware ships, from a lib/firmware/WHENCE inside the scanned tree or, for a lib/firmware directory with none of its own, from the file binary_inventory.firmware_whence names, and records per blob whether the index lists it, as a firmware_whence row on the blob's evidence-pack component. Only the File:, RawFile: and Link: lines are read, as linux-firmware's own install script reads them (basis: source code). License:, Driver: and Version: lines are not read, so a listing never states the terms a blob may ship under, and no purl, version or licence is added. A WHENCE too large to read whole is refused with a warning and yields no rows, so a failed read never makes a blob look unlisted.

Read for declared identity in a preserved original (36)#

These are not scan inputs. When a preserved artifact's original is a file in one of these formats, its own statements about itself are read under the cited published specification and recorded as file_declared_identity — never verified, never a finding, and never read past the identity the specification names. See Runtime and test evidence. The fourth column names the field whose value is a GNU build id; only that field is compared with the build ids of the release's declared firmware images (build_id_match), and no other declared value is ever matched or verified. The last column names the field whose value is the version the file declares about the build it came from; a release run sets it beside the product version the run states (declared_version_context: agree, differ or not_comparable, exact equality after trimming), as context only — never a match, a finding, a warning or a gate input. A name marked "read only when the format's marker is at offset N" is no claim: any other file under it is treated as if no reader were registered for it.

Attestation predicate types read by provenance-check (5)#

These are not scan inputs: an in-toto statement (plain or in a DSSE envelope) is read only when you pass it to sbomflow provenance-check. Every statement's declared type is recorded verbatim at observed.predicate_type, listed here or not. A type not listed is warned as unsupported_predicate and nothing is extracted from it; a statement with no predicateType takes the legacy shape-detected SLSA path.

Matching capability by ecosystem#

This section is generated from three code sources and joined so a single lookup answers "for ecosystem X, is a version range advisory-range-evaluated, equality-only, or is there no advisory source at all?" — a question that was previously answerable only by reading the engine's source.

• parsed — the recognized-input catalog above (what a default scan reads). parsed = a corpus-tested parser; recognized = detected and warned but not parsed yet.
• advisory-matchable — the ecosystem-to-advisory (OSV) map and each component's match_scope. registry means a served advisory ecosystem exists to query; none is an honest statement that no advisory coordinate exists — never a silent miss and never a guessed or cross-ecosystem match.
• range-ordering — the validated version-ordering schemes (currently 15). range-validated evaluates ranges under a differential-proven ordering for that ecosystem; equality-only means only exact-version equality is decidable (the generic fallback never fabricates an order).

The vocabulary is fixed — (parsed / recognized / import-by-flag) crossed with (range-validated / equality-only / match_scope: none). There are no support tiers and no scores. Components brought in with an explicit import flag (see Imported by explicit flag above) carry whatever ecosystem the imported record states and are classified by the same two rows below.

Advisory-matchable ecosystems (16)#

A served advisory (OSV) ecosystem exists for these, so a matched component carries match_scope: registry. Every one is also range-validated: the version-ordering work closed the equality-only gap for every matchable ecosystem, so no matchable ecosystem is currently equality-only.

No advisory source — match_scope: none (22)#

The package identity may still be exact (an official purl type), but no served advisory ecosystem is keyed by these coordinates, so matching is honestly none. Where the version ordering is nonetheless validated (a coordinate gap, not a scheme gap), that readiness is shown — it would take effect only if an advisory source is ever served, via the same coordinated change that enabled the others.

A component here that DECLARES a CPE — an imported SBOM's (Buildroot, Zephyr, OE-core), identity.cpe_map, or a vendored C header the curated table names — can be listed by the opt-in CPE candidate report (scan.cpe_candidates) against a local NVD snapshot. Those are candidates for a human in cpe-candidates.json, never findings, and they do not change match_scope.

A device or module declared under identity.devices — by vendor, product name or model number and firmware version, as industrial CSAF advisories name it — is compared with the CSAF documents the run reads as supplier VEX and written up in device-advisory-context.json. That is context only: never a finding, never a supplier VEX binding and never a match_scope.