Ten plus years ago the security team would actually read our code. They knew what to look for, where the language or database or server had vulnerabilities. Any issues they brought forward were actual real issues that needed attention. Now so many "security researchers" are simply running our code through automated tools. I have to spend time helping them create the Jenkins jobs to run the task and then they also need help analyzing the results. For example I had to explain dev dependencies don't ship with our production code so a given exploit is not applicable. Do I just work for a junk company or is this the new norm?
In my roughly 10 years of experience at megacorps, security related work towards products is generally treated like a compliance matter for the company, for better or worse. My experience in summary:<p>Testing: the security team run a few ad hoc tests, or only run the app team's automated security tests, or not at all.<p>Models: Once I built a threat model interactively with a security team member, but most times they'd ask the app team to put it together and send it to them. Usually would be reviewed with a few questions.<p>Paperwork: most of the is spent filling out forms, looking at automated tool results and addressing as needed, providing spreadsheets with new features or changes and their security requirements.<p>Code analysis: I don't think I've ever had a security team member read source code. Maybe I'm not remembering, but I genuinely can't think of one. I would love to have this happen though.<p>So, I guess I haven't had a good experience with security teams overall. I don't generally attribute that to the team itself though. They're often way over taxed and trying to oversee upwards of 10 projects with tons of reporting requirements and deadlines for releases. There's really no way in their structure or funding they _could_ do more than this. It's kinda amazing they even get this much stuff done now that I think about it! But yeah, I've never had an experience like you describe.
Yes.<p>I left security a few years ago because I saw the industry turning to shit. It's gotten worse since then, IMO.<p>What I see as the contributors to this, in no particular order:<p>- Computer security is growing much, much faster than software in general. This has attracted a lot of snake-oil salespeople, bullshit artists, and gold-rush types.<p>- The genuine security talent pool is very small, and not growing nearly fast enough to meet the genuine need. A lot of organizations end up staffing their security teams with incompetents because their only other option is not hiring anyone at all.<p>- Security education, training, and mindsets all seem stuck in the '00s. People who make the effort to learn about security end up learning a bunch of stuff that's simply not applicable to modern software, and they miss a bunch of stuff that turns out to be really important.<p>I can go on.
Yeah it seems like the current version of InfoSec is closely tied with compliance and audits. Meaning they don't really care about getting hacked as long as we filled out the right form, and checked the right check boxes and the lawyers are happy.
I also agree that these days, the average InfoSec Engineer is less technical than the average Software Engineer and it shows. The security tooling is just terrible relative to other areas.
I think the part about running it through automated tools is fine, so long as they can read and understand the code in highlighted areas. This provides a repeatable, standardized process which eliminates <i>some</i> of the chance for human error. It's especially helpful in helping to remember what vulnerabilities exist in version whatever of various libraries/servers/etc. That's all stuff you'd be looking up in a CVE list anyways. Of course you need knowledgeable people configuring the tools and building custom patterns to search for the PII or other company specific sensitive data (paterns and var names).<p>Even with this, they should be having a conversation with the dev team to understand the intricacies and to double check that the documentation matches the current system (can't tell you how often old docs are used and were missing something).
Having worked in the infosec community for close to 20 years now... What you are seeing is the result of the commoditization/expansion/specialization of the industry.<p>The issue with security is there is literally unlimited work and only a certain amount of budget to work through it. So CISOs are constantly looking for tools to automate or reduce the dependence on people and to be frank, they are all pretty shitty. Then what happens is the CISO has blown his budget on tools that supposedly automate all this work and designed his program so they don't need "rockstars", because they are expensive (aka people who know what they are doing).<p>Whats happening right now is that the only companies that can afford or attract competent people in the industry are large tech companies (and even some of those have incompetent leadership and can't attract decent people). Really good security people are basically consolidating at a few dozen companies and are kind of handcuffed there because other places are terrible to work at/don't pay as well.<p>So basically you see this massive delta between the people who know what they are doing and the ones who have gotten into the industry in the last 3-5 years. One of the massive downsides to this consolidation is the places that are willing to hire early in career positions don't have experienced staff to mentor these new folks. And since there aren't good mentors, people aren't picking up the skills you would want/expect from them.
It's happened with most IT positions. In the past most IT people went into the field because they were fascinated by the subject. They were just thrilled that they could get paid for something they loved. That was ok then since there were relatively few positions needed. Now the need has exploded and it attracts people that need a job and want a career. These people don't have the same devotion. That's ok. The industry and we old-timers will adapt. A job/career doesn't have to take over your life. In time, we all adapt.
As a member of the Security community, it's disappointing to hear that this is the perception on the table, because our community can and should do much better than that. In my experience and goals, the best Info/AppSec/SecEng teams put people before processes, build guardrails instead of walls, and demonstrate first hand what they want to see engineering teams doing. If you're open to it, I'd like to offer perspective on why some of the perceptively dumb things that sec teams do, do.<p>Those automated tools are better than ever. Manual code reviews are very important, but automated tools at this point can stand in for "over the fence" pre-production code reviews, as long as periodic reviews occur. In particularly sensitive contexts, especially finance, code is always signed off on by security before release when it can have impact on anything important. It's all about risk management.<p>Additionally, the cloud and SaaS is nothing like it was a decade ago. Security is now more focused on compliance due to the nature of building software today. You used to maybe provision a handful of nodes on EC2, use an autoscaling group if you were super fancy, and probably integrate into a handful of third party APIs. Every business is different, but that was the core of running a workload. Now, I can delegate specific responsibilities to third parties and reduce both people and operating costs. But with that comes massive risk since you just transferred an internal business function to a third party you have no control over. The most common approach to that risk is through process: vendor reviews, compliance and cloud posture security management.<p>And then there's DevOps who ends up being ad-hoc security way too often with no relevant background (or interest).<p>All that to say, good, compassionate security teams do exist.
I think you get what you pay for in security, and it's clear that a lot of the c-suite are happy to pay to tick boxes... so you get a lot of going through the motions.<p>Also, this isn't really new. When I worked as a more Junior person about a decade ago, lots of decisions came down to what was cheaper or faster, not what was secure.<p>To have good security, it's a cultural and organizational thing where the people at the top have to be on board.
Yea 100%... our company has gone through CSO's, at least one of them actually setup owasp and sonarqube himself.<p>The latest though... just good at creating documents, because he came from government background and all they care about is checking boxes. An absolute wizard at absolving himself of responsibility, very jealous.