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?
SCSVS-CODE-1	S2.1.G1	No Test ID	Verify Inherited Function Implementation	- Have all required functions specified by parent contracts been implemented in the derived contract?
				- Are there any missing implementations that could affect the functionality or purpose of inheritance?
				- Is the inherited contract’s behavior consistent with the parent contract’s expectations?
SCSVS-CODE-1	S2.1.G2	No Test ID	Verify Interface Implementation	- Does the contract correctly implement all functions defined in the interface it adheres to?
				- Have you verified that the interface methods are fully implemented and operational?
				- Are there any discrepancies between the interface specification and the contract implementation?
SCSVS-CODE-1	S2.1.G3	No Test ID	Verify Correct Inheritance Order	- Is the inheritance chain ordered from the most base-like contract to the most derived contract?
				- Have you verified that the inheritance order does not affect variable initialization or functionality?
				- Are there any issues with storage layout or state variable initialization due to incorrect inheritance order?
SCSVS-CODE-1	S2.1.G4	No Test ID	Verify Initializable Usage	- Does the contract use the onlyInitializing modifier if it is intended to be inherited?
				- Is the initializer modifier used appropriately and not exposed to inherited contracts?
				- Have you ensured that initialization is restricted correctly to avoid unauthorized access?
SCSVS-CODE-1	S2.1.G5	No Test ID	Verify Comment Accuracy	- Are comments and documentation reviewed and updated regularly to match the current implementation?
				- Does the code review process include verification of comment accuracy and relevance?
				- Are there automated tools or practices in place to flag outdated or inconsistent comments?