Do a better job of signaling when audited dependencies come from `pip-audit` itself

[woodruffw]

Raised by @esultanik.

We need to think a bit more about if/how we'd like to do this, but in terms of user experience: some users might find it confusing that running pip-audit (i.e. bare, auditing the current environment) is also likely to audit pip-audit's own dependencies.

This is confusing on two levels:

1. The user might not be expecting those dependencies to be there;
2. pip-audit will occasionally produce findings on its own dependencies, like the recent security advisory on requests.

[CribberSix]

Is this the same case as with the current urllib3 security advisory?

[woodruffw]

Is this the same case as with the current urllib3 security advisory?

I'm not sure, you'll need to be more specific. Can you share the advisory ID?

Edit: and are you using pip-audit in "environment" mode?

[CribberSix]

ID: GHSA-v845-jxx5-vc9f

I suppose not, we are using it as a pre-commit hook without any args.

[woodruffw]

I suppose not, we are using it as a pre-commit hook without any args.

That's the environment mode 🙂

Could you try running with a requirements file or other dependency source instead, and seeing if this reproduces? This may indeed be a false positive from our own dependencies.

[CribberSix]

If I run pip_audit in my local venv (that I use during development - created by poetry), it doesn't flag the above id - it only flags some other ids which I expected (and ignore in the pre-commit hook).

So I guess that means it's not an issue with pip-audit itself, but with my pre-commit hook setup.

[woodruffw]

Yeah, that sounds likely. Are you using pre-commit to run other tasks that might pull urllib3 in?

[CribberSix]

Black/flake8/isort/bandit ... probably the culprit is there. Sorry to bother you with this! I suppose it's one of them. Disregard my comments :D