DSA Security Review Board · Procedure v1.0
How an auditor earns a technical recommendation
A useful recommendation must connect an auditor's work to your system's risks. Public evidence checks establish what can be examined; qualified reviewers then assess the quality and relevance of that work.
Published . Committee appointments are pending. No provider has been assessed under this procedure.
What the labels mean
- Featured
- Editorial placement. It carries no technical score and does not imply approval by security reviewers. Pharos Production currently has this placement; it is assessed by the same evidence rules as every provider.
- Provider statement
- A claim attributed to a dated source, such as an offered language or a starting price. DSA has not independently demonstrated the capability.
- Confirmed in cited evidence
- A narrow fact checked in an identified artifact, such as the presence of a commit in a report. It does not validate the whole engagement.
- Insufficient evidence
- The source check did not establish the fact. An unavailable website or confidential report is not proof of poor work.
- Outdated / conflicting
- A source is no longer current or material sources disagree. These fields cannot support a current recommendation until resolved.
- Technical review
- Not assessed, in review, assessed for a named scope, or suspended. No generic "verified safe" badge is issued.
The expert group and its safeguards
The proposed board has at least three identified practitioners covering smart contract exploitation, protocol and economic risk, verification and testing, security engineering and disclosure or incident response. Membership requires public technical work or privately inspectable workpapers, relevant practice and an approved conflict declaration.
Each assessment is assigned to two reviewers independently. A third specialist resolves a disagreement of two or more scale points, an eligibility dispute or a disputed critical conclusion. Recused reviewers do not count toward the two required reviews. At least one assigned reviewer must demonstrate experience in the target ecosystem and protocol class.
Reviewers disclose employment, investments, referral fees, paid engagements and other material ties for the preceding 24 months. A material tie to the applicant excludes a reviewer from that assessment. Directory placement, sponsorship or fees cannot buy points. Commercial relationships must be disclosed beside any future recommendation.
Eligibility before scoring
- Establish the applicant's identity, accountable team, and authorship of submitted work.
- Obtain reports for at least three distinct projects from the preceding 24 months, including one relevant to the intended engagement, with identifiable initial scope and final outcome. Private work can be reviewed under confidentiality; publish a redacted rationale and disclose the restricted evidence.
- Inspect finding evidence and the fix-review trail. Request reproducibility material for at least one material finding where such a finding exists; do not penalize a clean audit solely for finding no vulnerabilities.
- Resolve material authenticity problems or undisclosed conflicts before proceeding. Record missing evidence as pending. Verified falsification is grounds to reject or suspend the assessment.
Seven criteria, weighted by relevance to security work
These weights are DSA's proposed policy. They are not a validated predictor of audit success. Reviewers score each criterion from 0 to 4 and cite the evidence behind the score. The anchors below describe 0, 2 and 4; 1 and 3 require a written explanation between adjacent anchors.
| Criterion | Weight | Required evidence and scoring anchors |
|---|---|---|
| Technical finding quality | 25% | Reports from three distinct projects with root cause, impact, exploit conditions and reproducible proof or a precise execution trace.
|
| Depth and threat model | 20% | A scoped threat model, trust boundaries, privileged roles, economic assumptions, test design and explicit exclusions.
|
| Scope and version traceability | 15% | Repository, immutable commit, file scope, compiler/configuration where relevant, report version and remediation commit.
|
| Demonstrated specialization | 15% | At least two relevant engagements or equivalent technical artifacts in the target language, chain and protocol class.
|
| Fix verification | 10% | Finding-by-finding resolution status, linked fixes, retest evidence and unresolved-risk acceptance.
|
| Internal quality control and response | 10% | Independent internal review, escalation, disclosure handling and documented correction or incident follow-through.
|
| Transparency and conflicts | 5% | Named accountable team, engagement boundaries, subcontracting, financial relationships and conflicts of interest.
|
Unknown is not zero. A total is withheld if any criterion lacks a supported score. A complete total is the sum of weight × score ÷ 4. No threshold such as "80 means safe" is used. A recommendation must state suitable project types, exclusions, unresolved risks, evidence coverage and reviewer disagreements.
Review, publication and renewal
- The research editor assembles a dated evidence packet with immutable artifact identifiers and a claim ledger.
- Two eligible reviewers score the packet independently, then compare findings. The third reviewer documents any adjudication.
- The provider can correct factual errors and submit evidence before publication. It cannot veto an adverse supported conclusion.
- The published decision names reviewers, conflicts, scope, score rationale, limitations and date. A recheck is due after 12 months or a material team, process or evidence change.
- An appeal supplies specific counter-evidence through the correction channel and is assigned to a reviewer outside the original pair. Credible falsification or a material conflict suspends a recommendation while investigated. A later exploit prompts scope-aware review; it is not automatic proof that an auditor was negligent.
Technical references and their limits
OWASP SCSVS informs EVM control coverage. Its assessment guidance informs evidence and workpapers. The EEA EthTrust Security Levels v3 specification provides Ethereum-specific requirements. These references do not certify DSA or its providers; additional expertise is needed for non-EVM and off-chain systems.
Public-source research is prepared with AI assistance and is labeled separately from expert review. Source failures, selection bias and unverified provider claims remain visible in each original report.
DeFiSec dataset access terms 1.0
Published .
These terms cover DeFiSec's original dataset descriptions and annotations, and any rights it holds in the selection and arrangement of records.
You may access and download the published data files for your own reference. All other rights in protected DeFiSec material are reserved. To request permission for reuse, email alliance@defisec.info.
Third-party source material and software listed in the tools directory remain subject to their owners' terms. This license grants no rights in those materials and does not restrict uses permitted by law.