Suggestion to Distinguish Non-Exploitable Vulnerabilities

[rakesh0x7]

Description:

As the blockchain ecosystem evolves, some vulnerabilities that were previously considered as issues are no longer exploitable due to advancements in smart contract development practices and improvements in blockchain security.

Proposal Please create a folder in the repository to categorize vulnerabilities that are no longer exploitable, helping users focus on current exploitable issues.

Examples:

1. Uninitialized Storage Pointer: Not exploitable due to modern Solidity practices.
2. Incorrect Constructor: Mitigated by new constructor syntax in Solidity.

Goal To help users focus on current, exploitable vulnerabilities.

Could you suggest a way to distinguish non-exploitable vulnerabilities in the repo? For example, by creating a new section or folder.

[kadenzipfel]

What do you think about instead updating the titles to include a "(DEPRECATED)" suffix or something like that? This way it wouldn't interfere with the categorization structure and would still make it clear to the user that it's likely not relevant.

Another concern I have with this though is that although these vulnerabilities may not be relevant in newer versions, researchers may still be reviewing older contracts. What do you think?

[rakesh0x7]

Adding a "DEPRECATED" suffix to the titles sounds like a great idea.

Regarding your concern about researchers reviewing older contracts, that's a valid point. To address this, we could add a brief note within the deprecated entries explaining their relevance to older contracts. This way, we provide context for both new and old contract reviewers.

What do you think?

[kadenzipfel]

I think my only concern at this point is in how we determine at what point the issue should be considered deprecated, e.g. a new solidity version that prevents a vulnerability should not immediately make it deprecated. I kinda feel like maybe the best option is to add a note to the top of the file indicating that, e.g. it's no longer relevant for v0.5.0 and above

[rakesh0x7]

Adding a note at the top of the file indicating the versions affected sounds like a reasonable approach.

The main reason I raised this issue is that, as someone learning about vulnerabilities, it would be helpful to focus on current issues when analysing contracts. However, I understand the importance of maintaining historical context for researchers.

Ultimately, it's up to you to decide the best approach.

[kadenzipfel]

Yeah I can see that. IMO it's better to know more than you need than too little, especially since there will always be smart contracts with old versions. Let's do the note at the top of the file, feel free to make a PR for any issues that this would be relevant