SCSVS-CODE

Temporary Checklist

This checklist contains the SCSVS v0.0.1 verification levels (L1, L2 and L3) which we are currently reworking into "security testing profiles". The levels were assigned according to the SCSVS v1 ID that the test was previously covering and might differ in the upcoming version of the SCSTG and SCS Checklist.

For the upcoming of the SCSTG version we will progressively split the SCSTG tests into smaller tests, the so-called "atomic tests" and assign the new SCS profiles to their respective SCWE weaknesses.

SCG ID	VR ID	TEST ID	Control / SCSTG Test	Checklist
SCSVS-CODE-1	S2.1.A1	TBD	Ensure adherence to latest compiler recommendations.	- Are the smart contracts compiled using the latest stable version of the Solidity compiler?
				- Are there automated checks in the CI/CD pipeline to enforce the use of specific compiler versions?
				- Is there documentation and enforcement of the project's policy on compiler versioning?
SCSVS-CODE-1	S2.1.A2	TBD	Verify non-usage of deprecated functions.	- Are deprecated functions identified and removed from the codebase during code reviews?
				- Are automated static analysis tools used to detect the usage of deprecated functions?
				- Is there a process to update the codebase to replace deprecated functions with their recommended alternatives?
SCSVS-CODE-1	S2.1.B1	TBD	Independent expert code review.	- Are pull requests (PRs) for smart contract changes reviewed and approved by at least two developers with smart contract security expertise?
				- Is there documentation of the review process, including comments and approvals from the reviewers?
SCSVS-CODE-1	S2.1.B2	TBD	Incorporate automated static analysis tools.	- Are automated static analysis tools, such as MythX or Slither, integrated into the CI/CD pipeline for smart contract code reviews?
				- Are all issues flagged by these tools documented and resolved or justified before merging the code?
SCSVS-CODE-1	S2.1.B3	TBD	Thorough analysis for vulnerabilities.	- Are code reviews checking for potential reentrancy vulnerabilities, such as unprotected external calls within functions?
				- Are integer overflow and underflow vulnerabilities being checked using SafeMath or Solidity's built-in overflow protection?
				- Is the code reviewed for proper access control mechanisms, ensuring that only authorized addresses can perform sensitive operations?
SCSVS-CODE-1	S2.1.B4	TBD	Adherence to development standards.	- Are smart contracts using SafeMath libraries for all arithmetic operations to prevent overflows and underflows?
				- Is the use of design patterns like checks-effects-interactions consistently applied to mitigate reentrancy attacks?
				- Are fallback and receive functions implemented securely, with proper checks to prevent misuse?
SCSVS-CODE-1	S2.1.B5	TBD	Checklist for common vulnerabilities.	- Is there a comprehensive checklist of common smart contract vulnerabilities (e.g., reentrancy, integer overflows, unchecked external calls) used during code reviews?
				- Are all items on the checklist reviewed and marked as addressed in the code review process?
				- Are the checklist and review process updated regularly to incorporate new vulnerabilities and best practices?