A dependency (aiohttp) is flagged with a moderate rated CVE

[BreadGenie]

• Related discussion: pip-audit flagging aiohttp: https://github.com/advisories/GHSA-rwqr-c348-m5wr aio-libs/aiohttp#6801

It seems like aiohttp is flagged with a vulnerability (which seems like a false positive) and we might want to either add it to the allowed dependencies (since there is no new release) or wait for NVD to remove the CVE from their database (like Snyk and pip-audit did) to get the tests to pass.

[terriko]

I saw it appear and then disappear in snyk and assumed NVD had updated or aoihttp had. This is more interesting than I expected.

I think this particular one will likely resolve itself in a few days (most of them do once they've been reported to NVD), but it's a good time for us to discuss what we want best practice to be with disputed or incorrect CVEs:

1. Adhere directly to what NVD provides. (current behaviour)
2. Provide our own revocation/triage list as triage info, use that in CI to address immediate concerns for our own dependencies.
3. Provide our own revocation/triage list as a data_source, try to keep it up to date as things come up.
4. Provide the ability for users to maintain their own revocation/triage lists and load them as cvedb data_sources. Similar to what we already do with triage but making it apply across all scans.

Let's start with making a triage file for CI and using it to resolve the immediate issue with aoihttp so that CI can function as expected while we wait for this to be resolved.

But we should have a bit of an architecture discussion about whether we want optional data sources and how to ensure that any optional data source we provide is maintained. Maybe during the weekly meeting?

[terriko]

Okay, i started a PR for this

• test: Add triage to requirements test to address aiohttp disputed cve #1746

Setting up the triage and changing the test to use it as a merged report was no problem, but it turns out that the test relies on the console text, which says there were CVEs found even if we then ignore them. I need to think about how to fix that text or make the test rely on something else.

[terriko]

Some discussion notes from the gsoc meeting:

• It's possible that triage can already be specified through env variables / config files. (maybe double-check how this works?)
• The triage I made for test: Add triage to requirements test to address aiohttp disputed cve #1746 could in fact be re-used by anyone, and that's true of any triage we maintain for ourselves for CI, although it may not be very obvious to others how to do that (maybe provide a guide? Part of Docs: Add triage guide #1747)
• Adding data sources should be possible but no one was jumping up with enthusiasm so it's probably just a feature request idea to file until someone actually needs it.

I'm going to keep working on fixing #1746 so it fully solves our CI issue and we'll likely leave it at that for now. I've filed a related improvement on how we report "ignored" CVEs right now:

• Improve output when CVEs are set to "Ignore" or "Mitigated" #1752

[terriko]

Coming back to this: I spent a bit of time reading through the latest updates on aio-libs/aiohttp#6801 and it looks like this is on track to be fixed in NVD.

I'd been planning to remove the triage file when it was no longer needed, but upon further reflection I feel like having the triage file set up in CI and available for us to update as needed is probably really useful for the next time something comes up, and it also makes a nice real-life example showing other users how to use a triage file. So I'm going to go ahead and close this bug since I don't intend to take any further action, though I guess we might want to peek at it a few more times to see when the issue gets resolved just out of curiousity. But you can do that with a closed issue too!