(I've been meaning to raise this to discuss for a few months and we're getting closer to v2 so I'm making a public issue to force my own hand 😄)

Currently when I run the scanner without any config it will include scanning the commit if it sees its in a git repository which generally it always will be for me as everything I do that involves code and dependencies uses git for source control, however most of the time these git repositories will not be public because they're proprietary applications meaning there will never a result of scanning the commit and arguably that's a bit of private data being sent to the API (which unlike e.g. the dependency tree, will never give a positive result).

My understanding is that generally there are two main criteria for git scanning to be useful:

1. the codebase is public (meaning its commits can be indexed, and whatnot)
2. the codebase is using a very "commit driven" language like C++ (i.e. while possible for other ecosystems to have commits related to vulnerabilities, it's far more likely in just about every ecosystem that version numbers/semver will be being used instead)

Given the number of ecosystems the scanner supports and frankly just how much better/easier non-git based vuln info is to handle right now, I strongly suspect more than half of the uses of the scanner are in a context where at least one of those conditions are not true meaning this current default is not useful for most people and arguably a little negative (though I admit it's not a huge privacy concern).

Personally I'd prefer if this was opt-in (i.e. --check-git or --include-git), though maybe there's another way to try make this more automatic - for example, maybe it would make sense for the scanner to fallback to checking git if it doesn't find any other lockfiles, or to make this managed through a config property so codebases could opt-in (i.e. open source repos could create an osv-scanner.toml with a marker effective telling the scanner "hey this is a public repo so feel free to be more 'aggressive' in what you check")