Security Workstream Budget (revised)

I propose that:

  • VulTech, LLC (i.e. @MrNerdHair) be compensated for leading the Security Workstream at the rate of $16,250/month for the 6-month period starting on January 1, 2022.

  • The Security Workstream be allocated $50,000 from the DAO Treasury. This is a lump-sum allocation to be used to cover contributor compensation, fixed costs, and test funds, and will be refilled as needed through future proposals.

Leadership

I propose that the DAO pay the Security Workstream Leader on a salary basis, commensurate with the compensation of the leaders of other workstreams. The downside to this approach is that it may potentially create an appearance that the security workstream leader is paid out-of-proportion to other workstream contributors; personally, I expect to spend a significant amount of my time contributing to other workstreams (primarily Engineering – after all, code quality and investment in sound architecture are first-order security concerns!) but that time will effectively be paid for from the security budget.

Given this structure the Security Workstream Leader will not be eligible to receive compensation via the Coordinape process outlined below, in the interest of preventing even the appearance of a conflict of interest. They will remain eligible for funds made available to Security Workstream members via other proposals (the on-call stipend suggested in SCP-46 is an example of this).

I’ve asked for advice from a few members of the community about the best way to structure workstream leader compensation in this case, and the consensus seems to be that the wisest choice is to stick with the salary model for this role for the sake of simplicity. This seems appropriate to me in the context of a appropriate general bias towards continuity and what we know works, and well as the avoidance of any potential unintended perverse incentives that might be created by a more complicated setup.

Fixed Costs

While the workstream currently does not have any fixed-cost expenses, this may change in the future as it expands. For example, this could include payment for tools (such as software licenses), services (such as a VPN connection), or even work (such as hiring a consultant or paying an engineer for a one-off project).

Fixed-cost payments such as these will be managed on the basis of consensus, as measured via the Colony reputation system. Any contributor may make a payment motion via Colony for such an expense once consensus has been reached. The Workstream Leader will be responsible to moderate the consensus-forming process and veto any abusive motions.

Contributor Compensation

Security needs a compensation system that’s flexible enough to adapt to a variety of circumstances: from “slow days” through to crisis response. I don’t envision a huge flow of security-specific work, which makes the traditional salary-style model of compensation less of a good fit, and I also expect that some Security Workstream contributors (hopefully, most of them!) will also be contributors to other workstreams.

As such, I propose that the DAO utilize Coordinape to determine Security Workstream contributors’ compensation, with the Workstream Leader acting as a referee (and ineligible to receive funds from the process). This will provide excellent flexibility by valuing contributions using a well-socialized price-discovery mechanism and a broad set of perspectives.

  1. Coordinape epochs will occur the last week of each month, with the interval subject to adjustment based on real-world experience with the process.
  2. Each epoch, the Workstream Leader will choose an amount to be distributed. (As we gain experience with Coordinape, my goal is to figure out some kind of consistent formula for this and eliminate my discretion from the process.)
  3. Coordinape will be used to divvy up the funds allocated for each epoch according to each contributor’s input over the previous month.
  4. Contributors to any workstream may participate in the Coordinape process, but only those who have made contributions to Security will be eligible to receive GIVE tokens.
  5. The output of the Coordinape process will be a Colony motion to pay out the appropriate funds; the Workstream Leader will be responsible to veto any such motions that don’t match the Coordinape output or involve abuse of the system.

Task Tracking

The Workstream Leader will manage a task-tracking system which will provide the community with transparency into how funds are spent. Tracking tasks will help new contributors to see how they can get started, as well as helping participants in the Coordinape process stay informed about who’s doing things that matter.

Security tasks relevant to a particular repository will be tracked in concert with Engineering; at the moment that means GitHub issues on the associated repo, probably with an extra ‘security’ tag or linked to a Security project board. A different system will be needed to track more general Security tasks, such as review of prospective partners’ code, or ones which need to remain confidential for a period of time; the precise system is TBD at the moment, but there are a number of options. The goal is a Kanban-ish “cards moving right” paradigm with “eventual transparency”, in the sense that any tasks that do require confidentiality (i.e. remediation of reported security issues) will still be tracked in a manner that will eventually (i.e. after the issue is fixed) end up publicly visible.

Trust

Security tasks will generally require a degree of trust in the contributor. (A contributor performing a security review will have to be trusted to disclose the issues they find rather than hiding them and exploiting them later; a contributor asked to help remediate a serious security issue will have to be trusted to maintain confidentiality.) For this reason, some tasks may require the approval of the Workstream Leader before beginning work, and some confidential tasks may only be visible to certain approved contributors.

Conclusion

I hope to get this dialed in to a much more deterministic system in the future, but we’re still evolving as an organization and security usually deals with unknown unknowns. There’s also still some level of split-responsibility to be sorted out between workstreams, like which tasks belong as Security initiatives and which belong to Engineering more generally, as well as what’s appropriate to handle via longer-term plans like the roadmap and what should be fast-tracked through the Security process.

4 Likes

Thanks for putting this together. As I stated in the governance call, I fully support you getting a consistent monthly salary. You provide a lot of value to our engineering effort that is even outside of precisely security matters. I have no doubt the DAO will get value from your more than full-time involvment.

Your request for $50,000 per month discretionary funds to bounty work to improve our security is too high for me. When talking, you mentioned $5,000 per month. That sounds reasonable to me. Then, if you do need more at some point, another proposal is a viable option to secure extra funds. Per @jonisjon’s point on the call, you could just request $30,000 discretionary funds for the 6-month period. Then, you can request and get as much of that as you need, when you need it. Rather than getting a $5k allocation per month.

Look forward to seeing your mods to this proposal. Thanks Reid!

2 Likes

This is excellent feedback and I appreciate it very much!

I do think that now is a particularly opportune time to invest in a solid security foundation, but one of my goals by suggesting $50k/mo was to somewhat highball the number. I definitely didn’t want to suggest something and have it pass with relatively little discussion, because I know I need the community’s help to get this right.

I don’t think it makes sense to have more full-time salaried contributors at this stage, but I do think it’s important to get a plurality of other part-time contributors involved, and hourly billing sucks. It’s my hope that Coordinape can solve that problem by distributing what would ordinarily be thought of as “payroll expenses” in a more fair and flexible manner. I do believe that we could run the workstream on a $5k/month budget, but in terms of salary-equivalents that would be less than half of an additional full-time contributor.

The best framing of the question I’ve been able to come up with is, essentially, how much security-focused activity we want to support in terms of number of people? $50k/month would fund ~4 additional full-time-contributor-equivalents, though I’m hoping for a larger group of less-active people. Choosing that appropriate activity level is the question I need everyone’s help to answer; I have a laundry list of the forms that activity might take (i.e. the specific technical stuff I referred to on the call), but I don’t think that really cuts to the heart of the question so I tried to keep it out of this proposal.

Since we’re still figuring out the combination of processes that would fit best I’ve been considering all expenses (“payroll”, task-specific bounties, test funds, etc) as a single line-item for simplicity’s sake, but it’s probably misleading to have framed that as a discretionary budget. Frankly, I want as little discretion in the process as is reasonably possible, which is one reason I’m so keen on having a diverse group of workstream contributors who outnumber, and can hopefully outvote, me!

1 Like

I see your point. Calling it discretionary is not accurate. “Bounty Funds to pay for security related engineering efforts” maybe? I wouldn’t consider it a salary unless you plan on hiring a security engineer for a full-time or part-time contributor role.

1 Like