|
I may not be caffeinated enough to participate in these threads articulately, but this question made me realize something that hadn't quite clicked before. As I have experienced it, the existing (waterfall?) model for deploying new features and bug fixes in large organizations requires going through QA and security review, where (hopefully) the on site security team has some sort of checklist or guideline for doing whatever analyses they do. But as they move over to agile, continuous integration/delivery, is there still time to deploy a complete staging build and wait? We have been working with small companies for ~2 years now and I haven't rigged up something to test code in at least a year. Mostly I just stare at it until I've figured out if I can exploit it. This is where large companies might trip and fall, if they expect their existing security analysts/teams to do this (or, as you say, if they try to offload it onto developers or ops people, even ones who are more interested in security). I don't like how this sounds, what I am about to type, but the majority of security people -- particularly the ones at the level where they are hired to run QA-type audits -- do not know how to review code. It really does make me uncomfortable to say this, but if that's the rock, the hard place is how many times I've had to tell someone they really need to learn to code if they want to "work in security." So when you say, "good security people," what you mean is people who can read and write code, and also have enough experience to know when that code can be used in a way that the original author did not intend to. It's almost as if there's a misconception that being able to read and write code is what you do if you're a dev or devops. This mindset is odd to me in so many ways. It's like saying, "I don't need to know how to use a screwdriver or a hammer because I'm not a carpenter." Even better, someone who understands what it feels like to be under some pressure to roll out changes where there might not have been a lot of time to consider malicious behavior. Someone who has your back. Just yesterday or the day before, I had this inexplicable crisis where I was concerned about the value I am providing. It's gone now. Thanks! |
For others, their appsec team(s) is/are constantly building security libraries, frameworks, and tooling, and scanning code for security issues with software and manual review on a daily basis.
Information security is still just a checkbox for a lot of companies. This is gradually changing with more and more breaches in the news every few days and executives who are finally starting to appreciate that the consequences of a breach can be very bad, but it's still pretty common. I really don't think many companies have solid appsec teams that are doing the things you and I would hope they would do, and I agree that probably a scarily high percentage of "application security analysts/engineers" do not and cannot review code effectively.
You are absolutely right that knowing how to write and read code are crucial skills for many aspects of infosec and that a lot of people neglect that, and it's disheartening that there are many companies who don't really have people like that on their security teams - even companies that claim to have an appsec program. But application security is also only one aspect of a solid information security program, and some other aspects do not necessarily require development knowledge beyond the basics.
From what I know and have experienced to a small extent, FAANG (and others in/near that tier) invest a ton into application security and really are doing it right, at least. (Or are at least doing it way better than 99% of other companies out there.)