Reported issues for supply-chain-guard
Pod holds 5 of 5 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.
Back to supply-chain-guard.
Most discussed
The two documented SBOM commands emit different documents, and every affects reference in the --format sbom one points at a bom-ref that does not exist
README.md lines 209 and 210 present two ways to obtain the SBOM, described as the same artefact:
supply-chain-guard scan ./project --format sbom # CycloneDX 1.6 SBOM with real dependency inventory
supply-chain-guard scan ./project --sbom-output sbom.json # Write SBOM to file separately
They do not produce the same document. Measured on this repository at commit 1a141fe8322345dbd8ec3c449a402eedc3c6d83f (v5.28.1), from the same scan of the same tree:
| command | components |…
Read the thread · 2026-08-22 · closed · 2 comments
Without a lockfile the SBOM version is the dependency specifier minus one character, so 'latest' ships as 'atest' and '^1.2.3' is asserted as 1.2.3
When a project has no package-lock.json, the SBOM generator falls back to the direct dependencies in package.json. A package.json dependency value is a specifier, not a version. The fallback converts it to a version by deleting one leading non digit character:
src/sbom-generator.ts, readPackageJsonComponents():
// Strip semver range operators to get a clean version string
const version = versionRange.replace(/^[^0-9]/, "") || versionRange;
^ and ~ happen to be one…
Read the thread · 2026-08-22 · closed · 2 comments
SBOM drops every licence, every dependency relationship and every bom-ref, all of which the parsed lockfile already carries
The npm lockfile the generator already parses carries a licence for every package and 175 declared dependency edges. None of it reaches the SBOM. Three of the fields most often required of an SBOM are absent from every component the tool emits.
Measured on this repository at commit 1a141fe8322345dbd8ec3c449a402eedc3c6d83f (v5.28.1), node dist/cli.js scan . --format sbom:
| field | in the SBOM | available in package-lock.json |
|---|---|---|
components[].licenses |
0 of 119 | … |
Read the thread · 2026-08-22 · closed · 2 comments
A Python, Cargo or Go project gets a well-formed CycloneDX 1.6 SBOM with zero components and exit 0; a pnpm project gets 7 of 119
The SBOM generator reads exactly two files: package-lock.json and, as a fallback, package.json. src/sbom-generator.ts, generateSbomDocument():
const lockfilePath = path.join(projectDir, "package-lock.json");
if (fs.existsSync(lockfilePath)) {
components = readLockfileComponents(lockfilePath);
}
if (components.length === 0 && fs.existsSync(packageJsonPath)) {
components = readPackageJsonComponents(packageJsonPath);
}
Everything else the scanner supports produces a…
Read the thread · 2026-08-22 · closed · 2 comments
SBOM fallback turns a semver range into a stated version, and strips one character off every non-numeric specifier
Summary
When there is no package-lock.json, the SBOM generator falls back to package.json and turns each declared semver range into what it presents as a component version. The conversion is a single-character strip:
src/sbom-generator.ts, readPackageJsonComponents():
// Strip semver range operators to get a clean version string
const version = versionRange.replace(/^[^0-9]/, "") || versionRange;
components.push({ type: "library", name, version, purl: npmPurl(name,…
[Read the thread](https://github.com/homeofe/supply-chain-guard/issues/199) · 2026-08-22 · closed · 1 comment
## Most recent
The remaining reports are on [the project's issue tracker](https://github.com/homeofe/supply-chain-guard/issues).