-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider making "skip git" the default in v2 #1277
Comments
Discussed offline and agreed that we should make it disabled by default |
This generally makes sense to me that we shouldn't need to scan the git hash of projects generally. However, we do want C/C++ scanning to work out of the box for third party / open source dependencies. Should we look at still accounting for git repos if they live inside one of these directories by default? osv-scanner/pkg/osvscanner/osvscanner.go Line 85 in 3702c3b
|
On an aside, that list includes |
Agree with not enabling scan the base git repository by default, though I think scanning submodules git hashes, and hashes under vendored lib names is still valuable to enable by default? |
(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:
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 anosv-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")The text was updated successfully, but these errors were encountered: