W3SAMM

Software Security

Control Criteria

Security is considered formally for the contracts being developed for the application
Security is considered for DApp front ends if they exist
Some element of security function is applied to DApps
Level 1: Are there initial best practices identified and implemented for the security of Decentralized Applications (DApps)?
Level 2: Are these best practices more comprehensive, regularly updated, and aligned with emerging security trends in the decentralized space?
Level 3: Is there an advanced set of best practices, widely recognized and adhered to, with proactive measures to anticipate and address future security challenges in DApp development?

Control Criteria

Smart contracts are reviewed for security in some way
Audits have been conducted or are planned for the smart contracts associated with the project or team
There is internal knowledge of smart contract security and best practices
Level 1: Is basic security in place for smart contracts, such as using known patterns and simple audits?
Level 2: Are smart contract security measures more rigorous, including thorough audits, formal verification, and vulnerability scanning?
Level 3: Is there a sophisticated, continuous security process for smart contracts, employing cutting-edge tools and practices, and integrating community feedback for ongoing improvement?

Control Criteria

Code reviews are conducted for third-party components
There is an inventory of third-party components available
Level 1: Are there basic procedures in place for the review of third-party code, focusing on major known vulnerabilities?
Level 2: Are review procedures more comprehensive, regularly updated, and include systematic checks for a broader range of security issues?
Level 3: Is there a highly advanced code review process, integrating automated tools, continuous integration checks, and peer review systems?

Control Criteria

There is engagement with the community to peer review third-party code
There are published issues or vulnerabilities for the third party
Level 1: Is there an initial engagement with the community for code review on an ad-hoc basis?
Level 2: Are community-based reviews more structured and regularly solicited, with clear guidelines and incentives for community participation such as a bug bounty program?
Level 3: Is there an established, robust community review ecosystem, with ongoing interaction, collaboration, and recognition systems to encourage active community involvement?

Control Criteria

Standards exist for extended ecosystem of the project
There have been submissions from the project or organization to the greater ecosystem
There is some engagement with the greater community
Level 1: Are basic advisory standards in place for guiding projects on security matters?
Level 2: Are these standards more detailed, tailored to various types of projects, and regularly reviewed for relevance and effectiveness?
Level 3: Are advisory practices highly advanced, regarded as industry standards, and include a proactive approach to advising on emerging security threats and technologies?

Control Criteria

The project or organization is accepting of feedback from external stakeholders
Feedback has been or is planned for incorporation into the product
Level 1: Is there a basic process for receiving and incorporating feedback into security advisory practices?
Level 2: Is feedback systematically solicited and analyzed, with structured mechanisms for integrating insights into continuous improvement of advisory services?
Level 3: Is there a mature, dynamic feedback and improvement system, deeply integrated into the stewardship approach, fostering ongoing adaptation and enhancement of security advisory services?

This site is open source. Improve this page.