Skip to content

Give the open source scan something to inventory - #26

Merged
Manushpm8 merged 1 commit into
mainfrom
oss-inventory-lock
Oct 8, 2026
Merged

Manushpm8 merged 1 commit into
mainfrom
oss-inventory-lock

Conversation

@Manushpm8

Copy link
Copy Markdown
Collaborator

Three PLC tasks are blocked on one cause: nSpect's OSS inventory for this program is empty. Consumed OSS Licenses needs package names to associate the OSRB bug with, OSS Vulnerability Scanning needs the dashboards, and Create SBOM needs Package Details to certify. All three have nothing to read.

The scans are not failing. Both registered branches report Detect status: SUCCESS, Scan Status: SUCCESS, fetch 9.3 MB, and have re-run cleanly several times. Inventory Status: UPDATE_INITIATED turns out to be the state the nSpect API documentation itself shows in its example response, not a stuck job.

The cause is ours. Per ProdSec's "Why is my nSpect vuln report empty", a Python project is inventoried from a lock file, and this repository has none: dependencies are declared as ranges across six pyproject.toml files, and the engine resolves its own through setup.py, which a static parser cannot read.

This adds a uv workspace root to the top level pyproject.toml and commits the resulting uv.lock, resolving 147 packages. The root declares no build backend and publishes nothing, and no package installs from the lock, so nothing about the five distributions changes.

This is the fix that worked on the predecessor client, where it took the inventory from 0 packages to a full one and let the same three reviews complete.

One honest trade, recorded rather than hidden: uv lock resolves every extra including test, so the inventory will list more than a user installs. Broader than shipped is the safe direction for a scan, but a reviewer should know the SBOM is not the runtime dependency set.

Gates: hygiene, ruff, root 255, client 1928, engine 2500, all passing.

After merge the program needs one rescan for the inventory to populate.

🤖 Generated with Claude Code

nSpect reports this program as having zero open source components, so
the consumed licence review, the vulnerability review and the version
SBOM all have nothing to work from. The scans themselves succeed; the
inventory is empty because a Python project with no lock file is read as
having no dependencies, and this repository had none. Its dependencies
are declared as ranges across six pyproject files, and the engine builds
through setup.py, where a static parser cannot see them.

A uv workspace root resolves all five packages together, with their
extras, into uv.lock. The root builds no distribution and nothing
installs from the lock, so no published package changes. The same fix on
the predecessor client took its inventory from zero to a full one.

The lock resolves every extra, including test, so the inventory will be
broader than the set a user installs. That is worth stating rather than
trimming: a scan that sees more than ships is the safe direction.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Manush Murali <manushm@nvidia.com>
@Manushpm8
Manushpm8 merged commit 4cfbcd1 into main Oct 8, 2026
12 checks passed
@Manushpm8
Manushpm8 deleted the oss-inventory-lock branch October 8, 2026 23:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant