I propose that:
- be “re-elected” as Security Workstream Leader for a period of 6 months, and be compensated at the rate of $$$/year
- The Security Workstream be allocated $$$ FOX each month for the next 6 months, to be handled as described below.
Still need to pick numbers here, but wanted to get the general idea out for feedback.
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 for completing discretionary security tasks via the 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.
Tasks
Compensation
Security tasks sometimes overlap with engineering ones, but sometimes don’t. I don’t envision a huge flow of security-specific work, which makes a traditional salary-style method of compensation less of a good fit. What we need is a system that’s flexible enough to adapt to a variety of circumstances: from “slow days” through to crisis response.
I expect that some Security Workstream contributors (hopefully, most of them!) will also be contributors to other workstreams. As such, I propose that the DAO pay for time instead of for people, by establishing a standard hourly rate for security work. Workstream contributors will submit payment requests on Colony for time spent on approved security tasks; the Workstream Leader will be responsible to veto any such payment requests that involve misrepresentation or abuse.
Still need to choose the hourly rate.
This obviously will involve a level of trust that contributors aren’t goosing their numbers, but it’s much more flexible than assigning pre-set values to individual tasks. I also feel that accidentally creating an incentive to rush security tasks is a much more dangerous failure mode than incidentally creating an incentive to move slowly. (In addition, trustworthiness is essential for security work, and if someone decides to lie about the time they’ve spent it’s a relatively cheap and reasonably detectable way to discover that they’re not right for the job.)
Tracking
Each payment request made to the Security Workstream will be tied to a tracked task, which will provide the community with transparency into how funds are spent. Security tasks that are 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. 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 confidential tasks may only be visible to certain approved contributors.
Origination
I hope to get this dialed in to a much more deterministic system in the future, but for now I ask that you trust me as workstream leader to choose and assign tasks on-the-fly in a responsible manner. We’re still evolving as an organization, and security usually deals with unknown unknowns. There’s 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.
I’d have preferred to bring a list of specifics here, but I do have confidence we’ll be able to sort it all out as we go. We’re approaching the point where we need to get started recruiting more active workstream contributors and prepare to jettison our centralized training wheels, and my feeling is that flexibility at this stage is essential.
Test Funds
The Security Workstream may distribute funds for testing purposes or for payment or reimbursement of necessary gas costs. These are expected to be minimal amounts, and the proposed discretionary budgetary allocation is expected to be sufficient.