Add: SCWE and SCSTG Test cases for 10 controls

.vscode/pratiklagaskar.weaudit

@@ -0,0 +1,9 @@
+{
+  "clientRemote": "",
+  "gitRemote": "",
+  "gitSha": "7860ea86986b18ca7c0286e4c08724f73704f440",
+  "treeEntries": [],
+  "auditedFiles": [],
+  "partiallyAuditedFiles": [],
+  "resolvedEntries": []
+}

docs/SCSTG/0x02c-Acknowledgements.md

@@ -51,7 +51,7 @@ If you'd like to apply please contact the project leaders by sending an email. P
 
 - If the "SCS Advocate" status is granted and you'd like to maintain it, the aforementioned contributions must remain consistent after the initial period as well. You should keep collecting this evidence and send us a _contribution report_ yearly.
 - [Financial donations](https://scs.owasp.org/donate/) are not part of the eligibility criteria but will be listed for completion.
-- Re-shared publications and blog posts linked in SCSTG text must be **educational** and focus on mobile security or SCSVS/SCSTG and **not endorse company products/services**.
+- Re-shared publications and blog posts linked in SCSTG text must be **educational** and focus on smart contract security or SCSVS/SCSTG and **not endorse company products/services**.
 - Advocate Companies may use the logo and links to SCSVS/SCSTG resources as part of their communication but cannot use them as an endorsement by OWASP as a preferred provider of software and services.
     - Example of what's ok: list SCS Advocate status on website home page, in "about company" slides in sales presentations, on sales collateral.
     - Example of what's not ok: a SCS Advocate cannot claim they are OWASP certified.

docs/SCSTG/0x03-Overview.md

@@ -2,4 +2,4 @@
 
 
 
-## How to Use the Mobile Application Security Project
+## How to Use the Smart Contract Security Project

docs/SCSTG/tests/SCSVS-ARCH/SCSTG-TEST-0007.md

@@ -0,0 +1,111 @@
+---
+id: SCSTG-TEST-0007
+scsvs_cg_id:
+- SCSVS-ARCH
+scsvs_scg_id:
+- SCSVS-ARCH-2
+platform: []
+title: Modularity and Upgradability
+scsvs_cg_levels:
+- L2
+tests: SCSTG-TEST-0007
+---
+
+### **Description**
+Modularity and upgradability are essential principles for the long-term security and maintainability of smart contracts. Poor modularity often leads to monolithic designs that combine critical logic and storage, making it difficult to upgrade, audit, or scale the system. Without controlled upgrade mechanisms, an attacker could exploit weaknesses in the upgrade process, leading to unauthorized contract changes or the introduction of security flaws. Ensuring a well-structured contract with clear modular separation, as well as a secure upgrade process, is crucial to avoiding such vulnerabilities.
+
+---
+
+### **Test 1: Ensure Proper Separation of Logic and State**
+
+#### Vulnerable Code
+```solidity
+contract Monolithic {
+    uint256 public data;
+    address public admin;
+
+    function updateData(uint256 _data) public {
+        require(msg.sender == admin, "Unauthorized");
+        data = _data;
+    }
+
+    function upgrade(address newAdmin) public {
+        require(msg.sender == admin, "Unauthorized");
+        admin = newAdmin;
+    }
+}
+```
+
+### **Why It’s Vulnerable**
+- The monolithic design combines logic and state in a single contract, making upgrades risky.
+- Changes to storage or logic could inadvertently corrupt existing data.
+- The lack of separation makes it more difficult to isolate bugs or vulnerabilities in logic.
+
+#### Fixed Code:
+
+```solidity
+contract Logic {
+    address public admin;
+    Storage public storageContract;
+
+    constructor(address _storageContract) {
+        admin = msg.sender;
+        storageContract = Storage(_storageContract);
+    }
+
+    function updateData(uint256 _data) public {
+        require(msg.sender == admin, "Unauthorized");
+        storageContract.setData(_data);
+    }
+}
+
+contract Storage {
+    uint256 public data;
+
+    function setData(uint256 _data) public {
+        data = _data;
+    }
+}
+```
+#### **How to Check**
+- Code Review: Verify the separation of logic and storage into separate contracts.
+- Storage Analysis: Ensure that the storage layout remains intact when upgrading the contract logic, and that no data corruption occurs.
+
+### **Test 2: Verify Secure and Controlled Upgrade Mechanism**
+
+#### Vulnerable Code:
+
+```solidity
+contract Proxy {
+    address public implementation;
+
+    function upgrade(address newImplementation) public {
+        implementation = newImplementation;
+    }
+}
+```
+
+### **Why It’s Vulnerable**
+- The upgrade function is not protected with any access control, allowing any user to replace the implementation contract. This opens the door for malicious actors to hijack the contract functionality.
+
+#### Fixed Code:
+```solidity
+contract SecureProxy {
+    address public implementation;
+    address public admin;
+
+    modifier onlyAdmin() {
+        require(msg.sender == admin, "Unauthorized");
+        _;
+    }
+
+    function upgrade(address newImplementation) public onlyAdmin {
+        implementation = newImplementation;
+    }
+}
+
+```
+
+#### **How to Check**
+- Code Review: Ensure that upgrade functions are protected by access control mechanisms (e.g., only the admin can upgrade).
+- Dynamic Testing: Attempt to perform an unauthorized upgrade to verify that the access control works as intended.

docs/SCSTG/tests/SCSVS-AUTH/SCSTG-TEST-0001.md

@@ -4,18 +4,77 @@ scsvs_cg_id:
 - SCSVS-AUTH
 scsvs_scg_id:
 - SCSVS-AUTH-1
-platform: android
-title: Multi-Signature Schemes
+platform: []
+title: Testing Multi-Signature Schemes
 scsvs_cg_levels:
 - L2
 tests: SCSTG-TEST-0001 
 ---
 
-Ensure that the visibility modifier for all functions is appropriate, preventing unnecessary exposure of internal functions.
+Ensure that multi-signature schemes are implemented for critical operations, requiring approvals from multiple authorized parties to enhance security and reduce the risk of unauthorized actions.
 
- - If a function is only meant to be used internally, it should be marked as internal or private. This ensures it cannot be called externally or by other contracts.
+- Verify that the multi-signature logic ensures a configurable threshold of approvals before executing sensitive operations.  
+- Confirm that all signers are authenticated and that duplicate signatures are rejected.  
+- Test edge cases, such as insufficient approvals or tampered data.
 
 ```solidity
-function internalFunction() internal { ... }  // internal function, only accessible within the contract
-function privateFunction() private { ... }	// private function, not even accessible by derived contracts
-```
+// Example of multi-signature scheme
+pragma solidity ^0.8.0;
+
+contract MultiSigWallet {
+    address[] public owners;
+    uint public requiredApprovals;
+    mapping(address => bool) public isOwner;
+    mapping(uint => mapping(address => bool)) public approvals;
+
+    struct Transaction {
+        address to;
+        uint value;
+        bool executed;
+    }
+
+    Transaction[] public transactions;
+
+    constructor(address[] memory _owners, uint _requiredApprovals) {
+        require(_owners.length > 0, "Owners required");
+        require(_requiredApprovals > 0 && _requiredApprovals <= _owners.length, "Invalid approval count");
+
+        for (uint i = 0; i < _owners.length; i++) {
+            isOwner[_owners[i]] = true;
+        }
+        owners = _owners;
+        requiredApprovals = _requiredApprovals;
+    }
+
+    function submitTransaction(address _to, uint _value) public {
+        require(isOwner[msg.sender], "Not an owner");
+        transactions.push(Transaction({to: _to, value: _value, executed: false}));
+    }
+
+    function approveTransaction(uint _txIndex) public {
+        require(isOwner[msg.sender], "Not an owner");
+        require(!approvals[_txIndex][msg.sender], "Already approved");
+
+        approvals[_txIndex][msg.sender] = true;
+    }
+
+    function executeTransaction(uint _txIndex) public {
+        require(transactions[_txIndex].executed == false, "Already executed");
+
+        uint approvalCount = 0;
+        for (uint i = 0; i < owners.length; i++) {
+            if (approvals[_txIndex][owners[i]]) {
+                approvalCount++;
+            }
+        }
+
+        require(approvalCount >= requiredApprovals, "Not enough approvals");
+
+        transactions[_txIndex].executed = true;
+        payable(transactions[_txIndex].to).transfer(transactions[_txIndex].value);
+    }
+
+    receive() external payable {}
+}
+```
+Review the logic to ensure all approvals are validated before execution, duplicate approvals are prevented, and transaction data integrity is maintained. Test with various approval scenarios to verify proper handling of edge cases.

docs/SCSTG/tests/SCSVS-AUTH/SCSTG-TEST-0002.md

@@ -4,8 +4,8 @@ scsvs_cg_id:
 - SCSVS-AUTH
 scsvs_scg_id:
 - SCSVS-AUTH-1
-platform: android
-title: Identity Verification
+platform: []
+title: Identity Verification Test
 scsvs_cg_levels:
 - L2
 tests: SCSTG-TEST-0002 

docs/SCSTG/tests/SCSVS-AUTH/SCSTG-TEST-0003.md

@@ -4,8 +4,8 @@ scsvs_cg_id:
 - SCSVS-AUTH
 scsvs_scg_id:
 - SCSVS-AUTH-1
-platform: android
-title: Least Privilege Principle
+platform: []
+title: Least Privilege Principle Test
 scsvs_cg_levels:
 - L2
 tests: SCSTG-TEST-0003 

docs/SCSTG/tests/SCSVS-AUTH/SCSTG-TEST-0004.md

@@ -4,8 +4,8 @@ scsvs_cg_id:
 - SCSVS-AUTH
 scsvs_scg_id:
 - SCSVS-AUTH-1
-platform: android
-title: Access Control on Critical Functions
+platform: []
+title: Test Access Control on Critical Functions
 scsvs_cg_levels:
 - L2
 tests: SCSTG-TEST-0004 

docs/SCSTG/tests/SCSVS-AUTH/SCSTG-TEST-0005.md

@@ -4,8 +4,8 @@ scsvs_cg_id:
 - SCSVS-AUTH
 scsvs_scg_id:
 - SCSVS-AUTH-1
-platform: android
-title: Timed Permissions
+platform: []
+title: Test Timed Permissions
 scsvs_cg_levels: 
 - L2
 tests: SCSTG-TEST-0005 

docs/SCSTG/tests/SCSVS-AUTH/SCSTG-TEST-0006.md

@@ -4,8 +4,8 @@ scsvs_cg_id:
 - SCSVS-AUTH
 scsvs_scg_id:
 - SCSVS-AUTH-2
-platform: ethereum
-title: Timed Permissions
+platform: []
+title: Test Access Control Using Merkle Trees
 scsvs_cg_levels:
 - L2
 tests: SCSTG-TEST-0006