3 ms·
This isn’t worded correctly based on my experience. It should say ‘enterprises no longer trust their developers and SREs alone to take care of security,’. Dev
by jcims 6y ago
This isn’t worded correctly based on my experience. It should say ‘enterprises no longer trust their developers and SREs alone to take care of security,’.
Devs and SRE still have a very important role as SAST and DAST tools only catch a portion of security issues in code and are generally useless for gauging architectural/deployment/runtime issues.
- ithkuil 6y agoI agree; my response was to the wording present in TFA, which seemed to imply that enterprises expected engineers to handle security and were surprised they didn't and hence now are attempting to force a top-down approach the whole thing will be secure _despite_ engineers doing the same things as before. Tooling helps; no question about that. But you can't assume you're engineering team can be oblivious to security concerns. You need to train, hire and equip your teams appropriately. You need to set the right incentives. Just limiting the kinds of software stacks you're allowed to use seems shortsighted.
- jcims 6y agoTotally agree. One option is to make static scans a tollgate only at higher application risk levels and/or exposure. For example, low/medium risk internal automation and telemetry tooling? Go nuts. Internet facing, regulated, high/critical risk? Need code scans.
- Kalium 6y agoThat sort of division assumes you can be completely sure about how a system will be used in the future. I've definitely seen internal systems deployed in a public-facing capacity because someone found a useful reason to do it. How are you going to do that, if the internal tool is written in something that is not supported by SAST tooling?