My time at AWS was spent working on application security at scale, most of that time building and leading the SHINE team (Security Hub of Innovation and Efficiency). Our mission to accelerate AppSec for builders, was straightforward and meaningful. We wanted security to enable shipping, not block it. That mission led us into some of the most interesting work I've been part of: automation, secure-by-default platforms, and eventually an AI-powered security engineer that could run reviews autonomously.

This post is the first in a short series about how we operated with automation and generative AI at AWS. Application security has always sat in the path of builders; the goal was to help pave the way to shipping securely. What we saw at AWS was the landscape shifting: automation and GenAI didn't just speed up old processes—they changed how we think about securing applications at scale. I'll cover the challenges we hit, the solutions we built, and what we learned. (I've since joined Pixee Pixee to work on these same problems for a broader set of teams - more on that in a separate post.)

The Challenge

I've discussed the purpose of team SHINE at AWS in a previously, but never the process. We started by focusing on granular problems, like creating binary decision trees to validate security checks automatically. Because the software was built on AWS infrastructure, we were able to solve tough engineering problems by leveraging tools and applications built by other teams with broad access - allowing us to query for most resources.

Most resources. That's where we hit a new challenge.

The problem was that we couldn't perform all of our checks automatically. We first ran into issues where builders weren't surfacing all of their resources in the security review. This is a common pattern in AppSec: builders, focused on shipping quickly, often don't provide complete context upfront because they're optimizing for speed, not security review efficiency. They may omit resources they consider irrelevant, forget about dependencies, or simply not realize what information security engineers need to make informed decisions.

To resolve this, AWS AppSec engineers would meet with builders to get the complete list. This meant we couldn't automatically perform the security validation checks, so we weren't saving as much time as we needed. These meetings created bottlenecks - every back-and-forth conversation delayed the review process and pulled both builders and security engineers away from their primary work. The irony wasn't lost on us: we were trying to accelerate AppSec, but incomplete information was forcing us back into the same manual, time consuming patterns we were trying to escape.

SHINE Discovery Service

In order to try to gather all resources automatically, my team created a discovery service that would enumerate resources based on our software organizations. This was a partial fix, it allowed us to add these resources automatically to reviews, which let our automations run. However, some organizations used one large group to host all of their software and we were therefore were adding too many resources (tiresome to remove). Other organizations had separate groups for permissioning and coding, which meant we might query the permissioning organization and miss the software resources entirely.

This fix helped, but it wasn't a complete solution.

Back to the Drawing Board

We went back to the original problem. Even if we had all of the resources, there were still some checks that required application context and knowledge. Most of this knowledge came from initial kickoff meetings or from the AppSec engineer's experience working with the same builders year over year. This meant that even with our automations in place and operating at full capacity, we still weren't speeding up reviews enough. AppSec engineers have a queue of reviews to work through, and if they had to meet with service teams, this added back-and-forth to the entire process. Even if AppSec engineers had to do less work on each individual review, it didn't scale as the review quantity increased because the engineers were overloaded.

We had to fix this problem at the root. We needed to deliver fewer total security reviews to our AppSec engineers. We needed to approve small or low-risk features without AppSec involvement at all.

SecureCDK Blueprint Property Injection

LinkedIn post about CDK Blueprint Property Injection One approach we took to reduce the number of security reviews was to create secure-by-default platforms. If builders start with secure configurations, many common security issues never arise, eliminating the need for review entirely. This is where CDK Blueprint Property Injection came in.

CDK Blueprint Property Injection is a feature that allows us to automatically apply security best practices to AWS CDK constructs by default. When builders use standard CDK constructs, Property Injection automatically applies secure configurations - things like encryption at rest, proper IAM permissions, network isolation, and compliance with AWS security standards. The injection mechanism is opinionated by design; it makes it easy to do the right thing and harder to do the wrong thing.

This approach fundamentally changes the security review process. Instead of reviewing every application for common security issues, we could focus our AppSec engineers' time on truly novel security challenges. Builders using Property Injection could often skip the security review process entirely for standard use cases, or at minimum, have a much faster review focused on application-specific risks rather than infrastructure configuration.

The impact was significant: builders could move faster because they weren't waiting for security reviews on standard configurations, and AppSec engineers could focus on higher-value work. But we still had a problem: even with secure defaults, some applications needed human judgment to evaluate security risks. That's where the Agentic Security Engineer (ASE) came in.

The Agentic Security Engineer (ASE)

ASE represents our evolution from deterministic automation to context-aware, AI-powered security reviews. While our initial automations could handle binary decisions, such as "Does this Lambda have encryption enabled? Yes or no?" - ASE could understand application context, interpret security requirements, and make judgment calls that previously required human expertise.

ASE works by analyzing the complete context of a security review: the application architecture, the resources being used, the data flows, and the security requirements. It can understand that a Lambda function processing PII requires different security controls than one processing public data. It can recognize when a proposed change is low-risk and approve it automatically, or when it needs human review.

In Part 2, I'll dive deeper into how ASE works in practice, including examples of the types of reviews it handles and how we balanced automation with human oversight.

Looking Ahead

The journey from deterministic automations to SecureCDK Blueprints to the Agentic Security Engineer taught us several important lessons about automation in AppSec:

Automation is necessary but not sufficient. Deterministic checks are essential for catching common issues at scale, but they can't replace human judgment for complex, context-dependent decisions. GenAI bridges that gap by understanding context and making nuanced security decisions.

Shift left, but also shift right. CDK Blueprint Property Injection helps builders start with secure configurations, but we also needed to catch issues during the review process. The combination of secure defaults and intelligent review automation creates a comprehensive security approach.

Scale requires both automation and delegation. We couldn't just make reviews faster - we had to reduce the total number of reviews. By approving low-risk changes automatically and providing secure defaults, we reduced the burden on AppSec engineers while maintaining security standards.

Context is everything. The breakthrough with ASE wasn't just using GenAI - it was understanding that security decisions require application context. By giving ASE access to architecture diagrams, resource configurations, and security requirements, it could make informed decisions that matched what human engineers would do.

The work at SHINE showed that this approach—secure-by-default platforms, deterministic automation, and context-aware AI—can define the future of application security at scale. In Part 2, I'll go deeper into how we implemented ASE and how we pushed this approach further left into the development process.