Status Security Revamp
When I started working at Status, I remember asking around “What do you think I should be doing?” and gathering the general responses. Many of them were “I don’t know, that’s why we hired you.” Lucky for me, the overwhelming natural tendency to security within the organization was, and has continued to be, reasonble. That means that what was built and the processes followed were reasonable, thus not presenting me with this mountain to overcome and build as we bolstered the concept of “Security” at Status over time.
One unfortunate consequence of how I’ve done things so far is that when something “Security” related comes up within a conversation across the organization, the tendency is to say “I don’t know, ask Corey about it.” This works in a small context in terms of efficiency and amount of work, but as things scale and grow it fails. It also sets me up as a gatekeeper of “Securitiy” within the entirety of the organization. As the Security team has grown over the years, this is slightly mitigated in terms of time effort, but I would argue that moving from “I don’t know, ask Corey” to “I don’t know, ask the Security team” as a default to dealing with security issues is not scalable. Moreover, it is the antithesis of a decentralized organization and will fail as we scale out.
To that end, the Security team is spending the rest of the year “Revamping itself” to operate more effectively, particularly within the context of a DAO-based organization. It is clear that this is the direction we are going, so we are going to act as if we are there. More on this later.
We have identified the broad steps to make this happen, and hope to have a fully fleshed out plan for what this is (with organization buy-in) by the end of the year, so we can start fresh in this mode of operation next year. It is as follows:
- Identify the current work-load and responsibilities of the Security team, and who the assocaited owners are
1.a: Identify the skills and desires of the current Security team - Re-map how that distribution is current set, as well as whether or not it is reasonably a “Security” matter.
- Identify “holes” in the current situation. This is an assessment of what we (and YOU) think Security should be doing, and how to mitigate this lack in coverage.
- Explicitely document this workload and responsibility chain so that others can refer to it when needed. Think, a place that answers “who is the person to contact about this issue, and how should I do it?” I.e., create the Status Security handbook
This post is both a broad announcement of what the Security team is working on, as well as a PLEE for you to give feedback on what you think we should be doing, and whether or not you think we are doing it adequately. Also note that this is mostly for Core Contributors, but community feedback is welcome if constructive and relevant.
As time goes on, we will make assets and documentation that details this transition. Here are the current places to check for things:
- Status Security - Internal: A place for internal-facing security related information, not to be publicly shared.
- Note the current responsibilities map in the
overviewdirectory.
- Note the current responsibilities map in the
- Status Security - External: A place for external-facing security related information, to be broadcasted at will.
It is most definitely within our goals to build a Security team and associated process that can be mimicked across the Web3 ecosystem, such that other decentralized organizations can build security-focused groups that bolster their projects. In that light, it is our hope that anything that is in the internal repos will eventually make it to the external ones, but obviously some things should remain internal for various purposes.
thanks!