securing · deliriusz · Dec 22, 2021 · Dec 22, 2021 · Nov 3, 2022 · Nov 3, 2022
diff --git a/.github/ISSUE_TEMPLATE/security-check-proposal--scp-.md b/.github/ISSUE_TEMPLATE/security-check-proposal--scp-.md
@@ -7,9 +7,9 @@ assignees: ''
 
 ---
 
-ATTENTION! If you would like to submit a SCP please use the following schema (described in [template](https://github.com/securing/SCSVS/blob/prerelease/SCSVSv2/scp-template.md)).
+ATTENTION! If you would like to submit a SCP please use the following schema (described in [template](https://github.com/ComposableSecurity/SCSVS/blob/prerelease/SCSVSv2/scp-template.md)).
 
-If you have a ready change to be added to the repository, please submit it as a [Pull Request](https://github.com/securing/SCSVS/pulls) and create a SCP with link to PR.
+If you have a ready change to be added to the repository, please submit it as a [Pull Request](https://github.com/ComposableSecurity/SCSVS/pulls) and create a SCP with link to PR.
 
 ## Check
 

diff --git a/1.1/README.md b/1.1/README.md
@@ -2,7 +2,7 @@
 
 ## Authors
 
-Damian Rusinek (damian.rusinek@securing.pl), Paweł Kuryłowicz (pawel.kurylowicz@securing.pl)
+Damian Rusinek (damian.rusinek@composable-security.com), Paweł Kuryłowicz (pawel.kurylowicz@composable-security.com)
 
 ## Introduction
 
@@ -27,8 +27,6 @@ You can use the SCSVS checklist in multiple ways:
 The entire checklist is in a form similar to OWASP APPLICATION SECURITY VERIFICATION STANDARD v4.0.
 Every category has a brief description of the control objectives and a list of security verification requirements.
 
-[___Download SCSVS PDF version___](SCSVS_v1.1.pdf)
-
 **Key areas that have been included:**
 * [V1: Architecture, Design and Threat Modelling](./0x10-V1-Architecture-Design-Threat-modelling.md)
 * [V2: Access Control](./0x11-V2-Access-Control.md)

diff --git a/1.2/README.md b/1.2/README.md
@@ -2,7 +2,7 @@
 
 ## Authors
 
-Damian Rusinek (damian.rusinek@securing.pl), Paweł Kuryłowicz (pawel.kurylowicz@securing.pl)
+Damian Rusinek (damian.rusinek@composable-security.com), Paweł Kuryłowicz (pawel.kurylowicz@composable-security.com)
 
 ## Introduction
 
@@ -27,8 +27,6 @@ You can use the SCSVS checklist in multiple ways:
 The entire checklist is in a form similar to OWASP APPLICATION SECURITY VERIFICATION STANDARD v4.0.
 Every category has a brief description of the control objectives and a list of security verification requirements.
 
-[___Download SCSVS PDF version___](SCSVS_v1.1.pdf)
-
 **Key areas that have been included:**
 * [V1: Architecture, Design and Threat Modelling](./0x10-V1-Architecture-Design-Threat-modelling.md)
 * [V2: Access Control](./0x11-V2-Access-Control.md)

diff --git a/2.0/0x100-General/0x102-G2-Policies-procedures.md b/2.0/0x100-General/0x102-G2-Policies-procedures.md
@@ -8,7 +8,7 @@ Think about possible situations and be prepared in case they arise. Act consciou
 Ensure that your project satisfies the following high-level requirements:
 * Security procedures and policies are thought out and ready to use,
 * Procedures and policies cover known and common threats from the past of other DeFi projects,
-* Employees are familiar with the policies and procedures and they know what they are responsible for.
+* Employees are familiar with the policies and procedures, and they know what they are responsible for.
 
 Category “G2” lists requirements related to the policies, and procedures in the context of security of DeFi projects.
 
@@ -24,12 +24,15 @@ Category “G2” lists requirements related to the policies, and procedures in
 | **G2.6** | Verify that the process of major system changes involves threat modeling by an external company. |
 | **G2.7** | Verify that the process of adding and updating components to the system includes a security audit by an external company. |
 | **G2.8** | Verify that there is a clear and known procedure in place in the event of a hack. |
-| **G2.9** | Verify that the procedure in the event of hack have defined exact persons to execute required actions. |
+| **G2.9** | Verify that the procedure in the event of hack have defined individuals to execute required actions. |
 | **G2.10** | Verify that the procedure includes alarming other projects about the hack through trusted channels. |
 | **G2.11** | Verify that a procedure is defined in case one of the project's private keys is leaked. |
+| **G2.12** | Verify that the project has an emergency contact with the external company that conducted the last audit. |
 
 ## References
 
 For more information, see also:
 
-* [TODO](https://www.youtube.com/watch?v=IwR4PAmRhhg&list=PL-lO2xrptAtav4SZgCdDkVxChWhVU3kmP&index=18)
+* [Emergency Procedures - Yearn Finance](https://docs.yearn.finance/vaults/0.4.2/process-and-procedures/emergency)
+* [Emergency tools - Yearn Finance](https://docs.yearn.finance/vaults/0.4.2/process-and-procedures/emergency#tools)
+* [Emergency checklist - Yearn Finance](https://docs.yearn.finance/vaults/0.4.2/process-and-procedures/emergency#emergency-checklist)
diff --git a/2.0/0x100-General/0x103-G3-Upgradeability.md b/2.0/0x100-General/0x103-G3-Upgradeability.md
@@ -33,5 +33,7 @@ Category “G3” lists requirements related to the upgradeabilitiy of the smart
 
 For more information, see also:
 
+* [OpenZeppelin upgrades plugins](https://docs.openzeppelin.com/upgrades-plugins)
+* [Chainlink upgradable smart contracts](https://blog.chain.link/upgradable-smart-contracts/)
 * [Contract upgrade anti-patterns](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns)
-* [Security in Upgrades of Smart Contracts](https://www.youtube.com/watch?v=5WE6PEc305w)
+* [Security in Upgrades of Smart Contracts](https://www.youtube.com/watch?v=5WE6PEc305w)
diff --git a/2.0/0x100-General/0x104-G4-Business-Logic.md b/2.0/0x100-General/0x104-G4-Business-Logic.md
@@ -2,7 +2,7 @@
 
 ## Control Objective
 
-To build secure smart contracts, we need to consider security of their business logic. Some of the smart contracts are influenced by vulnerabilities by their design.
+To build secure smart contracts, we need to consider the security of their business logic. Some of the smart contracts are influenced by vulnerabilities in their design.
 The components used should not be considered safe without verification. Business assumptions should meet with the principle of minimal trust, which is essential in building smart contracts.
 
 Ensure that a verified contract satisfies the following high-level requirements:
@@ -18,13 +18,18 @@ Category “G4” lists requirements related to the business logic of the smart
 | --- | --- |
 | **G4.1** | Verify that there are no vulnerabilities associated with business logic. | 
 | **G4.2** | Verify that the contract logic and protocol parameters implementation corresponds to the documentation. | 
-| **G4.3** | Verify that the business logic flows of smart contract proceed in a sequential step order and it is not possible to skip any part of it or to do it in a different order than designed.  | 
-| **G4.4** | Verify that the contract has business limits and correctly enforces it. | 
+| **G4.3** | Verify that the business logic flows of smart contract proceed in a sequential step order, and it is not possible to skip any part of it or to do it in a different order than designed.  | 
+| **G4.4** | Verify that the contract has business limits and correctly enforces them. | 
 | **G4.5** | Verify that the business logic of contract does not rely on the values retrieved from untrusted contracts (especially when there are multiple calls to the same contract in one flow). | 
 | **G4.6** | Verify that the contract logic does not rely on the balance of contract (e.g., *balance == 0*). | 
 | **G4.7** | Verify that the sensitive operations of contract do not depend on the block data (e.g., *block hash*, *timestamp*). | 
 | **G4.8** | Verify that the contract uses mechanisms that mitigate transaction-ordering dependence (front-running) attacks (e.g. pre-commit scheme). | 
-| **G4.9** | Verify that the contract does not send funds automatically, but it lets users withdraw funds on their own in separate transaction instead. | 
+| **G4.9** | Verify that the contract does not send funds automatically, but it lets users withdraw funds on their own in the separate transaction instead. |
+| **G4.10** | Verify that the functions are built symmetrically (e.g. in the case of a *deposit*, there is also a *withdraw*). |
+| **G4.11** | Verify that calling a function once with value XY gives a similar result as calling it X times with value Y. |
+| **G4.12** | Verify that the global state is also updated when working on a copy of some data for optimization reasons. |
+| **G4.13** | Verify that when accepting ETH deposits directly and indirectly via WETH, you are validating the case of msg.value > 0 and the amount of WETH transferred in the same function call. |
+| **G4.14** | Verify that there are no off-by one errors, especially with *>=*, *<=* and *length - 1*. |
 
 ## References
 
@@ -36,3 +41,4 @@ For more information, see also:
 * [Solidity Recommendations](https://consensys.github.io/smart-contract-best-practices/recommendations/)
 * [SWC-125 Incorrect Inheritance Order](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-125)
 * [EIP 1052: EXTCODEHASH Opcode](https://eips.ethereum.org/EIPS/eip-1052)
+* [Smart Contract Auditing Heuristics](https://github.com/OpenCoreCH/smart-contract-auditing-heuristics?utm_source=substack&utm_medium=email#readme)
diff --git a/2.0/0x100-General/0x105-G5-Access-Control.md b/2.0/0x100-General/0x105-G5-Access-Control.md
@@ -6,7 +6,7 @@ Access control is the process of granting or denying specific requests to obtain
 
 Ensure that a verified contract satisfies the following high-level requirements:
 * Users and other contracts are associated with a well-defined set of roles and privileges,
-* Access is granted only to the privileged users and contracts.
+* Access is granted only to privileged users and contracts.
 
 Category “G5” lists requirements related to the access control mechanisms of the smart contracts.
 
@@ -16,18 +16,19 @@ Category “G5” lists requirements related to the access control mechanisms of
 | --- | --- |
 | **G5.1** | Verify that there are no vulnerabilities associated with access control. | 
 | **G5.2** | Verify that the principle of the least privilege exists. Other contracts should only be able to access functions and data for which they possess specific authorization. | 
-| **G5.3** | Verify that new contracts with access to the audited contract adhere to the principle of minimum rights by default. Contracts should have a minimal or no permission until access to the new features is explicitly granted. | 
-| **G5.4** | Verify that the creator of the contract complies with the rule of the least privilege and their rights strictly follow the documentation. |
+| **G5.3** | Verify that new contracts with access to the audited contract adhere to the principle of minimum rights by default. Contracts should have minimal or no permission until access to the new features is explicitly granted. | 
+| **G5.4** | Verify that the creator of the contract complies with the rule of the least privilege and that their rights strictly follow the documentation. |
 | **G5.5** | Verify that the contract enforces the access control rules specified in a trusted contract, especially if the dApp client-side access control is present and could be bypassed. | 
 | **G5.6** | Verify that the calls to external contracts are allowed only if necessary. | 
 | **G5.7** | Verify that the code of modifiers is clear and simple. The logic should not contain external calls to untrusted contracts. | 
-| **G5.8** | Verify that all user and data attributes used by access controls are kept in trusted contract and cannot be manipulated by other contracts unless specifically authorized. | 
+| **G5.8** | Verify that all user and data attributes used by access controls are kept in a trusted contract and cannot be manipulated by other contracts unless specifically authorized. | 
 | **G5.9** | Verify that the access controls fail securely, including when a revert occurs. | 
 | **G5.10** | Verify that if the input (function parameters) is validated, the positive validation approach (allowlisting) is used where possible. | 
+| **G5.11** | Verify that passing priviledged access to another address is two-step operation. |
 
 ## References
 
 For more information, see also:
 
 * [OWASP Cheat Sheet: Access Control](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Access_Control_Cheat_Sheet.md)
-* [OpenZeppelin: Role-Based Access Control](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/852e11c2dbb19a4000decacf1840f5e4c29c5543/docs/access-control.md#role-based-access-control)
+* [OpenZeppelin: Access Control]([https://github.com/OpenZeppelin/openzeppelin-solidity/blob/852e11c2dbb19a4000decacf1840f5e4c29c5543/docs/access-control.md#role-based-access-control](https://docs.openzeppelin.com/contracts/3.x/access-control))
diff --git a/2.0/0x100-General/0x106-G6-Communications.md b/2.0/0x100-General/0x106-G6-Communications.md
@@ -2,10 +2,10 @@
 
 ## Control Objective
 
-Communications includes the topic of the relations between smart contracts and their libraries.
+Communications include the topic of the relations between smart contracts and their libraries.
 
 Ensure that a verified contract satisfies the following high-level requirements:
-* The external calls from and to other contracts have considered abuse case and are authorized,
+* The external calls *from* and *to* other contracts have considered abuse cases and are authorized,
 * Used libraries are safe and the state-of-the-art security libraries are used.
 
 Category “G6” lists requirements related to the function calls between the verified contracts and other contracts out of the scope of the application.
@@ -15,13 +15,14 @@ Category “G6” lists requirements related to the function calls between the v
 | # | Description |
 | --- | --- |
 | **G6.1** | Verify that there are no vulnerabilities associated with communications. | 
-| **G6.2** | Verify that libraries which are not part of the application (but the smart contract relies on to operate) are identified. | 
-| **G6.3** | Verify that delegatecall is not used with untrusted contracts. | 
-| **G6.4** | Verify that third party contracts do not shadow special functions (e.g. revert). | 
+| **G6.2** | Verify that libraries that are not part of the application (but the smart contract relies on to operate) are identified. | 
+| **G6.3** | Verify that *delegatecall* is not used with untrusted contracts. | 
+| **G6.4** | Verify that third-party contracts do not shadow special functions (e.g. *revert*). | 
 | **G6.5** | Verify that the contract does not, check whether the address is a contract using *extcodesize* opcode. | 
-| **G6.6** | Verify that re-entrancy attack is mitigated by blocking recursive calls from other contracts and following Check-Effects-Interactions pattern. Do not use *send* function unless it is a must. | 
+| **G6.6** | Verify that re-entrancy attack is mitigated by blocking recursive calls from other contracts and following **Check-Effects-Interactions** pattern. Do not use *send* function unless it is a must. | 
 | **G6.7** | Verify that the result of low-level function calls (e.g. *send*, *delegatecall*, *call*) from another contracts is checked. | 
-| **G6.8** | Verify that contract relies on the data provided by right sender and contract does not rely on tx.origin value. | 
+| **G6.8** | Verify that contract relies on the data provided by the right sender and the contract does not rely on *tx.origin* value. | 
+| **G6.9** | Verify that contract does not enforce usage of "phantom functions". |
 
 ## References
 
@@ -31,4 +32,5 @@ For more information, see also:
 * [DASP 10: Unchecked Return Values For Low Level Calls](https://www.dasp.co/#item-4)
 * [SWC-107 Reentrancy](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-107)
 * [SWC-112 Delegatecall to Untrusted Callee](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-112)
+* [Phantom functions](https://media.dedaub.com/phantom-functions-and-the-billion-dollar-no-op-c56f062ae49f)
 
diff --git a/2.0/0x100-General/0x107-G7-Arithmetic.md b/2.0/0x100-General/0x107-G7-Arithmetic.md
@@ -3,7 +3,7 @@
 ## Control Objective
 
 Ensure that a verified contract satisfies the following high-level requirements:
-* All mathematical operations and extreme variable values are handled in a safe and predictable manner.
+* All mathematical operations and extreme variable values are handled safely and predictably.
 
 Category “G7” lists requirements related to the arithmetic operations of the smart contracts.
 
@@ -12,18 +12,21 @@ Category “G7” lists requirements related to the arithmetic operations of the
 | # | Description |
 | --- | --- |
 | **G7.1** | Verify that there are no vulnerabilities associated with arithmetic. | 
-| **G7.2** | Verify that the values and math operations are resistant to integer overflows. Use SafeMath library for arithmetic operations before solidity 0.8.*. | 
-| **G7.3** | Verify that the unchecked code snippets from Solidity 0.8.* do not introduce integer under/overflows. | 
-| **G7.4** | Verify that the extreme values (e.g. maximum and minimum values of the variable type) are considered and does change the logic flow of the contract. | 
+| **G7.2** | Verify that the values and math operations are resistant to integer overflows. Use *SafeMath* library for arithmetic operations before solidity 0.8.\*. | 
+| **G7.3** | Verify that the unchecked code snippets from Solidity 0.8.\* do not introduce integer under/overflows. | 
+| **G7.4** | Verify that the extreme values (e.g. maximum and minimum values of the variable type) are considered and do change the logic flow of the contract. | 
 | **G7.5** | Verify that non-strict inequality is used for balance equality. | 
 | **G7.6** | Verify that there is a correct order of magnitude in the calculations. | 
 | **G7.7** | Verify that in calculations, multiplication is performed before division for accuracy. | 
 | **G7.8** | Verify that contract does not assume fixed-point precision and use a multiplier or store both the numerator and denominator. | 
+| **G7.9** | Verify that rounding uses secure granularity (e.g. seconds instead of days). |
+| **G7.10** | Verify that rounding in extreme conditions (e.g. very often) does not cause amplified losses (e.g. lack of interests accrued). Use RayWad library for such calculations. |
 
 ## References
 
 For more information, see also:
 
-* [DASP 10: Artithmetic Issues](https://www.dasp.co/#item-3)
+* [DASP 10: Arithmetic Issues](https://www.dasp.co/#item-3)
 * [OpenZeppelin: SafeMath](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/math/SafeMath.sol)
 * [SWC-101 Integer Overflow and Underflow](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-101)
+* [Significant Rounding Errors For Interest Calculation](https://github.com/OpenCoreCH/smart-contract-audits/blob/main/reports/c4/rigor.md#high-significant-rounding-errors-for-interest-calculation)