Skip to content
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

New feature: Filter invalid/unwanted vulnerabilities #2

Open
OSSIndex-Admin opened this issue Feb 23, 2016 · 0 comments
Open

New feature: Filter invalid/unwanted vulnerabilities #2

OSSIndex-Admin opened this issue Feb 23, 2016 · 0 comments

Comments

@OSSIndex-Admin
Copy link
Contributor

There are various situations where the user will want to filter out reported vulnerabilities, for example in the case of a false-positive, or if a particular vulnerability does not affect the user's product due to bug/implementation specifics.

It should therefore be possible to filter these bugs from the view. This could perhaps be done in the following way:

  1. User spots a vulnerability in the Error List that is to be filtered
  2. Right click the vulnerability to get the context menu
  3. Select "Hide vulnerability"
  4. Presto, the vulnerability will be filtered from the view for this, and all subsequent user sessions

It should also be possible to undo filtering. Perhaps in the following way:

  1. Click the "Tools->Options..." menu item, the options dialog will appear
  2. Expand the "Audit.NET" element on the left
  3. Click the "Filter List" sub-item, which will display a list of filtered vulnerabilities
  4. Select the listed vulnerability
  5. Click the "remove" button
  6. Click "OK" to close the options dialog and save the changes

Initially the filter will work on a Visual-studio wide basis. If there is desire at a future time we might be able to add a project-specific filter.

The filter file should be stored in a user-friendly file format that makes it possible to not only edit by hand, but copy to a different installation of Visual Studio to share filters with different users. The importer should be robust enough to handle corrupt files. XML or JSON would be likely candidates for the file format. The file should store enough information to work as a filter and provide user friendly information for the list, which means at least the following:

  • vulnerability id (used for the filter)
  • package name
  • vulnerability title
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant