Conversation
GHSA's own severity vocabulary is LOW/MODERATE/HIGH/CRITICAL, not LOW/MEDIUM/HIGH/CRITICAL. OSV.dev passes GHSA's database_specific.severity through verbatim, so a real advisory (e.g. GHSA-29mw-wpgm-hmr9, a lodash prototype-pollution CVE) reports the literal string "MODERATE". Every downstream table in static_patterns_supply_chain.py (_SEVERITY_ORDER, _osv_severity_to_app, _SEVERITY_CONFIDENCE) only recognises the app's own four-level vocabulary, so an un-normalized "MODERATE" fell through all of them to the LOW default. Normalize it once, at the boundary where the raw external string is read. Signed-off-by: Udaya Tejas <udayatejas2004@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #587.
Impact: silent-wrong-result
Who reaches this: any user of the CLI or MCP
scan_skillentry point that scans a skill whosedependency manifest (
requirements.txt,package.json+ lockfile, etc.) pins a package versionwith a known GHSA advisory, via the
SC4supply-chain rule's OSV.dev lookup insrc/skillspector/nodes/analyzers/osv_client.pyandstatic_patterns_supply_chain.py.Triggered when: OSV.dev reports a
database_specific.severityof"MODERATE"for the advisory —GHSA's own severity scale, not
"MEDIUM". Confirmed live againstapi.osv.devright now (see thelinked issue for the exact query and response).
_severity_from_vuln()passed that string throughunmodified, so
_SEVERITY_ORDER,_osv_severity_to_app(), and_SEVERITY_CONFIDENCEinstatic_patterns_supply_chain.py— which only recognizeLOW/MEDIUM/HIGH/CRITICAL— allfell through to their
LOWdefault.What the user observes: the
SC4finding for aMODERATE-severity advisory is reported atSeverity.LOW/ confidence 0.6 instead ofSeverity.MEDIUM/ confidence 0.7, with no error or logline indicating anything was downgraded.
Fix
Normalize
"MODERATE"to"MEDIUM"once, at the boundary in_severity_from_vuln()where the rawGHSA/ecosystem severity string is read, so every downstream table keeps working against the app's
own four-level vocabulary.
Tests
Added
tests/unit/test_osv_client.py::TestSeverityFromVuln::test_ghsa_moderate_normalizes_to_medium,::test_ecosystem_specific_moderate_normalizes_to_medium, and an end-to-endTestQueryBatch::test_batch_query_ghsa_moderate_normalizes_to_mediumthat mocks the real OSV.devHTTP response shape (
database_specific.severity: "MODERATE") and assertsquery_batch()returnsseverity == "MEDIUM".Negative control: reverted
src/skillspector/nodes/analyzers/osv_client.pyto its pristine stateand re-ran the three new tests without the fix:
With the fix restored, all three pass (
3 passed), confirming the asymmetry. Also ran the fulltests/unit/test_osv_client.py(36 passed) and the supply-chain SC4 tests intests/unit/test_patterns_new.py(84 passed) with no regressions.ruff check,ruff format --check, andmypyare clean on both changed files.Signed-off-by: Udaya Tejas udayatejas2004@gmail.com