>A root cause seems to be that everyone with the aptitude for security crowds toward jobs that don't actually involve implementing good security.
To expand on this, I've also noticed that "security" in enterprise-size companies tends to be a dumping ground for helpdesk+ staff -- people that can read a CVE or parrot "best practice", but not really grok the subject or think critically about it (e.g. jumping from one password to another every 3 months isn't "more secure"). It's been my experience that people in security teams can't implement the fixes to the things they complain about because if you're a security-minded dev, your career path will be in dev.
>It's not as fun to be a developer that is really into security but only have that be part of your job.
I think it would be ideal to have security as a parallel track to regular dev staff -- with their placement in the ecosystem being between dev and QA. Much like how "devops" was used as a hiring filter to have sysadmins that can at least read code, I think we should have a "devsec" group that bridges security-QA and dev.
> people that can read a CVE or parrot "best practice", but not really grok the subject or think critically about it (e.g. jumping from one password to another every 3 months isn't "more secure")
So much this.
One place I worked had a head of security that switched us to having passwords that auto-expired every 30 days, had annoying requirements (mix of upper, lower, numbers, and special characters) and not allowing reuse of a password for 1 year. The increase in people having problems was handled by having "security questions" and self-service password resets.
My insistence that "security questions" were just unexpiring, easy-to-guess passwords was met with "But this is the standard!". Pointing out that rapid turnover of hard-to-remember passwords led people to write them down generated a similar reaction.
I put a lot of effort into running environments securely, and eventually, someone always decides to get a second opinion.
The only recommendation I have ever seen come from a security audit in an enterprise, is bikeshedding password lifetimes. Every time I point out "SQL Injection in the logon form" level vulnerabilities, I get directed to the "security experts", which is why I've seen password policies go from 180 days, to 90, to 30, while the mentioned issues get ignored.
People flash a PWC business card and it's seen as credential. Then they drag me to the comms room and spend all day auditing the serial numbers on individual patch leads going to desktops.
You don't need to create a term, you just need to want to hire good people and actually pay for them. With that said, as a security interested dev, I actually work in devops as it's simply the best paying job so maybe a term does need to be created, but if you actually deeply understood security, you'd probably be hiring a devsecops.
To expand on this, I've also noticed that "security" in enterprise-size companies tends to be a dumping ground for helpdesk+ staff -- people that can read a CVE or parrot "best practice", but not really grok the subject or think critically about it (e.g. jumping from one password to another every 3 months isn't "more secure"). It's been my experience that people in security teams can't implement the fixes to the things they complain about because if you're a security-minded dev, your career path will be in dev.
>It's not as fun to be a developer that is really into security but only have that be part of your job.
I think it would be ideal to have security as a parallel track to regular dev staff -- with their placement in the ecosystem being between dev and QA. Much like how "devops" was used as a hiring filter to have sysadmins that can at least read code, I think we should have a "devsec" group that bridges security-QA and dev.