One of the things I think about when analyzing organizational behavior is where something falls on the supportive vs controlling spectrum. It's really impressive how much they're on the supportive end here.<p>When organizations scale up, and especially when they're dealing with risks, it's easy for them to shift toward the controlling end of things. This is especially true when internally people can score points by assigning or shifting blame.<p>Controlling and blaming are terrible for creative work, though. And they're also terrible for increasing safety beyond a certain pretty low level. (For those interested, I strongly recommend Sidney Dekker's "Field Guide to Understanding Human Error" [1], a great book on how to investigate airplane accidents, and how blame-focused approaches deeply harm real safety efforts.) So it's great to see Slack finding a way to scale up without losing something that has allowed them to make such a lovely product.<p>[1] <a href="https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648257" rel="nofollow">https://www.amazon.com/Field-Guide-Understanding-Human-Error...</a>
I love this! If you're a part of a security team and you are not automating your processes and procedures then your team is going to drown. You must automate.<p>It seems like some simple checklist app but having a non Jira process that takes only a few minutes is so valuable, and "security reviews" and "threat models" as part of your SDLC take insane amounts of time and honestly aren't super helpful.
I like the addition question if you are using C/C++:
«We confirm that we really, really need to use a non-memory-safe language.". PHP/Python/C/C++ get Medium Risk directly, Low Risk: WebApp/API/MessageServer/iOS/Android/Electron/WindowsPhone
So glad they finally published this, saw the OWASP AppSec talk, was eagerly awaiting it.<p>However - I would want to caution: I think this model works because Slack has a self-described "culture of developer trust". I tend to think, they hire bright engineers and ensure they are equipped to do the right thing. I believe the vast majority of organizations are NOT ready for this. I direly want them to be, but simple fact is there are too many mediocre developers, and they can't be trusted without guardrails (and some straight up need babysitters).
And I thought 'security' itself is friction ;-)<p>No seriously, I was wondering if that tool has a CLI interface? Might make it more accessable for some devs.
The company I work for has been offering an enterprise level service like for about 8 years now: <a href="https://www.securitycompass.com/sdelements/" rel="nofollow">https://www.securitycompass.com/sdelements/</a>
> The process of deploying code to production is very simple, and takes about ten minutes total. This results in a life cycle in which we deploy code to production approximately 100 times per day.<p>What? They spend 1000 minutes out of every 1440 deploying to production? The deployment process is occurring over 16 hours out of every 24? Am I the only one who is nonplussed by this?<p>EDIT: Ok I get it, I get it. I guess I always worked in much smaller companies where CD meant deploying about 10 times a day tops. TIL big companies are big.