3 ms·

I've got to say, I don't agree with this. The predicate of the argument appears to be that the team managing the VA/SAST platform will be able to block adoption

I've got to say, I don't agree with this. The predicate of the argument appears to be that the team managing the VA/SAST platform will be able to block adoption of new technologies if their tooling doesn't support them. I don't think I've ever seen a company where the security tooling team had that kind of authority or pull. I've seen plenty where the first time the security team hears about a new technology is after product development has started. You only have to look at the rise of containerization in enterprise to see this in action. When it started tooling was way behind, and it's only catching up now, but that didn't seem to stop anyone.

thinkharderdev 6y ago
I think they are arguing that this is changing now. When I first started software engineering ~15 years ago, it was pretty common for enterprises to exert quite a lot of control over what tech could be used. You had to use some solution from the "approved" list of languages/frameworks/versions (that was always hilariously out of date). Then that swung in the opposite direction (mostly concurrently with cloud adoption where dev teams were in charge of their own infrastructure) where individual teams had complete free reign to choose their own tech. The author is arguing that things are now swinging back in the other direction and it's largely driven by security considerations. So its not "you have to use something on the approved list of tech maintained by the Enterprise Architecture gods" but rather "you have to use something that is supported by our enterprise SAST solution." It will still likely be more lax than it was back in the old days because it is harder to enforce those restrictions in a world where the dev team manages their own cloud infrastructure, but still.
- raesene9 6y ago
  sure, and it's the argument that it's swinging back in the favour of centralised control that I don't buy. I look at major enterprises quickly adopting what are still quite new technologies, a good example being the uptake of things that come under the cloud native banner and that doesn't tell me that things are becoming more centralised/controlled. I've spoken to multiple security teams looking at container security who've said things along the lines of "this is getting deployed whether we want it or not, so we're doing our best to keep up" Ofc my examples will just be anecdotal, but that's what I'm seeing.
  - thinkharderdev 6y ago
    Yeah, I would mostly agree. I have noticed personally at my (largish) company a bit of a shift back towards centralized control, but only slightly. One thing that does seem very different now is that there is a lot more pressure on the vendors of SAST and other security products to support newer tech stacks. And if the big boys won't then there are always a huge number of smaller players ready to jump in to take advantage of that opening. The number of products just in the Serverless space offering "next-gen" WAF solutions is pretty amazing given how recent large scale adoption of Serverless stacks has been.
user5994461 6y ago
Had that in JP Morgan. New fancy things better work with all the tooling in place otherwise you can forget about using it (code review, unit tests, linter, deployment, packaging, vulnerability scanning, etc...). Honestly, this was great, this prevented developers and new graduates from rewriting every goddamn thing in the language du jour. I hope I never have to work in an organization with 100+ developers that doesn't enforce some standards. It's impossible to join a project and collaborate with other teams when every single developer/project decided to use its own language and make its own deployment system.
- sheeshkebab 6y ago
  The quality of consumer facing major banking websites shows how well this calcified development “culture” works in practice and long term.
  - jmnicolas 6y ago
    I'd rather my bank not loose my money than have a cool website though.
  - user5994461 6y ago
    If you're implying Chase the consumer bank, it's separate from JP Morgan.

thinkharderdev 6y ago

I think they are arguing that this is changing now. When I first started software engineering ~15 years ago, it was pretty common for enterprises to exert quite a lot of control over what tech could be used. You had to use some solution from the "approved" list of languages/frameworks/versions (that was always hilariously out of date). Then that swung in the opposite direction (mostly concurrently with cloud adoption where dev teams were in charge of their own infrastructure) where individual teams had complete free reign to choose their own tech. The author is arguing that things are now swinging back in the other direction and it's largely driven by security considerations. So its not "you have to use something on the approved list of tech maintained by the Enterprise Architecture gods" but rather "you have to use something that is supported by our enterprise SAST solution." It will still likely be more lax than it was back in the old days because it is harder to enforce those restrictions in a world where the dev team manages their own cloud infrastructure, but still.

raesene9 6y ago
sure, and it's the argument that it's swinging back in the favour of centralised control that I don't buy. I look at major enterprises quickly adopting what are still quite new technologies, a good example being the uptake of things that come under the cloud native banner and that doesn't tell me that things are becoming more centralised/controlled. I've spoken to multiple security teams looking at container security who've said things along the lines of "this is getting deployed whether we want it or not, so we're doing our best to keep up" Ofc my examples will just be anecdotal, but that's what I'm seeing.
- thinkharderdev 6y ago
  Yeah, I would mostly agree. I have noticed personally at my (largish) company a bit of a shift back towards centralized control, but only slightly. One thing that does seem very different now is that there is a lot more pressure on the vendors of SAST and other security products to support newer tech stacks. And if the big boys won't then there are always a huge number of smaller players ready to jump in to take advantage of that opening. The number of products just in the Serverless space offering "next-gen" WAF solutions is pretty amazing given how recent large scale adoption of Serverless stacks has been.

user5994461 6y ago

Had that in JP Morgan. New fancy things better work with all the tooling in place otherwise you can forget about using it (code review, unit tests, linter, deployment, packaging, vulnerability scanning, etc...). Honestly, this was great, this prevented developers and new graduates from rewriting every goddamn thing in the language du jour. I hope I never have to work in an organization with 100+ developers that doesn't enforce some standards. It's impossible to join a project and collaborate with other teams when every single developer/project decided to use its own language and make its own deployment system.

sheeshkebab 6y ago
The quality of consumer facing major banking websites shows how well this calcified development “culture” works in practice and long term.
- jmnicolas 6y ago
  I'd rather my bank not loose my money than have a cool website though.
- user5994461 6y ago
  If you're implying Chase the consumer bank, it's separate from JP Morgan.