Summary

Security failures in smart contracts, from poor access control or errors in code, to implementation of governance mechanisms, have caused very significant losses. The Smart Contract Security Standard is a set of security requirements for developing, operating and evaluating a Smart Contract System to minimise the risk of such failures.

Requirement Domains

The Smart Contract Security Standard covers the following requirement domains:

• 1. Development
• 2. Testing
• 3. Deployment and Upgrades
• 4. Operations
• 5. Governance

These domains only outline the outcomes of the standard, not the specifics of how each requirement would be met.

1. Development

Secure development practices are crucial to ensuring that a Smart Contract System is not vulnerable through problems in code. This covers both code produced by the Smart Contract Project for its own use, and so-called supply-chain bugs, where code produced by a third-party (or, increasingly commonly by an automated system) is used that introduces vulnerabilities later exploited by malicious actors.

A crucial aspect of ensuring security in development is testing - and re-testing. New vulnerabilities are discovered from time to time that can impact existing code, but also any code that has not been carefully tested by developers will instead likely be tested by malicious actors, and weaknesses found and exploited.

There are multiple approaches to testing. On the formal side, a range that includes unit tests and formal verification of systems, while it is also important to follow developments outside managing code, such as vulnerability research and market factors that can influence the attractiveness of different targets or exploit methods.

These differences in turn can have direct impact on development. While unit tests are often part of the work required in a small code change, discovering a vulnerability can also occur with a long-running fuzzing program scanning a static branch of code, or re-analyzing old code in light of new knowledge.

Naming Conventions

Use Clear Names
Naming within code SHOULD be straightforward and understandable for a third party.

Glossary
Any non-obvious terms SHOULD be defined in a glossary.

Style Guides

Use Language Style Guides
Code SHOULD follow the respective language style guide (e.g. for Solidity).

Use Style Guide
Code MUST adhere to a style standard available to all who contribute code.

Modular Design

Use Modular Code
Code SHOULD be organized into modular, self-contained components with clear interfaces.

Use Concise Code
Methods SHOULD be concise (e.g., <100 lines) and serve a single functionality.

Document Dependencies
The Smart Contract Project SHOULD document and MUST provide documentation of dependencies between modules.

This facilitates review and auditing, leading to a higher likelihood of any problems being correctly identified.

Use Existing Library Code
The Smart Contract System SHOULD use appropriate library code rather than custom-written code.

Actively maintained open source libraries enable a Smart Contract System to inherit the security assurances and practices of that library.

For example, popular open source libraries are often subject to review by many developers, maintain vulnerability disclosure programs, bug bounty programs, incident response procedures, and conduct code security audits.

Good code libraries can provide support functions that make programming easier and so less likely to introduce errors than coding with "system primitives" such as fundamental cryptographic functions. They also often have a wealth of associated documentation, tutorials, and example patterns.

Widely-used open-source code is likely to be familiar to security auditors, which can make review more efficient.

Finally, contributing to well-documented and well-maintained open-source code can be cheaper than replicating the entire effort, and contributes to overall ecosystem security by making the improvements available to others.

On the other hand, it is possible that code specifically developed for a limited purpose is more efficient, or reduces attack surface.

Best practice is to document decisions to write custom code instead of using an available library, and to ensure that known versions are adopted (see also Manage External Dependencies).

Code Operations

Use Consistent Steps
Code SHOULD follow similar steps in operations performed.

This improves readability, and re-use of patterns.

Dependencies

Document External Dependencies
The Smart Contract Project MUST document external dependencies.

Manage External Dependencies
The Smart Contract System SHOULD manage dependencies as third-party systems.

This requirement applies both to code directly included in the Smart Contract System, and to tools that the Smart Contract Project depends on for code management, because these tools can be subject to vulnerabilities, be used as a vector for injecting malicious code, or otherwise disrupt development in ways that impact security.

For third-party code such as open-source libraries, this means adopting tools such as Node Package Manager [NPM] for javascript library management rather than a "set-and-forget" incorporation of a third-party codebase by copy-paste.

It is important to ensure that known versions are incorporated in a controlled manner, such checking release hashes, ensuring code is obtained from known reliable sources, and reviewing updates for security, as well as adopting updates that resolve security issues in a timely manner.

Ensure Oracles are Replaceable
Code that introduces external dependencies on Oracles MUST enable replacing any Oracles.

