-
Notifications
You must be signed in to change notification settings - Fork 29
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
Broad/Descriptive Tags On Entries #23
Comments
That's an interesting question, the answer, at least for me is: "I don't know". Right now the only two ""sponsors"" for this project are the Arachni and w3af projects, which are web scanners, thus all the vulnerabilities in this database would have the "website" or "http" tags (at least implicit). In the future this might change and someone (not me, and most likely not @Zapotek but I can't talk for him) might add vulnerabilities which are not web related. It might be a good idea to prevent this future add-on of other vulnerabilities and tag all current vulnerabilities as "web", just in case. Leaving open so we do that. |
@andresriancho Which brings up the question, is vulndb just for web vulns or everything is fair game? |
Hope that clarifies my point of view |
Thank god for unittests. As you say it wasn't valid JSON, that made the test fail and after a couple of quick fixes: https://circleci.com/gh/vulndb/data/33 |
@andresriancho It will be better if we merge develop to master with PR in the future. What do you think? |
Yeah, I should work on develop and then merge. The good thing is that I'm only breaking master for some seconds ;) |
With regards to the tags used by entries in the database, what level of detail should they include? For example the entry on Cross-Site Scripting (XSS) has "xss", "regexp", "injection", "script", which is quite specific. I was wondering if it would be advantageous to add tags related to the domain in which the vulnerability exist. So include "website", "http", "sessions", etc.
Examples of when this might be useful is end-user search engines for the database which are aimed at developers who aren't necessarily infosec pros but want to see what could affect their project. Something where one can type "http", "website", etc and get a list of what they might be up against, allowing them to proactively build with those in mind prior to a security audit.
The text was updated successfully, but these errors were encountered: