What actually counts as "security work" in the design…
0 reactions
What actually counts as "security work" in the design phase of SDLC?
Been thinking about this for a while and wanted to hear how other devs actually handle it, not the textbook version.
The textbook answer is threat modeling. STRIDE, data flow diagrams, trust boundaries, all of it. And on paper it makes total sense, because the design phase is the cheapest place in the whole SDLC to catch a security problem. Fixing a bad auth assumption on a whiteboard is a 30 minute conversation. Fixing it after you are 40k lines deep is a whole quarter and a very bad standup.
But heres the thing. Almost nobody i talk to actually does it properly. What i keep seeing instead is stuff like:
* Security gets pushed to "well just pen test before launch", which is basically hoping the expensive phase catches what the cheap phase skipped
* Someone copy pastes an OWASP checklist into a Notion doc, nobody reads past the first 10 lines, and it gets called "our security process"
* The one dev who actually cares runs a threat modeling session alone, nobody else engages, and the doc dies in a folder nobody opens again
* The other extreme, a 3 day workshop with 11 people that produces a 60 page pdf and changes nothing about how the thing actually gets built
So my real question for this sub. When you say your team "does security in the design phase", what does that actually look like on a normal week? Is it a real activity with outputs that change the architecture, or is it more of a vibe where the senior devs just sort of know what to watch for and mention stuff during design reviews?
And for the teams that do threat modeling for real, how do you keep it from becoming the thing everyone dreads showing up to? The few places i have seen do it well kept it short, like 45 minutes, one user flow at a time, with the people who actually write the code in the room instead of a separate security team flying in and handing down a report.
Not trying to start a framework war. Just want to know what actually works in practice vs what gets written on a compliance doc and forgotten?
#programming #technology #dev
source
Been thinking about this for a while and wanted to hear how other devs actually handle it, not the textbook version.
The textbook answer is threat modeling. STRIDE, data flow diagrams, trust boundaries, all of it. And on paper it makes total sense, because the design phase is the cheapest place in the whole SDLC to catch a security problem. Fixing a bad auth assumption on a whiteboard is a 30 minute conversation. Fixing it after you are 40k lines deep is a whole quarter and a very bad standup.
But heres the thing. Almost nobody i talk to actually does it properly. What i keep seeing instead is stuff like:
* Security gets pushed to "well just pen test before launch", which is basically hoping the expensive phase catches what the cheap phase skipped
* Someone copy pastes an OWASP checklist into a Notion doc, nobody reads past the first 10 lines, and it gets called "our security process"
* The one dev who actually cares runs a threat modeling session alone, nobody else engages, and the doc dies in a folder nobody opens again
* The other extreme, a 3 day workshop with 11 people that produces a 60 page pdf and changes nothing about how the thing actually gets built
So my real question for this sub. When you say your team "does security in the design phase", what does that actually look like on a normal week? Is it a real activity with outputs that change the architecture, or is it more of a vibe where the senior devs just sort of know what to watch for and mention stuff during design reviews?
And for the teams that do threat modeling for real, how do you keep it from becoming the thing everyone dreads showing up to? The few places i have seen do it well kept it short, like 45 minutes, one user flow at a time, with the people who actually write the code in the room instead of a separate security team flying in and handing down a report.
Not trying to start a framework war. Just want to know what actually works in practice vs what gets written on a compliance doc and forgotten?
#programming #technology #dev
source
| 2,000 mlx | |
| 3 | |
| 0 |