Version Control

Use Version Control
The Smart Contract System MUST use a version control system to record the source of each change.

Over the life of a Smart Contract System, the ability to identify where code came from is important for maintenance, and reassessment of old code for the presence of newly-discovered vulnerabilities.

In a situation where errors have been introduced, restoring the integrity rapidly is easier with this traceability.

"AI-generated" software code can contain subtle bugs that are not typical of human coders. While automated systems can generate a large codebase rapidly, they can also introduce specific risks, including producing code with subtle bugs that they later exploit, just as a malicious programmer can do.

Make Atomic Commits
Each commit MUST contain a single logical change with a clear, concise description of the change made.

This facilitates code security auditing and helps prevent unintended modifications.

Tag Releases
Releases MUST be tagged with version numbers (e.g., semantic versioning).

Tag Verifiable Source
The Smart Contract Project SHOULD provide documentation of the commit hash.

This enables verifying that it matches the audited code (in accordance with the Code Security Audit requirement below) and the deployed code (in accordance with the Bytecode Verification requirement below).

Log Automated Development
The Smart Contract Project SHOULD maintain logs of all sessions where code is generated automatically.

This includes information such as tools and settings used, prompts and "conversation" records, with code that is rejected as well as code that is used in production.

Source Code Documentation

Document Public API
The source code of the Smart Contract System MUST document every contract, function, event, and variable included in the public API.

Best Practice is to use a standard format, such as using documentation comments in NatSpec for Solidity.

Document Sensitive Functions
The source code of the Smart Contract System SHOULD document private or internal functions that implement sensitive logic.

Inline comments

Explain Functions Inline
Inline comments SHOULD explain complex functionality and provide relevant information on the current status of code sections.

For example, as well as standard [NatSpec] documentation of functions, parameters, etc, explain unusual algorithms optimisations, identify code that is expected to be re-factored or deprecated in future, etc.

Cryptographic Considerations

Document Cryptographic Dependencies
The Smart Contract Project MUST document all cryptographic algorithms and primitives used by the Smart Contract System.

This includes signature verification schemes, hash functions, as well as any off-chain cryptographic operations that the system depends upon.

Allow Cryptographic Upgradability
The Smart Contract System SHOULD allow for upgrading or replacing cryptographic schemes without requiring complete redeployment of the system.

Assess Quantum-Related Risks
The Smart Contract Project MUST provide documentation of risks related to the long-term viability of cryptographic primitives used by the Smart Contract System.

This includes exposure to quantum computing threats, among other threats to cryptography, particularly for systems intended to secure assets or data over extended time horizons.

2. Testing

Testing is a critical component of secure development, to identify that code functions correctly as expected, including in usage outside "normal" bounds, and that it does not introduce vulnerabilities.

Testing takes many forms, including unit tests, formal verification, fuzzing, and running a system on a closed network. Developing appropriate tests is a significant job, and best practice is to have testing that is created and managed by developers directly as well as testing that is created by parties independent of development. This is because while developers know the codebase well and can usually easily identify key aspects that are not obvious to third parties, they are also likely to hold assumptions that are not documented and are not reflected in the testing they develop.

Development Testing

Provide Tests
The Smart Contract System code MUST include comprehensive test coverage.

This can include static and dynamic analysis and where applicable, formal verification.

The expectation is that tests will cover all the functionality of a Smart Contract System, and verify that in each case it behaves as expected and documented.

While higher test coverage does not guarantee that the test suite can detect all vulnerabilities, it does indicate that an appropriate level of effort is being devoted to testing.

Provide Tests Independently
A substantial proportion of tests SHOULD be written by parties who did not develop the code.

Best practice is for most tests to be created independently of code development, to minimize the risk that assumptions in coding are carried through without testing the impact, as well as because general security hygiene means not "marking your own homework".

Where code and tests are generated by automated "intelligent" systems, this requirement means that one such system is generating tests without being connected to or communicating with the system(s) involved in generating code.

Code generation systems using Large Learning Models and so-called generative AI can generate tests, however they are also capable of suppressing tests that the code they generate does not pass.

Human developers can retain assumptions that they do not test, where an independent third party would instead explicitly produce test cases.

Define Invariants
The Smart Contract Project SHOULD provide documentation of key invariants.

Up To Date Test Suite
The test suite and its dependencies MUST be up to date, such that all tests execute and pass on a fresh installation.

Test Edge Cases
The test suite MUST cover edge cases.

This is important because malicious actors often succeed in attacking smart contracts by considering ways that they are not intended to be run.

Typical edge cases that can identify problems include providing invalid, extreme, or empty values as inputs, unusual sender/recipient pairings (such as same sender and recipient), high volumes of transactions, and transactions that are expected to cause a failure.

Run Tests Locally
The test suite MUST be executable in local forks.

For developers integrating with multiple Smart Contract Systems, best practice includes running a set of integration tests against local forks of mainnet (i.e. the primary production blockchain network). Leveraging forking capabilities of existing tools can be a useful approach to testing edge cases.

Because this approach may require more set up, and maintenance efforts, it is often helpful to run a set of smoke tests before deployment against a local fork of mainnet.

Use Test Helpers
The test suite SHOULD include helpers.

It is helpful when developers spend time building and using helpers and utilities, as they make tests more legible and easier to write.

The test suite can include more advanced tests. Developers can incorporate a range of more advanced testing tools to achieve a greater degree of confidence in code correctness. Such tools include those for fuzzing, mutation testing, and property based testing.

Use Testing Standards
The test suite SHOULD meet generally accepted standards.

For example, the Smart Contract Security Verification Standard [SCSVS] item SCSVS-CODE-3: Test Coverage could be relevant.

Smart Contract Security Audit

Complete A Code Security Audit
The Smart Contract Project MUST [provide documentation] of a code security audit of the Smart Contract System that is put into production.

Although this cannot guarantee the security of the code, an audit that correctly follows a recognised methodology can ensure that certain known vulnerabilities are not present.

Although particular code security audit methodologies vary, best practices for comprehensive code audit include

• running automated static analysis tools,
• applying automated testing methodologies such as fuzzing, and
• human review of
  • code, generally including line by line checking,
  • interactions within the Smart Contract System and with external dependencies,
  • possibilities for external code to interact with the Smart Contract System, and
  • behaviour with unexpected inputs or use patterns.

The expectation of a code audit is that auditors attest that the Smart Contract System

• is not vulnerable to a described set of known attacks,
• operates as expected based on documentation provided to external users, and
• has trustworthy governance mechanisms.

For example, for a solidity codebase, an [EthTrust] level [Q] Conformance Claim asserts the smart contract has been extensively tested, including known solidity compiler bugs and general vulnerabilities known before the publication of the relevant EthTrust version.

Independent Code Auditors
The code security audit used to meet the requirement Complete a Code Security Audit MUST be conducted by at least two individuals who did not take part in the development of the smart contract code.

A single audit of the exact code deployed, by a third-party blockchain security audit firm, or by individuals within the Smart Contract Project who were not involved in the code development for the Smart Contract System, minimally satisfies this requirement if two auditors are assigned.

Best practice is to have multiple iterations of security reviews from multiple sources, including

• a clear process to ensure issues discovered in review are fixed, and the resulting codebase re-audited
• audits that check conformance to relevant security standards, such as EthTrust for Solidity code,
• separate security review cycles undertaken directly with people who have developed the code,
• security audit by a team member who was not involved in developing the audited code, and
• at least one security audit by a specialized third-party blockchain security audit firm.

There are a number of factors that impact security audits. Excessive familiarity with code can lead to auditors ignoring important changes, or longstanding issues. Unfamiliarity with the code can lead to auditors missing subtle interactions that are obvious to the developers, and could be exploited.

Early review of the architecture and continuous assessment of changes can stop vulnerabilities being introduced early, minimising the need to find and remediate them later and often reducing the amount of work required to do so.

