Moses also holds weekly application security review meetings with all of AWS’ service team owners

Now as CISO, Moses is responsible for security across AWS’ cloud platform, leading product design and development, security engineering and strategy. He hosts a weekly security review meeting with AWS CEO Adam Selipsky and his senior vice presidents and select vice presidents.

“This meeting is the mechanism that enforces the culture that security is ‘job zero’ at AWS,” Moses said. “People are held accountable for resolving open issues, and strict timelines are adhered to for resolution.”

New services will not launch if there are any known security issues open, he said, but delaying a launch is very rarely required.

“Our security teams are deeply engaged with new services and new feature development from the beginning,” he said in a recent interview with Protocol. “A highly collaborative, as opposed to oppositional, culture when it comes to security reinforces the trust between service teams and security teams.”

It really comes down to making sure that we have the right tools, techniques, processes and people in place from the start, shifting as far left as we possibly can – meaning that security is part of the design of the things that we’re making. And not only security in mind from the design standpoint, but the protections that you can put in place, detective or otherwise.

If you have a scanner that’s running across your code after it’s already been written, that means that you didn’t catch myladyboydate it in the design or the initial coding phase. Finding an issue after something’s gone into production and is public, and you have a CVE and all of that process, it’s very expensive to then mitigate that and to patch. We’ve moved as far to the left as we can and mechanized things.

They’re like, “Oh, it caught that I did this

One of the things this year that we found is that moving a lot of the code analysis straight into – before there’s ever even security reviews officially – the builder space, into the developer environments that they use, so that things are getting fixed before security officially would kick in and do reviews of the software. The good part of that is the developers are then catching it as it happens and then changing it is an education for them. This is an anti-pattern that I shouldn’t do,” and then they don’t do it again. And the percentages of increased capacity, if you will, is huge there because, once again, further left that we can shift stuff.

Every possibility that you can have to move further and closer to where code is being written by individuals or even further into the design phase means [reduced overhead], both from a development time as well as from a security perspective, to the overall process

My goal, in the fullness of time, would be to put our operations or responsive operations out of business. It’s not a real possible goal, but as much as we can to move things to the left so that we’re finding them earlier, remediating them when they can be most impactful and people learn from that so that you don’t have them happen again, the better situation we’ll be in across the board.

[The] last thing that any software development engineers like to do is repetitive, boring stuff. And the more that we can make it an automated process earlier on, the less impactful it is to their timelines of developing and deploying innovative new services or features. So far, the feedback from the teams themselves is positive. And that’s really what I like is that you’re making a security impact, but you’re also making the developers and the teams themselves that are trying to build new capabilities for AWS users, you’re making them happy. It goes back to … making security the path of least resistance.