Full Report
In some way, shape or form, the Bug bounty scope needs documented scope. On Immunefi, this typically labels contracts or websites in scope and assets at risk. So, what happens when the company writes a new contract but it is not put on the scope list? Well, the contract is no longer in scope! To me, this is really dumb. Obviously, you want to define what you pay out for. At the same time, shouldn't it just be that there are customer funds at risk? Funds at risk is funds at risk. If whitehats find a bug and don't feel they can get paid out, they may cross over to the dark side. This new Primacy of Impact is meant to get rid of this. We didn't mention that contract in scope yet you can steal millions worth of assets? Yep, we'll pay out for that! This rule is trying to prevent programs from not paying out for bugs but feeling the bug is bad enough to warrant a fix. If there are funds are risk, then a pay out should occur. In the DeFi space, where million dollar hacks happen regularly, it makes sense to have this rule. I think it's a good step forward for security.
Analysis Summary
# Best Practices: Primacy of Impact in Vulnerability Management
## Overview
Primacy of Impact is a security disclosure standard designed to prioritize the **severity and real-world consequences** of a vulnerability over the strict technical definitions of a "Scope" list. These practices address the "scope gap" that occurs when new assets (contracts, subdomains, or features) are deployed but not yet officially added to a bug bounty program. By adopting this impact-first approach, organizations ensure that whitehat hackers are incentivized to report critical risks—such as funds at risk—regardless of administrative omissions in the asset list.
## Key Recommendations
### Immediate Actions
1. **Update Program Philosophy:** Add a "Primacy of Impact" statement to the **Program Overview** section of your bug bounty page.
2. **Define "In-Scope Impact":** Explicitly list the types of consequences you will pay for (e.g., loss of user funds, unauthorized minting, sensitive data leakage) regardless of the asset involved.
3. **Commit to Fair Play:** Publicly state that if an asset is forgotten from the scope list but contains a vulnerability leading to a defined "In-Scope Impact," it will be treated as in-scope for reward purposes.
### Short-term Improvements (1-3 months)
1. **Map Assets to Impact Levels:** Categorize your infrastructure (Smart Contracts vs. Web/App) and decide if Primacy of Impact applies to all categories or just high-risk segments (e.g., DeFi protocols).
2. **Review Historical Submissions:** Audit previous "out-of-scope" reports that were closed without reward to identify if any would have qualified under the new standard, potentially offering goodwill retroactive rewards.
3. **Standardize Reward Tables:** Align your payout structure so rewards are based on the **Extent of Impact** rather than the specific asset's seniority.
### Long-term Strategy (3+ months)
1. **Automated Scope Synchronization:** Integrate your CI/CD pipeline with your bug bounty platform to automatically update "Assets in Scope" as new contracts/domains are deployed.
2. **Researcher Retention Program:** Use Primacy of Impact as a trust-building tool to attract high-tier "whitehat" researchers who specialize in novel, complex attack vectors.
3. **Policy Governance:** Establish an internal committee to adjudicate edge cases where the impact is real but the asset was intentionally excluded (e.g., a legacy system slated for decommissioning).
## Implementation Guidance
### For Small Organizations
- Focus on "Funds at Risk." If you are a small DeFi project, simplify your policy: any bug that can drain the protocol is in-scope, period. This reduces administrative overhead while maintaining maximum security coverage.
### For Medium Organizations
- Clearly differentiate between **theoretical risks** and **exploitable impacts.** Use Primacy of Impact to cover gaps caused by fast-paced development cycles where documentation lags behind deployment.
### For Large Enterprises
- Apply Primacy of Impact to specific high-value categories (e.g., core smart contracts) while maintaining a strict scope for lower-risk web assets to prevent "beg-bounty" reports on non-critical assets.
## Configuration Examples
**Standard Policy Clause:**
> "This program subscribes to the **Primacy of Impact** standard. If a researcher identifies a vulnerability with a real, exploitable impact listed in our 'In-Scope Impacts' table (e.g., Direct Theft of Funds), we will honor the report and provide a reward based on severity, even if the affected asset is not explicitly listed in the 'Assets in Scope' table."
## Compliance Alignment
- **ISO/IEC 29147:** Vulnerability disclosure (ensures ethical handling and reporting).
- **NIST SP 800-53:** Vulnerability Remediation (RA-5) and Security Assessment (CA-2).
- **CIS Controls:** Inventory and Control of Software Assets (Control 2).
## Common Pitfalls to Avoid
- **Rewarding Out-of-Scope Impacts:** Do not confuse *out-of-scope assets* with *out-of-scope impacts*. If a researcher finds a minor bug (e.g., UI glitch) on an unlisted asset, Primacy of Impact does **not** mandate a payout.
- **Ambiguity in Severity:** Failing to define what constitutes a "Critical" vs. "High" impact leads to disputes during the payout phase.
- **Ignoring the "Dark Side":** If you fix a bug reported in good faith but refuse to pay based on a technicality, you risk the researcher selling the exploit elsewhere or withholding future critical findings.
## Resources
- **Bug Bounty Platforms:** hxxps://immunefi[.]com
- **Vulnerability Standards:** CVSS (Common Vulnerability Scoring System)
- **Frameworks:** hxxps://github[.]com/disclose/vulnerability-disclosure-policy-templates