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

Clarify that CVE IDs can be assigned to vulnerabilities that are already public #32

Open
EvansJonathan opened this issue Jul 26, 2017 · 6 comments

Comments

@EvansJonathan
Copy link
Contributor

GOAL: Document existing policy
CHANGE: INC2 should be changed to clarify that the vulnerabilities that are already public can be assigned a CVE ID.
OUTCOME: Reduced confusion.

@kurtseifried
Copy link

define public, e.g. what if it is shared within an industry (e.g. aerospace)? does it need to go to oss-secrity? etc.

@EvansJonathan
Copy link
Contributor Author

Here is what I have in my training presentation for what public is:

  • For a vulnerability to be considered public, it must meet the following conditions
    • Has to have a URL
    • The Terms of Use must allow us to link to the URL
    • The document linked to by the URL must contain the minimum required information for a CVE entry.
      • Product
      • Version
      • Problem type (vulnerability type or impact)
  • Registration and login requirements are acceptable, but there can’t be other restrictions
  • Advisories that require payment to access are not considered public
    • If you have a public advisory with the minimum required details and other details require payment to access, then the vulnerability is considered public

@ghost
Copy link

ghost commented Sep 15, 2017

Registration and login requirements are acceptable, but there can’t be other restrictions

does this mean free sign up, or can it be tied to something that may not cost money but may be a pain to sign up for (e.g. they only allow signup using a facebook account).

@dadinolfi
Copy link
Contributor

If anyone anywhere has the ability to get to the information without paying money, the resource would be acceptable.

@ghost
Copy link

ghost commented Sep 26, 2017

I would generally agree but there are a few corner cases where the signup process is so onerous (e.g. you have to log into an IRC channel, wait for someone to be around, and ask them for an account on the bug tracker, and no this isn't a made up case, this is a real world case) that nobody can be bothered to do it. This is also one of the reasons I want to embed a copy of the data into the CVE JSON data (so if it goes away or is hard to get at there's the data in CVE JSON at least, even if out of date it's better than nothing).

@dadinolfi
Copy link
Contributor

Suggestion: change INC2 to read:

Is the vulnerability report or the issue described currently published publicly or intended to be published to a publicly available location in the future? CVE IDs are intended to be public information and are not assigned to vulnerabilities that are intended to be private. See Section 2.1 for a description of what is considered “public”.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants