Summary
Smart contract code is intentionally out of scope for SEAL Certifications, but the operational process around smart contract security is not currently covered anywhere in the framework. A protocol's smart contract development lifecycle (audits, testing, change controls, bug bounty, vulnerability monitoring) is core operational security and belongs in scope.
Gap
A review of the current certs shows no controls covering security audits, formal testing, or bug bounties. Only Incident Response monitoring (ir-2.x) touches deployed smart contracts.
Proposal
Add a new section to DevOps & Infrastructure (sfc-devops-infrastructure), e.g. di-5: Smart Contract Development Lifecycle, with:
- di-5.1.1 — Security review before deployment and changes. Independent security audit(s) before initial mainnet deployment; re-audit or focused review for upgrades, patches, and significant parameter/config changes; a defined testing regime (unit, integration, invariant/property, fuzzing); and a documented standard for what level of review each change type requires.
- di-5.1.2 — Bug bounty and vulnerability disclosure. A documented vulnerability disclosure policy and, proportional to scale/TVL, a bug bounty program with defined scope, severity/reward tiers, and response timeframes.
Deployed-contract vulnerability monitoring is already partly covered by Incident Response (ir-2.x); di-5 should reference it rather than duplicate it.
Scope note to preserve: this assesses the process and assurance around smart contracts, not the contract code itself, which remains out of scope.
Open questions
- New section (di-5) vs. adding controls under di-2 (Source Code & Supply Chain) or di-3 (CI/CD)?
- Bug bounty as a required control vs. recommended-by-classification?
Raised by @zS-SFC.
TODO (housekeeping): create a certifications label for the repo and apply it to certs issues like this one. The certs contribution guide (#521) directs contributors to open issues with the certifications tag, but that label does not exist yet. This issue currently uses the closest existing labels instead.
Summary
Smart contract code is intentionally out of scope for SEAL Certifications, but the operational process around smart contract security is not currently covered anywhere in the framework. A protocol's smart contract development lifecycle (audits, testing, change controls, bug bounty, vulnerability monitoring) is core operational security and belongs in scope.
Gap
A review of the current certs shows no controls covering security audits, formal testing, or bug bounties. Only Incident Response monitoring (
ir-2.x) touches deployed smart contracts.Proposal
Add a new section to DevOps & Infrastructure (
sfc-devops-infrastructure), e.g. di-5: Smart Contract Development Lifecycle, with:Deployed-contract vulnerability monitoring is already partly covered by Incident Response (
ir-2.x); di-5 should reference it rather than duplicate it.Scope note to preserve: this assesses the process and assurance around smart contracts, not the contract code itself, which remains out of scope.
Open questions
Raised by @zS-SFC.
TODO (housekeeping): create a
certificationslabel for the repo and apply it to certs issues like this one. The certs contribution guide (#521) directs contributors to open issues with thecertificationstag, but that label does not exist yet. This issue currently uses the closest existing labels instead.