Earlier quoted context omitted.
When programmers feel frustrating repetition they automate. The way to reach people is not with scolding but with scanners that are easy to use, helpful, and don't have lots of false positives.
> The way to reach people is not with scolding I think it's an unfair assumption to say that I'm scolding the teams I work with by trying to educate them on security issues - the fact that that is your takeaway from my last post says a lot about another issue with security organisations: that there often exists some adversarial nature between software engineering and product security. I moved into security from produ…
Besides myself, I've never came across another developer in an InfoSec team. Their background ranges from networking, desktop jockeying, manual sysadmin, audit, script running pentesters and mangerial, but never really developers, nor anyone who has been setting up automation for an operations function.
I think this is partly because I contract, and the sort of orgs that bring me on are already struggling, but I think it's also just a common theme that InfoSec teams don't build, and so people that do don't want to be there.
This is what leads to a lot of things we don't like. The demands to follow processes that don't really help, the buying of random products and demanding you integrate, etc. They simply lack of knowledge in Product Development leads to a lot of bad habits.
Much like you suggest, my job is too easy really. The builders also flee these orgs, because dealing with bullshit bureaucracy isn't fun, so with what's left all I can really do is suggest: use a framework that deals with security considerations, and don't deviate; follow this guidence such as CIS Benchmark; Use scanning tooks and look into the input; basically basic stuff, then come back to me when I have something to look at.