Experiment: Nivenly Fedi Security Fund

Nivenly Public Discussions
1

Howdy, folks - this is an idea that was inspired by a recent discussion and CVE in a Fediverse project. The core of it came down to: could contributors get paid for closing vulnerabilities to make the fediverse safer?

We think Nivenly can help! The idea is that Nivenly will pay a modest “sponsorship” for people who close high and critical CVEs. Since this is the first time we’ve tried something like this, we want to start small and are calling this an “experiment”. Our hypothesis is: by sponsoring the work to close important vulnerabilities, we will give contributors more opportunity to make open source contributions, therefore making the overall fedi ecosystem safer.

The full text of the proposal is below. We’d love your questions, feedback, and ideas. Since this is an experiment, the idea is to try something out, get some data, reach a conclusion, and do it again!

Happy Hachyderming,

Esk

Changelog

  • 2024-02-14 - @esk
    • Adjusted to include finding vulnerabilities in addition to fixing them.
    • Clarified we are looking at the base CVSS score of the vuln.
    • Simplified payouts to $200 for finding/fixing a high/crit.
    • Increased the fund limit to account for round numbers & more activity since we’re now including finding vulns.

Nivenly Fedi Security Fund

Background

Software inevitably has security vulnerabilities, and software for the Fedi is no exception. Closing these vulnerabilities provides a safer, more trustworthy experience for citizens of the Fediverse. To that end, Nivenly is launching an experimental fund to sponsor contributors who find or close serious security flaws in popular open source Fediverse products.

The Fund

Individual contributors who identify or fix a high or critical CVSS base score vulnerability in Fediverse software will receive a one-time sponsorship of $200 from the Nivenly Foundation.

Since this is a new program and we want to gather data about how contributors will engage with it, Nivenly will set aside $3,000 USD through the end of June 30, 2024. Before or at the conclusion of the experiment, Nivenly will hold a member vote to determine if we want to continue the program.

Terms

Since this is a time and funds limited experiment, and it’s the first time Nivenly has tried something like this, there are a few terms to keep things a bit simpler:

  • Sponsorships will only be awarded to individuals, not teams or corporations.
  • Contributor is responsible for providing Nivenly with
    • (preferred) a Github Security Advisory that is:
      • Linked to an eligible software project.
      • Linked to the contributor’s Github account with credit for the find or fix.
      • Sponsorship credit requested from the @nivenly-foundation Github account.
    • or, if the project does not use Github:
      • Link to a vulnerability in an authoritative database like NIST’s NVD
      • Link to a PR that contains the fix and references the above CVE
      • Demonstrate ownership of accounts in both the project’s source control system and Github (e.g. create a gist/snippet and share it with Nivenly)
  • Contributor is responsible for notifying Nivenly when the CVE is identified or fix is merged; payment will be issued no later than 14 days after.
  • Sponsorship will be submitted via a one-time Github Sponsors payment. Nivenly will be responsible for any fees associated with the sponsorship.
  • Contributor may receive sponsorships from other organizations for the same CVE.
  • During the experiment, a single contributor is limited to a maximum payout of $1000 USD.

Eligible Fediverse Software

Don’t see the project you were expecting? Raise a ticket at nivenly/community and let’s have a discussion about adding it.

2

Perhaps one question to ask here is “are we measuring base scores or overall scores?”, because GitHub’s Security Advisories only seem to measure base score?

e.g., for the recent pixelfed vulnerability GitHub calculated that as a 9.9/10 for me, but today I learned of NIST’s v3 calculator, and putting in the other factors based on what I know, the overall score dropped to 8.4 — I’m also learning scoring seems to be highly subjective, and different people will have differing opinions on facets of a score.

I think it’d be worth us clarifying exactly which score should be used here, lest there be any confusion.

2 Likes
3

perhaps then for the purposes of the experiment we simplify and pay a flat $200 regardless of the score?

1 Like
4

I think a huge flaw here is how to get access to current CVEs, as these are non-public until a fix has already been implemented. So the only eligible people under this fund would be those who either is already a core contributor to the project, or a magic “10x vulnerability researcher” who can both find and implement a satisfactory fix the respective code-base with such a critical vulnerability, and also get it merged.

The incentives here heavily favors people who are already established as the vulnerability fixers for their respective projects, and i fear the ultimate outcome here may be secrecy or even postponing disclosing security vulnerabilities to upstream from outsiders to guarantee yourself to be the one who also fixes the flaw, such that you are eligible for payment under this fund.

Maybe a better idea would be to split up the payout of discovery and code-fixes? As this draft would not give any value to those finding and disclosing vulnerabilities responsibly…

1 Like
5

All excellent feedback, folks.

@dma’s suggestion to simplify the payout scheme makes sense to me, particularly because this is a new thing and it will make the back-end accounting a little easier.

@thisismissem’s comment on which score we’re using is very important - for simplicity’s sake, I would suggest we go with the base score, and I can clarify in the draft text.

Finally, @sofi’s suggestion to also include identifying vulnerabilities also makes sense, as we want to encourage responsible behaviors throughout the vuln lifecycle. I’ll update to include this as well.

6

Text updated & I’ve included a changelog to call out the specific changes.

7

As mentioned privately, I think we need to be explicit that the vulnerability report & later disclosure must follow the Nivenly Covenant, i.e., we’re doing this to help the Fediverse, not to fund those who wish to be rude or disrespectful to maintainers, past contributors, or others working on the projects covered or using the projects.

2 Likes
8

Howdy, folks - I am going to have quite a bit more time on my hands next week – PTO, hooray! – and I’ll finalize the announcement post then. Thanks, everyone for the feedback!

9

So it turns out we never launched it; I’ll blame it on my favorite stock Jira status – “overcome by events”.

We (the Nivenly board) recently resolved to formally launch this program in December. I’ll finalize the doc shortly and convert into a blog post.

1 Like
10

@esk did we end up deciding to adopt the suggestion about following the nivenly code of conduct? i.e., we only pay out for setting a good example, and shaming people is not it.