Vyper Security Alliance

Vyper currently doesn't have a bug bounty program (see policy). Partly this is due to the the expansive scope one would have (how do we determine impact of a potential codegen issue?), and partly it's practical in that there is currently no budget available for it (although that could change in the future). Regardless, Vyper does today have several production users, including Yearn, Curve, and Lido.

This proposal would be in 3 parts, each would be opt-in that would help the Vyper language find greater adoption by security researchers, which will in turn make both the language and the users of the language (who adopt this agreement) stronger.

Step 1: Add Vyper to your Bug Bounty Program

Easy first step is to mention the versions of the Vyper compiler (that you support in production deployments) to your bug bounty program, under the Scope heading of your program.

This would look something like the following:

### Vyper Compiler

Code generation defects for any version(s) of the Vyper compiler that we use
to generate code for any contracts covered under this Bug Bounty Program are
considered in scope of this program. If you discover such a defect and report
it to us, per the rules of the program, you will be eligible for at least an
Informational-level reward, if the defect is considered valid.

You can read more about Vyper's own security policy [here](https://github.com/vyperlang/vyper/security/policy).

By including this snippet in your own bounty program, you are including the Vyper compiler in scope of the program.

In practice, this only means code generation (e.g. the part of the compiler that actually creates production code for your production deployments) is considered in scope. Any bugs to the frontend or type system will not be considered in scope, as those are just usage bugs for the compiler (which are not capable of creating impact to your own code). Additionally, the impact assessment only relates to your own production deployment, not of the compiler itself, so the increase in scope is still fairly limited, and will only benefit you in finding potentially catastrophic bugs for your own projects.

We can link to these policies under Vyper's own policy to create a more fluid understanding amongst researchers that identifying Vyper codegen bugs can at least make you eligible for a reward of any of the listed bug bounty programs.

Step 2: Create the Vyper Security Alliance

Step 1 is all well and good, however this might have a limited impact because most bug bounty programs exclude findings already reported to other projects, so you can really only apply to the top program to receive the rewards of that project, leaving other projects to glean their own impact through ad-hoc sharing of the potential exploit through other means.

What we want is a cooperative means of sharing potential exploits with all users of the Vyper compiler, such that one identified codegen defect will be valid for all the participating project's programs.

The creation of the "Vyper Security Alliance" (VSA for short) would assist in making this clear to researchers that they can potentially multiple their rewards by researching on the Vyper compiler itself, since identifying any code generation defect could lead to up to N possible rewards (where N is the participating projects), depending on impact to each individual project (limiting to only impact per each respective program is valuable to limiting the scope of these findings for each participant).

The creation of such an agreement would be beneficial to all participants due the increased scrutiny of one of the most important parts of their production deployment pipeline, and increases security for additional users of the compiler as a side effect.

Agreeing to the VSA would be a matter of two additional steps:

1. Adding the VSA under "Bilateral Disclosure Agreements" section of your bug bounty program (e.g. Yearn)
2. Adding your name under Vyper's security policy as a participant in this agreement (TBD)

If either one of these is not in place, you will no longer agree to participate in this program, which means you'll have more discretion over which reported Vyper codegen defects are covered under the rules of your program.

However, it's still rather limited in scope, since to qualify for anything above Informational-level impact, the codegen defect would have to have impact to your own project per the rules of your Bug Bounty Program.

The only difference between Step 1 and Step 2 is the additional coverage among multiple participating projects for any discovered codegen defects, and the additional marketing from participating in this program by having your name listed on our own policy.

Step 3: Funding Vyper Security (and other ideas?)

To improve the ability for security researchers to identify bugs in both the compiler as well as just increase the security of Vyper overall, participants in the VSA (or really anyone) could do some of the following:

1. Create bounties for the creation of Vyper security tooling
2. Co-fund regular audits of the critical sections of Vyper's codebase (e.g. code generator and optimizations)
3. Co-fund educational workshops for Vyper
4. many other ideas…

Really, I just wanted to include this section to talk about more of the ways participants in the VSA can work together for the benefit of all projects, and for the security of the Vyper language itself. All of this is up for disscussion!