The “Two-Slice” Team and Machine-Speed Security

Hey guys, thanks for the throw. We're here with Hart Rossman, who's Vice President of Security for AWS, and we're having a little chat about, well, what is the future of security going to look like in the age of AI, and especially how our teams are going to be constructed, because everything is changing. Hart, welcome to the show.

Hi, thanks for having me, Mike. All right. I think it's fair to say that AI is going to enable both the good folks and the bad folks to discover vulnerabilities faster than ever.

And hopefully, we will use AI to create the fixes for that faster than they will be exploited, and it's a bit of a race against time, as it were, and some people might call it an AI arms race. But is it your assessment that these two things are going to happen in tandem, or is there a gap between the two and things might get a little worse before they eventually get better, or how should we be thinking about this? Mike, I've always approached security with a bit of an optimistic lens, right?

Each new evolution of whether it's technology or tactic or operational principle gives us an opportunity to raise the bar for security and do better at scale. And so I'm excited about AI. I'm excited about the prospect of teams learning to be more efficient and effective every day and at scale.

And so I think for the security teams that are willing to lean into change, that there's tremendous upside. And that's really, I think, the challenge. Many security teams, the new and the unfamiliar can be scary, can appear to be untrustworthy, and so they're reluctant to change.

And in today's environment, the pace of change is so rapid, you can't afford to sit on the sidelines and watch and wait. And to your point about that, all these things are happening now at what we would call machine speed, and maybe it'll seem kind of quaint to the way we used to think about security and call it stressful back in the day. But the existing workflows and processes, and maybe even the ways we're organized, just don't seem to lend themselves to machine speed.

So do we need to rethink how we're approaching this from an organizational perspective because, well, if the tools change, so do the workflows. Yeah, I really think we do. The way I've been encouraging my teams to think about it is you've got two gears, right?

You've got that fast-twitch muscle, and then you've got that slower, more strategic thinking. The more strategic thinking, that looking over the horizon, this connecting the dots, sometimes we call them one-way doors at Amazon. Those are still vitally important, right?

What we have to do is recognize that most decisions, particularly at machine speed, are not that. They are fast, they are iterative, they are quick to experiment. And so, in the past, maybe where you would've sat down and written out a BRD or a PRD or a product doc of some sort, today, you should build a prototype that's a candidate to go into production.

Right? So don't spend an afternoon writing a doc. Spend an afternoon building a proof of concept.

And then don't spend a week iterating and reviewing the doc with your peers. Spend the week iterating and building a candidate production build from that proof of concept. So taking this to its nth degree, I think when I talk to IT folks, there's always been this sense of fear about patching something without first testing it and going through that whole process, and that can take days, weeks, sometimes even months.

And the concern has always been that the application will break. But it seems we're approaching the point now where maybe I do need to automatically apply whatever fix is available the minute it becomes available, because the bad folks are able to exploit that now in a matter of minutes as well. So I may not have the luxury of testing things the old-fashioned human way.

So does this whole loop of what we call DevSecOps need to become much more automated than we've ever imagined? So I guess I would say I don't fully agree with all of the premise of the question. I would say, though, that the benefit of AI and the benefit of AI development life cycles is that things we've always wanted to do in security at scale reliably are now possible.

So test-driven development, having complete coverage of code when you do a vulnerability assessment, is all now possible in a realistic period of time. So you don't need to spend weeks or months testing. You can do it in hours or minutes, which means you can patch infinitely faster than you could in the past.

What it can sometimes surface, though, are organization-wide mechanisms that are too slow, right? And so it gives you an opportunity to rethink, to streamline, so that you really can patch at the speed that you need to. It's just one example, right?

And AI gives you that advantage. There's a couple of different ways it does that, but this whole idea of interacting with an agentic IDE to steer the development of whether it's a piece of software or patch, whatever it might be, and then use test-driven design, use spec-drivenDesign and development so that you get the output you're looking for, and it is computationally correct. It's just a huge opportunity for the defender.

The models themselves are getting smarter, and so are the reasoning capabilities. And I've talked to some other folks recently where it's rare that an AI model, for example, generates a SQL injection vulnerability these days, and that used to be the bane of our existence. As we kind of work our way through all that, is the software that we initially create going to be more secure in the first place than it was when humans built it?

It may not be immediately, but it seems like we're heading in that direction. Yeah. So what I'm definitely seeing is the code that's being generated is more often than not bug-free, or it's correct.

Where there's the gap is sort of the intent. Is did you describe enough about the system for it to build all the right pieces and parts to get the outcome you were looking for? The code is correct, but did it build the right thing?

And did it add all the components? And so now you have to think about even more than you did in the past, security as a functional requirement. So it will build all the security features you need if your intent is to have a security bar that it meets.

And so then you go back to, okay, well, did I ask it good questions about the cryptography that I need? Did I ask it good questions about the authorization model that I need? And if you do those things, it's likely to produce software that includes security as the right functional output of your request.

I was also talking to somebody about this whole issue, and one of the things that they had pointed out is if the timeline changes in terms of what it takes to create and test a patch, well, the economics around outages changes dramatically. Because their point was, well, if I do have an issue and I create a patch and it knocks off the app, well, it's only going to take me a few more minutes to fix the patch and redeploy it anyway. So the amount of downtime might be only measured in minutes and not hours and have this major level of disruption.

