Add ERC: Vulnerability and Exposure Identifier #513
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
abcoathup
reviewed
Jul 2, 2024
abcoathup
reviewed
Jul 2, 2024
abcoathup
reviewed
Jul 2, 2024
abcoathup
reviewed
Jul 3, 2024
eip-review-bot
changed the title
|
The commit 3718230 (as a parent of 3bf98a3) contains errors. |
This was referenced Jul 9, 2024
18 tasks
SamWilsn
reviewed
Aug 29, 2024
| --- | ||
| eip: 7731 | ||
| title: Vulnerability and Exposure Identifier | ||
| description: Establish a specification for creating on-chain unique identifiers for vulnerabilities |
There was a problem hiding this comment.
Suggested change
| description: Establish a specification for creating on-chain unique identifiers for vulnerabilities | |
| description: On-chain unique identifiers for vulnerabilities |
The first half of your description doesn't really have any information in it. Because the description is limited on space, we prefer to pack as much useful detail in there as possible. I've trimmed your description above, but you should try to expand further on what this proposal is proposing. Some ideas are:
- What is a vulnerability?
- What usecases does this solve?
- Who wants these identifiers?
Obviously with only ~140 characters, you can't be too verbose, so pick what's most important.
|
|
||
| ## Abstract | ||
|
|
||
| This EIP proposes a specification of the identifiers of vulnerabilities and exposures and a rule to specify the unique identifiers for vulnerabilities for disclosure and indexing, establishing a common language for protocol developers and ethical hackers. Indexers can easily track and subscribe to vulnerability updates if the vulnerability database is compatible with this EIP, whether on-chain or off-chain. |
There was a problem hiding this comment.
The phrasing here is a little rough. How about:
Suggested change
| This EIP proposes a specification of the identifiers of vulnerabilities and exposures and a rule to specify the unique identifiers for vulnerabilities for disclosure and indexing, establishing a common language for protocol developers and ethical hackers. Indexers can easily track and subscribe to vulnerability updates if the vulnerability database is compatible with this EIP, whether on-chain or off-chain. | |
| This proposal specifies identifiers for vulnerabilities and exposures, and a rule to create the unique identifiers for vulnerabilities for disclosure and indexing. It establishes a common language for protocol developers and ethical hackers. Indexers can easily track and subscribe to vulnerability updates if the vulnerability database is compatible with this proposal, whether on-chain or off-chain. |
|
|
||
| ## Abstract | ||
|
|
||
| This EIP proposes a specification of the identifiers of vulnerabilities and exposures and a rule to specify the unique identifiers for vulnerabilities for disclosure and indexing, establishing a common language for protocol developers and ethical hackers. Indexers can easily track and subscribe to vulnerability updates if the vulnerability database is compatible with this EIP, whether on-chain or off-chain. |
There was a problem hiding this comment.
Separately from the phrasing comment, your abstract is missing some technical meat. After reading this section, your audience should have a high-level overview of how the proposal accomplishes its goals.
|
|
||
| ## Motivation | ||
|
|
||
| When discussing security incidents, they are usually referred to as "Protocol Name + Exploit". Also, there are no unique identifiers for ethical hackers to reference the vulnerabilities, leading to high communication costs between the protocol developers and the ethical hackers. We can unify the terminology across various contexts by providing each vulnerability a unique identifier, as a parallel system to the existing ones such as CVE(Common Vulnerability and Exposure). |
There was a problem hiding this comment.
Suggested change
| When discussing security incidents, they are usually referred to as "Protocol Name + Exploit". Also, there are no unique identifiers for ethical hackers to reference the vulnerabilities, leading to high communication costs between the protocol developers and the ethical hackers. We can unify the terminology across various contexts by providing each vulnerability a unique identifier, as a parallel system to the existing ones such as CVE(Common Vulnerability and Exposure). | |
| When discussing security incidents, they are usually referred to as "Protocol Name + Exploit". Also, there are no unique identifiers for ethical hackers to reference the vulnerabilities, leading to high communication costs between the protocol developers and the ethical hackers. We can unify the terminology across various contexts by providing each vulnerability a unique identifier, as a parallel system to the existing ones such as the Common Vulnerabilities and Exposures (CVE) program. |
|
|
||
| When discussing security incidents, they are usually referred to as "Protocol Name + Exploit". Also, there are no unique identifiers for ethical hackers to reference the vulnerabilities, leading to high communication costs between the protocol developers and the ethical hackers. We can unify the terminology across various contexts by providing each vulnerability a unique identifier, as a parallel system to the existing ones such as CVE(Common Vulnerability and Exposure). | ||
|
|
||
| This EIP can be useful in the following use cases: |
There was a problem hiding this comment.
Suggested change
| This EIP can be useful in the following use cases: | |
| This proposal can be useful in the following use cases: |
|
|
||
| The identifier of vulnerability and exposure MUST conform to the following format: `Database Prefix + Year + Arbitrary Digits`. | ||
|
|
||
| `Database Prefix` SHOULD be uniquely named by different assigners. |
There was a problem hiding this comment.
This is not really an actionable requirement. Does this mean each assigner should choose exactly one unique prefix? What happens if they don't?
|
|
||
| `Arbitrary Digits` is RECOMMENDED to start from `0001` and increase incrementally. | ||
|
|
||
| These three parts MUST be connected by `-`, for example, `CVE-2024-0097`. The length of the identifier MUST NOT exceed 32 bytes. |
There was a problem hiding this comment.
exceed 32 bytes
This leaves the encoding of the identifier unspecified. Is it UTF-8? ASCII?
|
|
||
| `Year` MUST be in `YYYY` format. | ||
|
|
||
| `Arbitrary Digits` is RECOMMENDED to start from `0001` and increase incrementally. |
There was a problem hiding this comment.
What is permitted as a digit? Is Ⅷ (U+2167) a valid digit?
|
|
||
| `state` is the acceptance status of this `veId` set by the assigner. In this EIP, only two final state values are defined: `Published` and `Rejected`. The assigners can define their own initial or intermediate states based on their business requirements. The `status` value MUST be either `Published` or `Rejected` when the `veId` is in the final state. | ||
|
|
||
| `reportCid` MUST be the vulnerability report's IPFS CID(Content Identifier). |
There was a problem hiding this comment.
Suggested change
| `reportCid` MUST be the vulnerability report's IPFS CID(Content Identifier). | |
| `reportCid` MUST be the vulnerability report's IPFS Content Identifier (CID). |
There was a problem hiding this comment.
We prefer SVG images where possible. If you can't, this PNG is fine.
9 tasks
Mikhai56
suggested changes
Sep 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To address the absence of a standardized reference method for vulnerabilities and to reduce communication costs between protocol developers and ethical hackers, this ERC proposes a rule for creating unique identifiers for vulnerabilities. The aim is to establish a common language in these scenarios.