In this episode of AppSec Builders, Jb is joined by security expert, John Steven, to discuss his BSIMM study findings, the fundamental shifts in AppSec, software-defined security governance, and much more.

About John:

Linkedin: https://www.linkedin.com/in/m1splacedsoul/

Twitter: https://twitter.com/m1splacedsoul

Through his firm Aedify, John advises innovative security product firms as well as maturing security initiatives. John leads one such firm, ZeroNorth, as CTO. For two decades, John led technical direction at Cigital, where he rose to the position of co-CTO. He founded spin-off Codiscope as CTO in 2015. When both Cigital and Codiscope were acquired by Synopsys in 2016, John transitioned to the role of Senior Director of Security Technology and Applied Research. His expertise runs the gamut of software security—from managing security initiatives, to cloud security, to threat modeling and security architecture, to static analysis, as well as risk-based security orchestration and testing. John is keenly interested in software-defined security governance at the cadence of modern development. As a trusted adviser to security executives, he uses his unparalleled experience to build, measure, and mature security programs. He co-authors the BSIMM study and serves as co-editor of the Building Security In department of IEEE Security & Privacy magazine. John is regularly invited to speak and keynote.

Resources:

Latest BSIMM

Aedify Security

Concourse Labs

Transcript

[00:00:02] Welcome to AppSec Builders, the podcast for practitioners building modern AppSec hosted by JB Aviat.

Jb Aviat: [00:00:14] So welcome to this episode of AppSec Builders. Today I'm proud to interview John Stevens. So, John is the founding principle at Aedify where he advises product security firms. John, before that, you led ZeroNorth as a CTO and before that you were leading as co-CTO at the Cigital firm. Welcome, John.

John Steven: [00:00:36] Hello, how are you? Thanks for having me.

Jb Aviat: [00:00:38] I'm great, thanks for joining. So John, another thing that you've done is that you co-authored BSIMM, so could you let us know what it is and how it can be a useful tool to AppSec builders?

John Steven: [00:00:50] Yeah, it's worth clarifying because it's frequently misunderstood. The BSIMM is the building security in maturity model observational study. We went out and over a period of 11 years we've studied about two hundred and over two hundred firms and asked the question, what do you actually do to build your security initiative and to secure your software? And it doesn't prescribe what to do, but you can use it to look at what firms that are within your vertical or that look similar to you in terms of maturity, are doing with their time and money, and decide whether or not you want to replicate those behaviours or cut your own.

Jb Aviat: [00:01:29] So you are interviewing like CISO application security practitioners, developers like every actor of the security game.

John Steven: [00:01:38] Yes. Historically, the list has looked like what you described. What was interesting to us about the last two years of this study is that when we began talking with the CISO, they'd say, oh, you need to talk to the VP of Cloud on this, or actually you need to talk to the SREs and to to delivery or to the VP of engineering. The people we had to talk to fundamentally changed over the last two years. And that was a key finding that we we wrote about this year, that the people doing the work of security were shifting from the security group to the engineering, digital transformation and cloud groups.

John Steven: [00:02:20] And that's a big deal, right, because there's been these phrases that we've held dear for 10 years or more. You know, building security in is something that we've said for two decades. Me and a colleague argue as to who said shift left first and we've ended to like November of 2001 when we first said that. It was a long time ago. The other thing we say is that security is everybody's responsibility. Every developer, every engineer, every operator needs to think about it. And we've been harping on those things forever. And what we see is now that engineers, now that SREs, now that operators are taking a really first class citizen role in security, people are taking that 'security is everybody's responsibility' to heart. And in fact, who makes up a security initiative has now changed. And that's a really big deal.

Jb Aviat: [00:03:08] Yes, it is. And so a trend that we have seen over the past two years is like QA testing moved from dedicated teams towards the hands of developers and they are now writing their own data and then monitoring their own deploy, running back if necessary. And so what you describe about security is following the same trend, right? So the teams are now starting to own security by themselves.

John Steven: [00:03:35] Yeah, and we see what we call engineering-led security initiatives, where engineers are not only acting as security champions and participants in a program, but the owners of practice areas and the drivers of the program. So it's not uncommon in some organisations, particularly ISPs, that are more mature, for them to have a Product Security Lead or a Chief Architect who has full purview and responsibility for security and for those people to do the things that you'd expect the security group to do prior. Pick defect discovery tools, tune those tools and drive to a secure coding standard, you know, generate and administer a training program associated with those standards and those tools, you know, and build security blueprints and so on and so forth.

Jb Aviat: [00:04:22] And so you mentioned shift left. So now what I understand is that you are not like advertising shift left anymore. So, due to this change in the industry, now that security is done to be done by people that are actually conceiving and building the things.

John Steven: [00:04:41] With the benefit of time, anything, anything will look wrong, I suppose. So, you know, when we talked about shift left, we were thinking about all of those organisations that use spiral or iterative development or even worse, waterfall. And, you know, we would talk about, look, you know, we can pentest your software, you can apply testing to your software. But wouldn't it be better if you moved earlier in the lifecycle and found those bugs as you were developing them so that they were easier to remediate? And that was the basis of shift left and everybody cited the rational study and it's cheaper to to fix things earlier and yada, yada. You can see why that's a valuable precept. But think about how orchestration platforms and how software delivery has changed over the last five to seven years. We're using Kubernetes you know we've changed the way virtualization has happened. We're layering on top of Kuberntes things like Istio. More and more of the way we deliver software is becoming code, and the whole infrastructure is code movement and the whole delivery and pipeline orchestration movements. What that means is that more and more of the stovepipes between build, test, deliver and operate are being broken down, so that a DevOps engineer can shepherd a greater percentage of the software lifecycle in self-service mode. I don't have to hand something over a wall to you. I can walk it further down the lifecycle pipeline myself. And even the the bridge between Dev and prod is becoming a softer wall than it has historically been.

John Steven: [00:06:26] Cloud, open-source, all of these are self-service technology stacks that allow you, again, further control over a larger percentage of the lifecycle. And so what that means is that code is creeping right in the lifecycle. When you use Kubernetes Istio configuration files, when you use infrastructure-as-code, cloud service provider configuration, what you're doing is you're driving that code right in the life cycle and saying more and more of the way I build, package, deliver and operate is going to be software defined. So more accurate than shift left is maybe shift to where the code is. And what we're seeing is that the code is shifting right. So your know my keynote of the BSIMM conference two years ago was shift right to do security everywhere. And it was extremely aggravating to the attendees because after two decades of moving to the left and trying to get closer to design and requirements, I mean, Laurie Williams out of North Carolina has published a study that says that as much as 10, 11 percent of your code may be infrastructure-as-code and that 30 percent of the churn, month to month in your code bases, is that code. So there's data based evidence that says that that code is moving right.

John Steven: [00:07:42] And so we must move right with it if we want to get earlier. And so this is really never REST. Your security initiative needs to follow the tr...