So has the risk level of automated patching kind of declined? I think it is, and it will continue to decline. What you described is a little bit of a perfect state, assuming everybody has a modern automated pipeline, they're using a monorepo.

They've got some experience, and they've built up a point of view and some of the automation around it to do that. There are still lots of organizations in the world who are, for example, just transitioning to cloud or are, believe it or not, still getting into DevOps. And then there are a bunch of workloads that, for a variety of reasons, may never be fully automated.

In certain public health and safety systems. But I do think that's the direction things are going, and if you have a system that could benefit from that today, again, there's no reason to wait. What's the impact on the security operations teams?

Because I would argue that historically, there's not always been a lot of love lost between SecOps and the developers, and SecOps tends to view developers as kind of the root of their cause of their problems, and the developers always viewed SecOps as something to get around. Is that relationship going to change in the age of AI? Will we get to the point maybe where the two will see more eye to eye?

I certainly hope so. I've long believed that you can't protect what you don't understand, and I think in the technology world, it's easy for us to put that lens on the technology itself. It's difficult to make good risk-based decisions about how to deploy a database if I don't understand the database technology.

That's also so true about people in organizations. And so in my org, we talk a lot about this concept of EPIC leadership, which is a way we use to understand the people in the teams we're interacting with to get aligned and deliver the best outcome. And EPIC is an acronym.

It stands for empathy, purpose, inspiration, connection. And so taking the time to deeply understand the operating system of the people in the organization, and then proactively investing in the things that are going to get the best outcome. And the addition of AI is so beneficial there.

One is you can literally create persona agents, so you can sort of pre-evaluate the impact to your builders by interacting with an agent that's representative of a particular builder community. Whether you're testing a message in communication or you're modeling out a certain change. But the other thing you can do is use it as a common point of understanding.

We're all shifting into the AI era, the age of agentic. And so we've got a common set of challenges and opportunities that we can choose to work through together, or we can choose to work at odds. And I think to your point, it's an awesome opportunity for security and the business and the engineering orgs to make the decision to invest in speed, to invest in alignment, to reduce friction, and to raise the bar for security at machine speed with big functional outcomes for the business and customers.

So how do we get there? " So we have this notion of secure by design, and you mentioned intent, but how do I express my intent to follow secure by design principles in a way that actually creates that outcome? Yeah.

So there's a few ways to do it. Of course, you can start with the prompt, right? " That's one approach.

But another approach is that as these technologies are maturing, you have the ability to provide what's often called a steering doc. So it's a markdown file that basically governs how the AI should interact with everybody and everything on that project. And so a great best practice is to implement a security steering doc that memorializes in plain English or whatever your native language is, what are some of the security expectations, what are some of the guardrails, what are some of the requirements, what are some of the regulations that we want all of the software to meet, regardless of whether it was explicitly asked for in a particular prompt or conversation.

And it's a wonderful way to scale that sort of culture of security in your organization, do it agentically. " Is there kind of things that leap to mind where it's like, yeah, if we just started out on this right foot, things would be better? I'll say two things.

One is, I'm always surprised at the number of people who view working with AI as the last step in the build process. They'll have a requirements meeting, they'll do a bunch of whiteboard, they'll create all these wireframes. They'll do all of this upfront work to then go sit down and formulate their prompt.

And the beauty of the environment we're in is you can invert all that. " And start building it interactively with the AI. Right?

So I'd say that's the first thing is start with AI, don't end with AI. And then the other thing I would say is that, I think people are now in a world where you can build so quickly that they underestimate the level of effort to finish. It's a little bit of the Pareto principle all over again.

And so they get 80% of it done in the first couple of hours and hadn't really thought about the more complicated elements of what they're trying to do, which of course could then take days or weeks to resolve. And so they're surprised that they didn't finish in an afternoon because they've heard all the hype about how fast AI is. And it's like, yeah, you got the 80% solution out of the gate.

Now with the human in the loop, you got to go reason about the hard part, and that could take a while. So to close this out a little bit, historically, I think if I looked at an organization for every, and I'm guessing, but for every 50 developers, there was one person maybe who was kind of in charge of DevSecOps, and they were doing that on the behalf of the other 50. It's probably maybe closer to 100.

Is that whole structure now obsolete? Because in theory, DevSecOps is going to be pervasively deployed throughout the software development life cycle using AI, and I won't have to be dependent upon the expertise of one to support 50. So what I'm seeing a lot of is smaller, flatter teams that are multi-dimensional, they're multidisciplinary, and they're moving very quickly.

And so, in Amazon, for example, we always talked about a two-pizza team as a team large enough, obviously, to eat two large pizzas. So maybe eight to 10 people, 10 to 12 people. Today, we're seeing maybe they're two-slice teams.

You're seeing groups of two, four, maybe six people, who are working with lots of other teams of two, four, six people to build just phenomenally complicated software simply and efficiently and effectively. Well, folks, you heard it here, the way we think about building secure software is going to need to change. There's no two ways about it.

It's just a question of where are we going to fit not just the humans, but all the AI agents that make up that workflow to create something that is, well, hopefully better. Hey, Hart, thanks for being on the show. Cool.

Thanks for having me, Mike. All right. And back to you guys in the studio.