Likewise, Test-driven development (see the Development Testing requirements can minimise the work to audit code, and in particular the amount of remediation work required.

Ensure Sufficient Scope
The Smart Contract Project and the code security auditors MUST agree to a broad enough scope to enable the auditors to conduct a thorough review all aspects of the Smart Contract System that could reasonably have a material impact on its proper functioning.

Some components of a Smart Contract System could be well-understood open-source code libraries, that an auditor judges do not need a specific audit. Likewise, some code updates or parameter settings could be agreed not to have a material impact. In other cases a responsible auditor will want to ensure that these type of changes are reviewed in detail, for example because they impact other systems interacting with the Smart Contract System.

Publish Code Audit Report or Attestation
The Smart Contract Project SHOULD document all code security audits of the Smart Contract System in order to demonstrate the security posture of the Smart Contract System. The Smart Contract Project MAY publish an attestation confirming the completion of a code security audit in lieu of publishing a full report.

Re-Audit Material Changes
The Smart Contract Project MUST conduct additional code security audits of any material changes to the Smart Contract System (or any components thereof) before such changes are put into production.

Material changes in this context means any change that affects the behaviour of the Smart Contract System, or interactions with it, and code changes that are designed to improve coding practice and maintain the same behaviour.

In other words, the majority of changes to code, as well as some changes in settings.

While it is not always necessary to re-review code that is not changed in an update, or unmodified code from an established open-source library, it is often necessary to re-verify its interactions with code that has changed or is new.

Note that this requirement applies however code is updated, including fixing items identified as vulnerabilities following a security audit, performance enhancements and new features added in the course of development, etc.

3. Deployment and Upgrades

Deploying code, and in particular deploying upgrades, is a critical operation that introduces some specific risks. The requirements in this domain help ensure that procedures to deploy code to blockchain networks do not risk introducing new vulnerabilities.

Local/Testnet Testing

Use Testnets
The Smart Contract Project MUST test proposed code including updates in a controlled test network environment prior to mainnet deployment

Best practice is to use official protocol testnets where these are available and match the mainnet protocol. It is important to keep in consideration that even seemingly small differences, such as contracts deployed at different addresses, or different gas pricing on a testnet, can change the behavior of a Smart Contract on a different network and to design testing accordingly.

Document Deployment Network Differences
The Smart Contract Project MUST provide documentation of network-specific requirements and differences for each network where they deploy the Smart Contract System.

Meeting this requirement includes documenting networks used for test deployments.

Compilation

Deterministic Compilation
The compilation of the Smart Contract System’s source code MUST be deterministic, and MUST proceed without error or any compiler issues.

Provide Compilation Metadata
The Smart Contract Project SHOULD document and MUST provide documentation of relevant compilation metadata to verify deployed bytecode.

Verified Bytecode

Publish Verification
The Smart Contract Project SHOULD document and MUST provide documentation that the deployed bytecode matches the source code audited under the requirement Complete a Code Security Audit.

For example for code written in Solidity, a Conformance Claim for EthTrust Security Levels EthTrust includes such information.

4. Operation of the Smart Contract System

Poor operational practices can enable attacks, and have frequently caused the impact of both deliberate attacks and simple errors to be magnified. The requirements in this domain help ensure effective operation of the deployed Smart Contract System, and response to any anomalous behavior.

Source Code

Publish Source
The Smart Contract System source code SHOULD be made available publicly.

This helps to ensure transparency of the service provided, and enables responsible bug disclosure and patching.

Public Documentation

Documentation that is not accurate and up-to-date does not meet this requirement.

See also Document Public API, Document Sensitive Functions, Document Governance, and Maintain Current Risk Assessments.

Address Book

Identify Contracts Used
The Smart Contract Project SHOULD document and MUST provide documentation of the addresses of all smart contracts included in the current version of the Smart Contract System.

Best practice is to provide links to each smart contract on a block explorer for the relevant blockchain network(s), as part of the overall documentation.

Other smart contract system-specific guidance to minimize risks targeting users is encouraged (e.g. identifying previous smart contracts that are no longer in use by the Smart Contract System and may contain vulnerabilities).

Security Contact

Identify Security Contact
The Smart Contract Project MUST appoint a designated security contact with sufficient skills and experience to manage any potential security issues.

Document Security Contact
The Smart Contract Project SHOULD document confidential methods for contacting the security contact.

It best practice to provide the security contact information in the source code (e.g., in the NatSpec for EVM smart contracts), and in other online public documentation, including implementing [RFC9116].

Provide Timely Security Response
The response to secure contact methods SHOULD be timely "24/7".

"24/7", or round-the-clock coverage is best practice. An important consideration is that deliberate hacking attempts often give considerations to different timezones, weekends, and holidays, aiming for times when coverage is likely to be reduced. This means Smart Contract Projects need to strive for the greatest coverage possible.

Risk Assessment and Monitoring

Keeping risk assessments up to date is partially a question of revising them over time, but best practice is also to reassess risk in response to events such as activating an incident response, or major market or regulatory changes.

Systemic risks can arise where, for example, a blockchain network is increasingly centralized, or where there is centralization is back-end services that are crucial to the ecosystem. Centralized services such as cloud computing or storage can be a single point of failure for a Smart Contract Project, but also for a blockchain network, if their use is too widespread and redundancy is insufficient across the ecosystem. Catastrophic events have demonstrated that often there is a high degree of reliance on a narrow range of centralized services, leaving blockchains vulnerable to apparently external failures.

Use Monitoring
Monitoring MUST alert those responsible for the security of the Smart Contract System if the foregoing risks occur.

Monitoring Triggers Response
Monitoring alerts MUST trigger an Incident Response.

Transaction Screening

Use Transaction Screening
A Smart Contract System MAY implement transaction screening on some or all activity to permit only certain pre-defined types of activity using the Smart Contract System.

For example, a Smart Contract System could simulate transactions before they are executed to determine if they present security or regulatory risks, and block them (see Trigger Automated Response) if they are flagged as high risk.

Up-to-date Security Practice and Knowledge

Integrate Security Updates
The Smart Contract Project MUST provide documentation of how it integrates new security information and updates.

Best practice is to provide attestation, or point to an overall process, rather than attempt to provide an exhaustive description.

Vulnerability Disclosure Program

Vulnerability Disclosure
The Smart Contract Project MUST document a vulnerability disclosure program for responsible disclosure of vulnerabilities found by third parties.

Bug Bounty Program
The Smart Contract Project SHOULD offer sufficient incentives to motivate responsible disclosure of vulnerabilities found by third parties.

For example, it is best practice for a Smart Contract Project to offer a "Bug Bounty Program" that provides incentives to third parties that responsibly submit vulnerabilities that are confirmed as legitimate risks. Determining the amounts that bug bounties pay is typically informed by the value of disclosure or impact of exploitation, and the Smart Contract Project’s risk tolerance and overall financial state.

Incident Response

Plan Incident Response
The Smart Contract Project MUST implement an incident response plan to guide the response to any security incidents.

Best Practice for an Incident Response Plan is to include at least

• triage of reported vulnerabilities,
• appropriate immediate mitigation,
• seeking additional help when appropriate
• communication to keep relevant stakeholders informed in real time and provide a summary after the incident, and
• a post-mortem analysis and report that includes updating Incident Response plans where appropriate.

Immediate mitigations can include pausing transactions, reverting updates that caused problems. If a Smart Contract Project has an existing relationship with a third-party security provider, or is able to seek help from a reputable emergency response service such as Seal-911 this can provide resources to address problems.

It is a bad practice to be seeking new security relationships in the middle of a security incident, both for the delays this will incur and because there is a heightened risk of being "phished" and engaging a malicious actor, whether they exacerbate the instant problem or leverage an apparently productive relationship to integrate themselves and cause harm later.

Maintain Incident Response Plans
The Smart Contract Project SHOULD test and update the Incident Response plan at least annually.

Best practice is to simulate an actual incident like a "war game", with limited information release to mirror a real situation, testing whether communications are timely, attack scenarios are identified correctly and responses are as effective as possible. It is important that public communication does not create the impression that a real attack is underway during the simulation, and also to manage the slight possibility that a genuine incident does occur during a simulation.

Analysis of the simulation, and lessons learned, can provide important insights to update the Incident Response Plan.

5. Governance

Governance failures, or non-transparent governance that is vulnerable to malicious action, has caused many types of failure, from "rug pulls" to an inability to adjust operations in changed ecosystems. This domain's requirements are to ensure that the processes for managing and making any material changes to the functionality or operation of the Smart Contract System are clearly communicated to users, and followed.

Governance Disclosure

This covers both changes originating with decisions made by people within the Smart Contract Project, and changes that are actually automated such as pausing or reconfiguring a smart contract in response to a trigger from security monitoring.

Unclear documentation, excessive legal terminology, overreach in terms, or technical detail that obscures the meaning, can all increase the risk that users do not understand the governance. This in turn can lead to both reputational and direct legal risk.

Update Documentation
Any expected changes to the Smart Contract System (including changes to its governance process) MUST be notified to users in advance and reflected in documentation without delay.

Out of date documentation leads to misinformed users, and can in turn produce both reputational and legal risk for the Smart Contract Project

This requirement applies to all documentation; see also Document Overall System, Document Public APIs, and Document Sensitive Functions.

Identify Governance participants
The Smart Contract Project MUST provide documentation of all entities involved in control or governance of the Smart Contract System.

For example, if the Smart Contract System can be upgraded by a multisignature wallet, the persons or entities acting as signers on the multisig would be identified and verified by the Smart Contract Project or by a designated third party through a public attestation.

This applies to parties able to perform or participate in Critical Actions, off-chain technology components, individuals, or entities that have privileges to interact with the Smart Contract System, including any of the following:

• Emergency procedures such as pausing, locking, or self-destruction of the Smart Contract System
• Modifying any allow list or deny list
• Smart Contract System Upgrades (See also Requirements Domain 4: Upgradability)
• Account management that impacts any Privileged Role

Specific types of applications can have additional Privileged Roles.

For example, if the Smart Contract System manages a Token, the ability to mint tokens, burn them from a user's account, or freeze their transfer, affecting the supply and thus value of a token directly, is a Privileged Role subject to this requirement.

Upgrades

Use Safeguards
Governance processes MUST include rules that safeguard the interests of users in the event of a change to the scope of the Smart Contract System.

Example safeguards include:

• Ensuring transparency in making decisions regarding changes that impact the community;
• Providing reasonable notice of the change in an easily accessible location online;
• Using timelocks for staging changes;
• Providing users with a documented path for exiting the protocol in a timely manner if they do not wish to participate after changes are made; and
• Enabling users to continue using the version that operated prior to the change in the same conditions.

Privileged Roles

Limit Privileged Roles
Privileged Roles MUST be strictly limited to those necessary for proper performance of the Smart Contract System.

Decentralize Privileged Roles
Privileged Roles SHOULD be decentralized.

This can be achieved through a variety of approaches, including the use of Multisigs or Multi-Party Computing, governance provisions implemented within the Smart Contract System, or organizational controls such as a requirement for separate approvals.

For the case of Incident Response it is important to balance the need for rapid protective action with the risk that centralizing the necessary capacities increases vulnerability in the case of a malicious actor, or of an honest actor being compromised.

Secure Privileged Roles
Entities with Privileged Roles (including as participants of a Multisig or as developer of code) MUST implement appropriate security and compliance standards based on the identified risks related to their role.

This requirement can be met by applying standards with a broad scope covering many aspects of security, such as [SOC 2], [ISO 27001], or through more specifically targeted blockchain-specific security standards, such as the "BSSC Key Management Standard" [KMS], and "BSSC General Security and Privacy Guidelines" [GSP], respectively covering the specifics of managing cryptographic keys, and general security practices for organizations operating in blockchain ecosystems.

References

[SCSVS]

"OWASP SCSVS" https://scs.owasp.org/SCSVS/

[EthTrust]

"EEA EthTrust Security Levels Specification". Ed. Chaals Nevile, EEA, 2022- Latest version URL https://entethalliance.org/specs/ethtrust-sl/, current latest version ("Version 2") URL https://entethalliance.org/specs/ethtrust-sl/v2/, latest Editor's Draft https://entethalliance.github.io/eta-registry/security-levels-spec.html

[GSP]

"General Security and Privacy Guidelines", Ed. Joe D'annolfo and John Kemp, BSSC 2025. https://specs.blockchainssc.org/gsp/

[ISO 27001]

"ISO/IEC 27001 - Information security management systems", ISO. https://www.iso.org/standard/27001

[NatSpec]

"NatSpec Format - Solidity Documentation", Ethereum Foundation. https://docs.soliditylang.org/en/latest/natspec-format.html

[NPM]

"npm - a JavaScript package manager", npm. https://www.npmjs.com/package/npm

[KMS]

"Key Management Standard", Ed. Mark Nesbitt, Akshar Rawal, and John Kemp, BSSC 2025. https://specs.blockchainssc.org/kms/

[RFC2119]

"Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, IETF 1997. https://www.rfc-editor.org/rfc/rfc2119.html

[RFC8174]

"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", B. Leiba, 2017. https://www.rfc-editor.org/rfc/rfc8174.html

[RFC9116]

"A File Format to Aid in Security Vulnerability Disclosure", E. Foudil and Y. Shafranovich, IETF 2022. https://www.rfc-editor.org/rfc/rfc9116.html

[SOC2]

"SOC 2® - SOC for Service Organizations: Trust Services Criteria", AICPA. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2

How to Read This Document

Requirements

The requirements are the core of this document. Each requirement has a standard structure:

• A name (which can be linked to, whether in a specific version or in the latest published version),
• A statement of the requirement explaining a testable control that the requirement is met, and optionally
• further explanation, that is not a formal part of the requirement but is intended to be helpful in assessing whether a requirement has been met or understanding why it is there.

As an example the following requirement:

Independent Code Auditors
The code security audit used to meet the requirement Complete a Code Security Audit MUST be conducted by at least two individuals who did not take part in the development of the smart contract code.

A single audit of the exact code deployed, by a third-party blockchain security audit firm, or by individuals within the Smart Contract Project who were not involved in the code development for the Smart Contract System, minimally satisfies this requirement if two auditors are assigned.

Best practice is to have multiple iterations of security reviews from multiple sources, including

• a clear process to ensure issues discovered in review are fixed, and the resulting codebase re-audited
• audits that check conformance to relevant security standards, such as EthTrust for Solidity code,
• separate security review cycles undertaken directly with people who have developed the code,
• security audit by a team member who was not involved in developing the audited code, and
• at least one security audit by a specialized third-party blockchain security audit firm.

There are a number of factors that impact security audits. Excessive familiarity with code can lead to auditors ignoring important changes, or longstanding issues. Unfamiliarity with the code can lead to auditors missing subtle interactions that are obvious to the developers, and could be exploited.

Early review of the architecture and continuous assessment of changes can stop vulnerabilities being introduced early, minimising the need to find and remediate them later and often reducing the amount of work required to do so.

Likewise, Test-driven development (see the Development Testing requirements can minimise the work to audit code, and in particular the amount of remediation work required.

Has the name "Independent Code Auditors".

Its stable URL is https://specs.blockchainssc.org/scs/#req-independent-auditors which points to the requirement in the latest published version of the specification.

The statement of requirement is

The code security audit used to meet the requirement Complete a Code Security Audit MUST be conducted by at least two individuals who did not take part in the development of the smart contract code.

The rest of the text is explanatory. While it is helpful to some audiences, it is not a formal part of the requirement that needs to be met.

Requirements are grouped into a set of Requirement Domains, and generally into smaller groups within each Requirement Domain, as a convenience. Requirements are not prioritized, as specific priorities will depend substantially on specific implementations and use cases.

Links

Some kinds of link used in this document are identified by specific formatting:

Glossary terms

Terms with a specific meaning defined in the BSSC Glossary appear in Title Case in italic text, and link to the glossary entry, for example Token Contract.

References

Links to external resources appear as follows: [RFC2119], and link to the relevant item in the References section.

Document Status and Feedback

This document is the BSSC Smart Contract Security Standard version 1, developed by the Technical Working Group of the Blockchain Security Standard Council (BSSC Inc.).

The BSSC requests feedback on this document, which can be provided via our contact form.

Disclaimer of Warranty and Liability

NO WARRANTIES: THIS SPECIFICATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, COMPLETENESS AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL BSSC, ITS MEMBERS OR ITS CONTRIBUTORS BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE SPECIFICATION.

THIRD PARTY RIGHTS: Without limiting the generality of the foregoing, BSSC ASSUMES NO RESPONSIBILITY TO COMPILE, CONFIRM, UPDATE OR MAKE PUBLIC ANY THIRD PARTY ASSERTIONS OF PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS THAT MIGHT NOW OR IN THE FUTURE BE INFRINGED BY AN IMPLEMENTATION OF THE SPECIFICATION IN ITS CURRENT, OR IN ANY FUTURE FORM. IF ANY SUCH RIGHTS ARE DESCRIBED ON THE SPECIFICATION, LICENSOR TAKES NO POSITION AS TO THE VALIDITY OR INVALIDITY OF SUCH ASSERTIONS, OR THAT ALL SUCH ASSERTIONS THAT HAVE OR MAY BE MADE ARE SO LISTED.