Hah this thread is good reading for security engineers. Agreed with a lot of the criticism but will first leaven that with devs get up to some wild shit that h

Hah this thread is good reading for security engineers. Agreed with a lot of the criticism but will first leaven that with devs get up to some wild shit that has to get controlled behind the scenes by the sec team. Can’t say more without doxing, but I’ve have done sec eng at a variety of pre/post IPO tech companies. Staggering irresponsibility with PII management, prod secrets, access prod on a personal laptop and indignantly arguing About it, malicious IDE/browsers extensions given prod creds by a freewheeling dev, and on and on and on. I have lost a non-zero amount of evenings due to this and top it off with an argumentative dev or PM, even if I really do a good job about crafty “this is a blame free situation we’re just trying to solve.” But, that aside, 10-20% of security hires are engineers who dig security, 20-30% can glue tools together and know the concepts but really stretch the definition of engineer, and the remainder are ivory tower no-machines who somehow refuse to learn how to code. SREs playing a large role in security are a natural result of this. The less technical the company, the more these %s skew badly. Also, the emotional intelligence distribution is all over the place across these categories. However, keep in mind that behind the stronger “no don’t do this anymore” dictates is not a zero chance it’s a sales RFP or large client audit. If you want to generate revenue and get paid, audits have to get passed, and many hardline rules source from this (as in, not just regulated industries do this).