SCSVS-ARCH

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-ARCH-1	S1.1.A1	SCSTG-TEST-0005	Verify modularity and upgradability.	- Are the smart contracts using import statements to include other contracts and libraries?
				- Are functions within the contract logically separated and grouped into different contracts or libraries?
SCSVS-ARCH-1	S1.1.A2	SCSTG-TEST-0006	Ensure secure and controlled updates.	- Is the contract using a proxy pattern (e.g., Transparent Proxy or UUPS Proxy) for upgradability?
				- Are the upgradeTo or similar functions protected with onlyOwner or onlyAdmin modifiers?
				- Are there migration functions to safely transfer state variables to the new contract version?
SCSVS-ARCH-1	S1.1.A3	SCSTG-TEST-0006	Check module boundaries and dependencies.	- Are interfaces and abstract contracts used to define boundaries between modules?
				- Are external calls to other modules made through well-defined interfaces?
SCSVS-ARCH-1	S1.1.A4	SCSTG-TEST-0006	Ensure changes to storage variables are managed.	- Is there a well-documented storage layout for the contract?
				- Are storage variables added in storage gaps to avoid conflicts?
SCSVS-ARCH-1	S1.1.A5	SCSTG-TEST-0006	Verify critical privilege transfers.	- Is there a two-step process for transferring ownership using transferOwnership and claimOwnership?
				- Are there events emitted for each step of the transfer process?
SCSVS-ARCH-1	S1.1.A6	SCSTG-TEST-0006	Verify data location handling in function overrides.	- Are memory and storage keywords correctly used for parameters and return variables in overridden functions?
				- Are there tests covering function overrides to ensure no invalid virtual function calls?
SCSVS-ARCH-1	S1.1.B1	No Test ID	Verify separation of different functionalities.	- Are the contracts modular with clearly defined responsibilities?
				- Is there a single responsibility per contract or module?
SCSVS-ARCH-1	S1.1.B2	No Test ID	Ensure minimal dependencies between modules.	- Are modules loosely coupled?
				- Is each module's responsibility clearly defined and limited?
SCSVS-ARCH-1	S1.1.B3	No Test ID	Check for cross-module dependencies.	- Are there dependencies that could introduce security vulnerabilities?
				- Is each module's responsibility clearly defined and limited?
SCSVS-ARCH-1	S1.1.B4	No Test ID	Ensure consistent operation during privilege transfers.	- Are edge cases considered during privilege transfers?
				- Is there a fallback mechanism in case of transfer failure?
SCSVS-ARCH-1	S1.1.B5	No Test ID	Verify proxy contract initialization.	- Are proxy contracts using the onlyInitializing modifier?
				- Is there a check to prevent re-initialization?
SCSVS-ARCH-1	S1.1.B6	No Test ID	Verify storage layout consistency.	- Are storage layouts compatible across different contract versions?
				- Is there documentation for storage layout changes?
SCSVS-ARCH-1	S1.1.B7	No Test ID	Ensure immutable variable consistency.	- Are immutable variables properly defined and documented?
				- Is there a verification process for consistency across upgrades?
SCSVS-ARCH-1	S1.1.B8	No Test ID	Verify consistency in logic implementation.	- Is logic implemented consistently across the contract?
				- Is there a review process for verifying consistency?
SCSVS-ARCH-1	S1.1.B9	No Test ID	Ensure separate handling of ETH and WETH.	- Are ETH and WETH treated as distinct entities?
				- Are there checks in place to handle ETH and WETH appropriately?
SCSVS-ARCH-1	S1.1.B10	No Test ID	Verify proxy setup for contracts with constructors.	- Are contracts designed without constructors for proxy setups?
				- Is initializer logic implemented and verified?
SCSVS-ARCH-2	S1.2.A1	No Test ID	Verify implementation of upgrade mechanisms.	- Is the contract using a well-known proxy pattern such as Transparent Proxy or UUPS Proxy?
				- Are there unit tests verifying the upgrade functionality?
				- Is the upgrade mechanism designed to be easily extensible for future upgrades?
SCSVS-ARCH-2	S1.2.A2	No Test ID	Ensure safeguards against unauthorized upgrades.	- Is the upgradeTo function protected by onlyOwner or onlyAdmin modifiers?
				- Are access controls and ownership mechanisms properly tested and reviewed?
				- Are multi-signature wallets or other advanced access control mechanisms used for upgrade authorization?
SCSVS-ARCH-2	S1.2.A3	No Test ID	Review and document the upgrade mechanism.	- Is the upgrade mechanism thoroughly documented in the project documentation?
				- Has the upgrade mechanism undergone a formal security audit?
				- Are there guidelines and best practices documented for performing upgrades?
SCSVS-ARCH-2	S1.2.A4	No Test ID	Verify consistency of immutable variables.	- Are immutable variables defined and documented across all contract versions?
				- Is there a validation process to ensure consistency of immutable variables during upgrades?
				- Are there automated tests checking the state of immutable variables before and after upgrades?
SCSVS-ARCH-2	S1.2.A5	No Test ID	Verify use of selfdestruct and delegatecall in proxy setup.	- Is there a review process for identifying and mitigating risks associated with selfdestruct and delegatecall?
				- Are there unit tests covering scenarios involving selfdestruct and delegatecall?
				- Is the use of selfdestruct and delegatecall documented and justified in the contract?
SCSVS-ARCH-2	S1.2.A6	No Test ID	Protect UUPSUpgradeable contracts.	- Are UUPSUpgradeable contracts tested for initialization-related vulnerabilities?
				- Is there a mechanism to ensure that implementation contracts are properly initialized before use?
				- Are there security reviews focused on initialization and upgrade vulnerabilities in UUPSUpgradeable contracts?
SCSVS-ARCH-2	S1.2.B1	No Test ID	Verify handling of deprecated contract versions.	- Are deprecated contract versions clearly marked with appropriate deprecation notices in the code and documentation?
				- Is there a mechanism to disable functionality in deprecated contracts while maintaining state integrity?
				- Are deprecated contracts archived and isolated from the main deployment pipeline to prevent accidental usage?
SCSVS-ARCH-2	S1.2.B2	No Test ID	Ensure restriction or disabling of access to deprecated versions.	- Are access controls updated to restrict interactions with deprecated contract versions?
				- Is there a revocation process in place to revoke permissions or keys associated with deprecated contracts?
				- Are deprecated contracts audited to ensure no critical functions remain accessible post-deprecation?
SCSVS-ARCH-2	S1.2.B3	No Test ID	Check security of migration paths from deprecated versions.	- Is there a documented and tested migration plan for transitioning from deprecated to new contract versions?
				- Are migration scripts and tools audited for security vulnerabilities that could compromise the migration process?
				- Is there a rollback mechanism in case the migration encounters issues, ensuring no loss of state or functionality?
SCSVS-ARCH-3	S1.3.C1	No Test ID	Verify implementation of high-priority risk mitigations.	- Are there specific mitigations in place for reentrancy attacks, such as the use of checks-effects-interactions pattern or reentrancy guards?
				- Are overflow and underflow checks implemented using SafeMath or Solidity's built-in overflow protection?
				- Are access controls and role-based permissions thoroughly tested to prevent unauthorized access?
SCSVS-ARCH-3	S1.3.C2	No Test ID	Ensure documentation and testing of mitigation strategies.	- Are all mitigation strategies documented with clear explanations of how they address specific vulnerabilities?
				- Are there unit and integration tests specifically designed to validate the effectiveness of each mitigation strategy?
				- Is there a process for continuously updating the documentation and tests as new threats and mitigations are identified?
SCSVS-ARCH-3	S1.3.C3	No Test ID	Review and validate effectiveness of implemented mitigations.	- Are periodic security audits conducted to review and validate the effectiveness of implemented mitigations?
				- Are there automated tools and scripts in place to continuously monitor the security posture of the smart contracts?
				- Is there a feedback loop for integrating audit findings and monitoring results into the mitigation strategy?
SCSVS-ARCH-3	S1.3.G1	No Test ID	Understanding Protocol Actors	- Have all actors and their interactions within the protocol been clearly identified and documented?
				- Are the roles and permissions of each actor clearly defined and appropriate?
				- Does the contract inherit functions from parent contracts?
				- Are functions that override parent contract functions explicitly marked with the override keyword?
SCSVS-ARCH-3	S1.3.G3	No Test ID	Verify Sybil Attack Protection	- Is the protocol's quorum mechanism or rewarding system designed to resist Sybil attacks? Verify the criteria used for participation or rewards.
				- How does the contract ensure that actions or decisions are not unduly influenced by Sybil attacks?
				- Are there checks or balances in place to validate the legitimacy of addresses participating in quorum or rewarding mechanisms?
SCSVS-ARCH-3	S1.3.G4	No Test ID	Verify Front-Running Protection for Initializer	- Does the contract use a factory pattern or other mechanism to prevent front-running of the initializer function?
				- Is the initializer function protected from being called by unauthorized parties immediately after deployment?
				- Have you implemented safeguards to ensure the initializer cannot be front-run to alter critical access controls?