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

Add ERC: Vulnerability and Exposure Identifier #513

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

dimitrysuen
Copy link

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.

@eip-review-bot
Copy link
Collaborator

eip-review-bot commented Jun 30, 2024

File ERCS/erc-7731.md

Requires 1 more reviewers from @axic, @g11tech, @SamWilsn, @xinbenlv

ERCS/erc-tbd.md Outdated Show resolved Hide resolved
ERCS/erc-tbd.md Outdated Show resolved Hide resolved
ERCS/erc-tbd.md Outdated Show resolved Hide resolved
ERCS/erc-tbd.md Outdated Show resolved Hide resolved
@eip-review-bot eip-review-bot changed the title Add ERC: Vulnerability and Exposure Identifier Specification and Indexing Add ERC: Vulnerability and Exposure Identifier Jul 8, 2024
@github-actions github-actions bot removed the w-ci label Jul 8, 2024
Copy link

github-actions bot commented Jul 8, 2024

The commit 3718230 (as a parent of 3bf98a3) contains errors.
Please inspect the Run Summary for details.

@github-actions github-actions bot added the w-ci label Jul 8, 2024
---
eip: 7731
title: Vulnerability and Exposure Identifier
description: Establish a specification for creating on-chain unique identifiers for vulnerabilities
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`reportCid` MUST be the vulnerability report's IPFS CID(Content Identifier).
`reportCid` MUST be the vulnerability report's IPFS Content Identifier (CID).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We prefer SVG images where possible. If you can't, this PNG is fine.

Copy link

@Mikhai56 Mikhai56 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ERCS/erc-7731.md

Copy link

@Mikhai56 Mikhai56 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assets/erc-7731/veId-and-refVeId.png

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

Successfully merging this pull request may close these issues.

5 participants