-
Notifications
You must be signed in to change notification settings - Fork 38
find a groove for the security queue #460
Comments
P.S. The current members of @gratipay/security are @greggles @TheHmadQureshi @rohitpaulk and @pjz. @benhc123 recently excused himself from the team (thanks for your time with us, @benhc123! :-). |
Another thing to consider is that some Gratipay issues also affect Liberapay, so we could collaborate on those, which would likely result in better and quicker fixes. |
Thank you for comments! :) Yes i think a weekly video call would be helpful. What do you think ? |
@TheHmadQureshi The only problem with that is that the For our first weekly call, how about we try Wednesday at 2pm UTC? |
@Changaco Thanks for the offer. How would you see collaboration working? Would we share a HackerOne account? |
@whit537 For now you would simply give me access to Gratipay's HackerOne account, and when Liberapay launches we can either share a single account or if I decide to create a separate account for Liberapay then I'll give the Gratipay team access to it. |
2pm UTC will be 9 am according to my time. i may not be available at that time but if we can adjust it to 3pm UTC ( 10am acc to my time ) i maybe available. |
Are you sure? 2 pm UTC is also 9 am in my time. What time zone are you in? |
Thanks again for the offer, @Changaco, but I think it will be best to run separate programs for Liberapay and Gratipay, since our codebases are certain to drift apart the further we get from the fork. Now that Aspen is spun out as a third entity, I think that's a place we can continue to collaborate on security: AspenWeb/salon#3. |
With the introduction of bounties to our program (#369), we're now seeing a fair clip of activity. In my view @TheHmadQureshi and I are finding a groove with triage and queue management using HackerOne and GitHub (e.g., #506), with @rohitpaulk stepping in to help with code review. With that, I'm going to go ahead and close this ticket. !m @TheHmadQureshi 👯 |
We're getting a fair amount of throughput on HackerOne (#255). Yay! @TheHmadQureshi is doing a great job of triaging issues and responding to researcher requests for status reports, and we're evolving (#456) a pretty good process for securely deploying fixes.
Our bottleneck is in actually producing fixes: as usual, we're constrained on developer time. We need to find a way to manage our security queue with this reality in mind.
Obviously if anything critical is reported, we need to drop everything and respond immediately. Most reports, however, are for low-risk issues. We need to get into a groove where we make regular progress on these low-level issues. It's unlikely that we'll ever see Security 0 again. Instead, I think we should focus on regularly cycling the queue so that no issue is stuck there for too long. We should pay special attention to the age of this queue.
This means we should be regularly scanning the queue, topping up issues, and prioritizing based on risk and age. @pjz and I have found over on Aspen that regular calls are a good way to ensure that we're looking at all issues in a queue on a regular basis, and I propose that we do something similar for our security queue. Since security moves at a faster clip than web framework development, I think a weekly call would be more appropriate than a monthly call.
@TheHmadQureshi @gratipay/security What do you think? Would scheduling a weekly video call help us stay on top of our security queue?
The text was updated successfully, but these errors were encountered: