Repository navigation
fix(scan): a source nobody configured is not a source that failed - #57
Merged
Merged
Conversation
Without VULDB_API_KEY the VulDB collector refused every target, and the scan reported each refusal as a failure: "results … are incomplete" per target, "VulDB answered for none of the N targets" at the end, and never "no CVEs found", which needs every source to have answered. Over HTTP the refusal sat in `errors` of every scan. The default configuration could never give an all-clear. A fixture in conftest.py hid it: it replaced the VulDB collector, in the CLI and the API, with one returning nothing in every test. It now only removes the key from the environment, which is how most installations run; seven existing tests failed that way before this change, as did two of the new ones. VulDB is now queried only with its key, by the CLI and the API alike, the silent-sources summary counts only the sources asked, and a scan says once that VulDB was not asked and how to add it. A real scan of a product with no CVEs now ends in "no CVEs found". The collector still refuses before any request without its key, as the NIS2 document says. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Merging this PR will not alter performance
|
codecov/patch on #57: the API's branch that adds VulDB when its key is set had no test, since every test runs without the key. A scan with VULDB_API_KEY set, VulDB answering an empty result, now asks it once from the CLI and once from the API, and prints no line about the key. Removing the branch fails it. `vuldb._real_fetch_cves` and the line of test_vuldb.py that used it go: they existed only to undo conftest's replacement of the collector, which is gone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ource-is-not-a-failed-one # Conflicts: # CHANGELOG.md
|
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.



The defect (audit finding PR-05)
Without
VULDB_API_KEY, which is how most installations run, no scan could end in an all-clear:"no CVEs found" needs every source to have answered, so it never appeared. Over HTTP, VulDB's refusal sat in
errorsof every scan.A mock hid it. The autouse fixture
vuldb_offline_by_defaultreplaced the VulDB collector, in the CLI and the API, with one returning nothing. Its own docstring said why: otherwise the missing key "breaks every test that assertserrors == []".Fix
_scan_targetand API_scan_onequery VulDB only when its key is set.ℹ️ VulDB was not asked: set VULDB_API_KEY to add it to the scan.VULDB_API_KEYfrom the environment. This is isolation, not a mock.vuldb.fetch_cvesstill refuses before any request without a key. The NIS2 evidence test checks this.Tests (TDD, no mocks in the new file)
test_collector_failures,test_scan_hardening,test_scan_source_outage), as did the two new behaviour tests. That is the defect in the real configuration.tests/test_scan_unconfigured_source.py. NVD answers from the recordingnvd_no_results.json, MSRC with 404, KEV with conftest's cached empty catalogue. It checks:errorshold the other sources' 503s and nothing from VulDB;test_nis2_evidence.py::test_the_web_scan_asks_debian_and_the_command_line_scan_does_notnow checks what it is about (nodebian_fetchin the CLI scan) instead of the exact old loop line.patchradar scan zzqxnonexistentproduct --days 2now printsno CVEs found in last 2 daysand the one information line.This PR adds an entry at the top of
### Fixed, like #56. Whichever is merged second will need a one-line conflict fixed, which I'll do by mergingmaininto it.🤖 Generated with Claude Code