Reporting OSS Vulnerabilities
Coming Soon to Testnet

Find and report vulnerabilities to secure the software supply chain

Security researchers can enhance the security of OSS software by submitting vulnerability reports to project maintainers. Users who report valid vulnerabilities may be rewarded with TEA.
Read the White Paper
Earn rewards
for valid
vulnerability reports
Security researchers are encouraged to participate in the tea Protocol by reporting software vulnerabilities associated with the tea Protocol or registered software projects.
Project maintains codebase

OSS contributors receive and evaluate vulnerability reports

Project contributors continually maintain open-source software code, including by evaluating incoming vulnerability reports.
Vulnerability is addressed

The happy path, project maintainers take action

OSS project maintainers address the vulnerability report by either accepting or rejecting it. Vulnerability researchers who submit accepted reports are rewarded with TEA.  Maintainers are expected to promptly address the vulnerabilities identified by valid reports, or explain why rejected reports are invalid.
Codebase
vulnerability
reported
Reporter stakes
TEA tokens
Vulnerability
is evaluated
Security researchers evaluate codebase

Users hunt for software vulnerabilities and submit reports

Anyone may report a software vulnerability. Staking TEA tokens to a vulnerability report is an anti-spam measure that’s required to submit the report.
Vulnerability is ignored

Left on the shelf, vulnerability report is not addressed

The unhappy path occurs when OSS project maintainers ignore the vulnerability report by not accepting or rejecting it. Not responding to a submitted vulnerability report in a timely manner causes the OSS project and its stakers to be penalized using a token-slashing mechanism. Not resolving a validated vulnerability also results in penalization via slashing for an OSS project and its stakers.
Project maintains codebase

OSS contributors receive and evaluate vulnerability reports

Project contributors continually maintain open-source software code, including by evaluating incoming vulnerability reports.
Security researchers evaluate codebase

Users hunt for software vulnerabilities and submit reports

Anyone may report a software vulnerability. Staking TEA tokens to a vulnerability report is an anti-spam measure that’s required to submit the report.
Codebase vulnerability reported
Reporter stakes TEA tokens
Vulnerability is evaluated
Vulnerability is addressed

The happy path, project maintainers take action

OSS project maintainers address the vulnerability report by either accepting or rejecting it. Vulnerability researchers who submit accepted reports are rewarded with TEA.  Maintainers are expected to promptly address the vulnerabilities identified by valid reports, or explain why rejected reports are invalid.
Vulnerability is ignored

Left on the shelf, vulnerability report is not addressed

The unhappy path occurs when OSS project maintainers ignore the vulnerability report by not accepting or rejecting it. Not responding to a submitted vulnerability report in a timely manner causes the OSS project and its stakers to be penalized using a token-slashing mechanism. Not resolving a validated vulnerability also results in penalization via slashing for an OSS project and its stakers.

Incentivized vulnerability
reporting

Staked tokens at risk

Reporting OSS vulnerabilities requires users to stake tokens to a bug report to prevent spam and protect project maintainers. Anyone who submits a valid report may receive rewards if the vulnerability is confirmed—regardless of whether the bug is ultimately resolved.

Learn More on GitBook
Remediation timeline

Every submitted vulnerability report is accompanied by a governance-defined timeline for the OSS project maintainer to address or resolve the software vulnerability. The first step is for the project maintainer to confirm the validity of the bug report.

Learn More on GitBook
Penalties for non-response

The tea Protocol incentivizes prompt and thorough responses to vulnerability reporting. Project maintainers who do not acknowledge or resolve reported issues in a timely manner may be penalized by a token-slashing event. Token slashing also impacts a project’s stakers.

Learn More on GitBook
Have questions or need assistance?
Connect with us—we're here to help
Get Support from tea
© tea Association. 2024.
Terms of Use
Privacy Policy
Sitemap
Learn about tea
Overview
Proof of Contribution
Rewards for OSS Contributions
Building OSS Reputation
Reporting OSS Vulnerabilities
Donating to OSS Projects
Governance
Roadmap
TEA Token
Overview
Token Value Capture
TEA Tokenomics
tea for Developers
Why join tea
How does it work
How can I join
Documentation
Resources
About
White paper
Documentation
FAQs
GitHub
Blog
White paper
Documentation
FAQs
Blog
GitHub
© tea Association. 2024.
Terms of Use
Privacy Policy
Sitemap
*This website is for information purposes only. The information shared on this website is not intended to form the basis of any investment decision and is not and should not be considered an offer, recommendation, or advice. This information shared on this website may contain forward looking statements, opinions and/or projections which involve significant elements of subjective judgement and analysis which may or may not be correct. Such forward looking statements, opinions and projections are not guarantees of future performance and involve known and unknown risks and uncertainties. The information shared on this website speaks only as of the date you visit the website and updates, revisions and/or changes to the website are at any time possible. Prior to your participation in the acquisition of TEA tokens, you shall carefully study this website and all the documents and contract associated with the same.  Do NOT enter into such contract unless you have actually read, understood, and agreed to be bound by such terms. The acquisition of TEA tokens involves inherent risks and speculative elements. Do NOT purchase TEA tokens unless you’re prepared to lose the entire purchase price. This is a high-risk purchase and you are unlikely to be protected if something goes wrong.