Diving Into DevSecOps with John Willis pt.2

**SPEAKER_1** (0:02)
Hey, welcome back to the second and final part of our DevSecOps series with John Willis. Let's jump back into it. This episode is sponsored by LinearB. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity. Sign up free at linearb.io.
John, let me ask you this.
You were talking a lot about, I think, kind of giving the right information to developers or right information to a security team or the right information. I remember when I was doing development, we were not in a DevSecOps mode. We were in that mode where we're doing a pen test once a year or we're going through our SOC 2 renewal process. And yeah, I get delivered like a big report and then I have to do some type of translation to actually figure out what I need to do in the code, okay? Which sucked, that was terrible. What type of information do you think should go to the developer while they're coding? Like what is useful?

**John Willis** (1:14)
Well, again, I think there's the sort of easy answer, hard answer, right? The easy answer is my broken record automated governance, right? Which is sort of imagine this, imagine that in this organization, in order to use these sophisticated, and the other thing you do is the reason you sort of game people to use these automated governance. Why? Because you say if you do things this way, then you don't have to go to the cab.
So when somebody says, how did you guys manage the cab? Like, oh yeah, we went ahead and used this automated government. And so imagine that you set up this sort of in the pipelines, it has all these attestations and gatings, it's stored. There's a policy as code that actually drives it. So here's how to train. So the original team is going to build a new service.
They consult with risk. So imagine this, they literally go to risk and say, hey, we've got this service, we want to use the new policy as code and automated governance solution. They collaborate to create a YAML file that describes the things that need to control that particular component.
And so that becomes, and they agree on that, and they arbitrate, and maybe it was back to sort of, well, do we really need this? Tell me why you don't think you need this. Well, OK, yeah, you might be right. You don't need that, right?
And actually, that becomes evidence for future people who will say, oh, this one had an exception, and here's why. So when people are searching. So anyway, now you take that sort of policy as code YAML, and it's now part, it's an artifact, the part of the delivery.
So now it's part of the delivery that not only you have these immutable sort of signed attestations happening, of all the things, like it must be 80% code coverage. It has to have a cyclomatic complexity of less than whatever, five, I don't know what, you know, five. It has all these things.

**SPEAKER_1** (3:09)
There's a policy. It's a policy.

**John Willis** (3:11)
It's driving that, and the evidence is being created from the policy, and it's stored. And now at the end of the day, and there's sort of like again, think blockchain, don't use blockchain. There's sort of a blockchain event that not only includes all the attestations, but it includes a digitally signed signature of the policies code.
So now you have a point in time of that. And so now the things that could go wrong during the delivery are very pinpointable to the policies code that the thing you've already arbitrated over why it's there. Now, it doesn't answer the hard problem is like, okay, I got something in my code base, you know, how do I code around this? Then you take sort of a mature environment like the one I was talking about earlier, it would be maybe have when they give the event, they might have examples of how to do that right, so everybody who sort of encounters this, you start creating your own repository of the right way and the wrong way. So now if I get, again, I'll just use simple ones that aren't always relevant, but if I get an SQL injection, like, well, shit, I mean, how do I do this? And then like in the event that you got it said, here, look here, this is telling you what you did, here's an example of how this organization, you know, best practices is to do that.
And not only that, though, there's some freebies too, like, and again, I don't know what part of like sonotype is free or not free, but like I've done some workshops with them and like even in their IDEs, you know, we did a workshop where we implemented the, the Struts to Jakarta purposely, and then like had developers push it through the pipeline and then show them how they could use like, you know, Metasploit and all these things to hack. Yeah, but the part of the, like when we started adding the solutions on top, right?