Hi Sarah
– Just me, you can skip this part.
I’m Benjamin Winston, I work for the ECC as their Director of Security. I’ve been lucky enough to work on the test team for several great consultancies, and I’ve worked directly for a few vendors in the past, most recently at Fitbit looking at their full stack and firmware. The transition from external assessment to internal vendors really taught me a lot about being a security practitioner, including making my fair share of mistakes along the way.
I had been hired while CVE-2019-7167 was being worked on, but I wasn’t briefed on it until just prior to Sapling launch, at which point I handled the disclosure process. Many sleepless nights and stress on that one lol 
I handle the engagement of ECC with external security assessors, and I run our internal security function doing stuff like this Fuzzing Zcash with Kubernetes - Electric Coin Company
– end of me, please stop skipping here
I’m glad that we’ve got representation of security interests on the ZOMG and I agree that forcing spend into silos will reduce the effectiveness of the effort to check the security of the Zcash ecosystem by doing external assessments.
It also makes sense to me that there be a resource for security input into designs ahead of the “oops we didn’t mean to do that” and reengineering that inevitably follows someone engineering without first doing some security planning.
Certainly I don’t want to see basic TLS security or any other table-stakes control omitted from any product, which is why we started an outreach program with Aditya, unstoppable, nighthawk around their security. Our (I keep saying our - I mean mine and Taylor’s) intentions around that was to provide maximum reward for the ecosystem with a minimum invetment of effort on our part.
After you dropped that bug in Aditya’s code on Twitter with no warning or forward disclosure, we reached out to him and tried to provide a service. We created a key result around our performance in this area in response to that event to the effect of “no simple-to-discover issue gets by this program”. We defined “simple to discover” that a competent attacker would find it in the first few moments of analyzing the software.
I must confess I do wonder about your commitment to Ethics Reviews around projects harming the communities they’re intended to support. I wonder whether you consider dropping that bug to not be harming the community, or whether you think it only doesn’t detract from your ability to make that determination in other people’s efforts.
Thus far this program, as ah-hoc as it has been has seemed to provide at least some assurance to projects that might otherwise have experienced none. We had problems regulating our time on it though - it’s hard to dedicate exactly half a day per week to something while we’re operating in what is basically a high throughput interrupt-driven environment like ECC’s security.
One thing we’ve been able to organize while the Zcash project was just ECC (well, ZcashCo at the time) and the foundation is to adapt the norms of responsible disclosure to the wilds of the cyptocurrency space. I was lucky enough to be invited to a working group that ultimately produced this standard: GitHub - RD-Crypto-Spec/Responsible-Disclosure: A standard point from which crypto projects may derive their responsible disclosure policy. and we committed to it here: https://github.com/zcash/zcash/blob/master/responsible_disclosure.md
Briefly, the standard is intended to provide a commitment scheme to the destinations and conditions under which we will disclose security issues, so as to be able to provide continuous user safety in a distributed consensus-critical environment. The intent is to separate, basically, the transport negotiations from the communication itself so as to speed up our response times and reduce overhead when dealing with critical bugs. This complements ECC’s internal processes on handling security issues.
We just completed negotiations (yesterday) with Deirdre and Teor at the foundation to add them to our public commitment (expect a PR for that in zcash/zcash later today, I’m delighted to have them on board for this) and with Nighthawk and Unstoppable who have adopted our wallet code (expect a PR for that later today or early next week in those repos).
My hope is that if you come into contact with any bugs, critical or otherwise, in any of the code I’ve been employed to coordinate the security of that you’ll work with us on our polite request to please report them via our security disclosure comms point, which is documented on our website here: Security Information - Zcash and we will deal with them seriously.
I stand ready to provide whatever other input might be helpful to ZOMG in the effort to secure the ecosystem, although of course ultimately we don’t have too much spare capacity in terms of individual contributions, I’m here to help you in any other way I can.
Thanks
bambam