3 ms·

> In the wake of so many data leaks and hacking events enterprises no longer trust their developers and SREs to take care of security, and so protocols are bein

> In the wake of so many data leaks and hacking events enterprises no longer trust their developers and SREs to take care of security, and so protocols are being implemented top down. As if enterprises were not responsible for not properly budgeting security concerns in their engineering teams. I guess it's easier to just buy a tool that will force a process overhaul, rather than doing a much more thorough process overhaul in the first place. The problem is that tools like vulnerability scanners address only one part of the problem; admittedly, it is a low hanging fruit.

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 ago
  I 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 ago
    Totally 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 ago
      That 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?
thinkharderdev 6y ago
Those things are not mutually exclusive. And the original framing that enterprises "no longer trust their developers and SREs to take care of security" is a bit leading as well. Real, practical security is a mixture of dedicated security teams doing in depth analysis and pen testing, developers and SREs building secure solutions and automated tooling that does basic sanity checks.

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 ago
I 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 ago
  Totally 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 ago
    That 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?

thinkharderdev 6y ago

Those things are not mutually exclusive. And the original framing that enterprises "no longer trust their developers and SREs to take care of security" is a bit leading as well. Real, practical security is a mixture of dedicated security teams doing in depth analysis and pen testing, developers and SREs building secure solutions and automated tooling that does basic sanity checks.