iTranslated by AI
re:Invent 2025: Practical Frameworks and Tools for Building Application Security Programs on AWS
Introduction
By transcribing various overseas lectures into Japanese articles, we aim to make hidden, high-quality information more accessible. The presentation featured in this project, based on that concept, is as follows!
For transcription articles of re:Invent 2025, please check the information gathered in this Spreadsheet.
📖re:Invent 2025: AWS re:Invent 2025 - From Code to Cloud: Building AppSec Programs with AWS (SEC222)
In this video, AWS Senior Security Engineer Daniel Begimher and Principal Security Engineer Patrick Gaw explain a practical framework for building an Application Security program within an organization. Defining AppSec as a collection of people, processes, and technologies that evaluate the security characteristics of software throughout the development lifecycle, they center their approach on the concepts of distributed ownership and shift left. Building the program proceeds in four phases: Plan, Prepare, Execute, and Scale, and is based on five principles: setting clear expectations, empowering developers, automation, measuring metrics, and organizational buy-in. They particularly emphasize the importance of providing an "easy button," demonstrating communication techniques using the EAST model (Easy, Exciting, Attractive, Social, Timely) and concrete implementation methods leveraging tools like Amazon Q Developer (Kiro), Amazon Inspector, and Threat Composer. Strategies for scaling through the decentralization of decision-making via the Security Guardians program and the creation of reusable artifacts are also introduced.
- Please note that this article is automatically generated while maintaining the content of the original lecture as much as possible. Be aware that it may contain typos or incorrect information.*
Main Content
Session Overview and the Big Picture of AppSec Programs
Hello everyone. Thank you for joining this Thursday afternoon session at 4:00 PM. Welcome to SEC 222, "Code to Cloud: Building AppSec Programs with AWS." My name is Daniel Begimher, and I am a Senior Security Engineer at AWS. I have been with AWS for over five years, and for the past 13 years, I have worked in various security domains, including incident response, application security, and more recently, security. Today, I am joined by Patrick Gaw.
Hello everyone, I'm Patrick Gaw. I am a Principal Security Engineer on the AWS Global Services Security team, and I have been with AWS for about three and a half years. Before this, I served as VP of Security at a late-stage startup, where I helped build their Greenfield Security program. Prior to that, I worked as an AppSec engineer, building and operating security engineering teams and architectures. It is an honor to meet you all today.
Great. This is a level 200 breakout session. Over the next 60 minutes, we will dive deep into AppSec and how you can build an AppSec program in your organization. By the end of this talk, I hope that no matter what stage your AppSec program is at—whether you already have one or are planning to implement a new one—you will walk away with practical tools and a framework you can implement in your own environment. Patrick, please go ahead.
First, I will start by giving a brief overview of what application security is. What exactly does AppSec mean? What is an AppSec program? Next, we will discuss the principles of AppSec. From there, we will dive deep into the roadmap for an AppSec program, which we have broken down into four distinct phases. We will begin with preparation and planning: which metrics need to be defined, which metrics should be collected, and how to communicate with various stakeholders in the organization when implementing new AppSec controls. Next, we will cover execution. I will show you how you can actually implement threat modeling, code scanning, and other solutions by leveraging AWS services. We have some demos planned for that as well. Finally, we will talk about scaling: how you can do all these things at scale. I sincerely hope this session will be valuable and helpful to you all. Patrick, please.
Defining Application Security and Two Dimensions at AWS
Thank you, Daniel. Before we dive into the main part of the session, I want us to have a common understanding of what application security is. Application security is a collection of people, processes, and technologies used to evaluate the security characteristics of software across all phases of the software development lifecycle. I want you to focus on the latter part of this definition, because it gives us unique insight into how we view application security and security here at AWS. It is really along two dimensions.
The first dimension is about this concept of ownership or distributed ownership. If you ask anyone at AWS, from top-level Matt Garman to individual contributors, they will say that security is a top priority. That is the first point, and it includes the concept of distributed ownership. Everyone at AWS who builds and operates services has some level of responsibility and accountability for the security of the services they build. That is part of it. Specifically, when our builder teams build and operate services, they are responsible for the security of their services, but they are also empowered to make security-related decisions on behalf of AWS. That is the first point: distributed ownership.
The second dimension is about the concept of "shift left," which is integrating good security practices throughout the SDLC. If you had asked me about AppSec 10 years ago, we would have been doing bolt-on security as an afterthought after pushing code to production. Today, we are thinking about integrating good security practices as early as possible in the SDLC. I am sure you have all heard the term "shift left." That is distributed ownership for scaling. The second is integrating good practices—security practices—as early as possible in the SDLC. Daniel will actually cover the core mechanism we call "threat modeling," and show you the high-level framework and approach, which is a central part of what we do here at AWS.
So why is that important, if we are doing it correctly? It really helps our builders build software faster and get features and capabilities into your hands as quickly as possible, while simultaneously maintaining a high standard of security.
When we think about integrating all these applications and bringing in best practices as early as possible in the SDLC, we also reduce organizational costs and risks. Honestly, it is much easier to make changes on a simple diagram or architecture diagram than it is to actually roll back code that was insecure from the start and then deal with the impact related to the potential exploitation of security issues. If there is a saving in time and costs, there is more time and money to reinvest in other improvements for the program.
Five Core Principles Supporting the AppSec Program and the Importance of the "Easy Button"
So, how do we do it? There are truly five core principles that we at AWS abide by. The first is to set clear expectations. From an organizational perspective, it is about truly understanding your organization's risk tolerance and risk appetite, and defining what that security bar looks like. Once you have defined that, you then clearly define the security requirements, policies, and standards that you will promote and enforce across your entire AppSec program and application portfolio.
I mentioned the concept of distributed ownership earlier, and the service teams building and operating services at AWS are responsible for the security of those services as well. We empower them by giving them knowledge. That is, we have robust training mechanisms and are educating them on security knowledge. We also teach things like threat modeling. Many of our builders look at architecture diagrams as part of their standard development process. As Daniel will explain in more detail, they identify risks early in the design phase and are trying to build security in, rather than responding after the code has been pushed to production.
In other words, the second core principle is having robust training and community to enable developer teams to actually build securely. The third is automation. We use automation to automate undifferentiated manual processes, and when we define security requirements, standards, and policies, we use automation to consistently apply and enforce them throughout the SDLC.
The fourth is about metrics. At AWS, we are obsessively measuring everything. Think of metrics in terms of the number of security flaws by severity level, by different business units, and by lines of business. Because that allows us to understand the current security risk landscape. It also serves as a foundation for continuous improvement.
Fifth is the concept of organization, which I touched on a little earlier. When I say organization, I mean organizational buy-in across the entire company. As I mentioned, security is a top priority for us, from Matt down to individual contributors like myself, and that is key. Another aspect underlying these five key principles we use to drive the program, and another underlying principle I will show you next, is based on my own past experience.
A few years ago, when I took over a new technical team and had to restart a program, I needed to gain visibility to understand where the security risks were within the application portfolio. We evaluated various application security platforms that could do things like Static Application Security Testing and Software Composition Analysis. One of our core requirements was how effective the SAST and SCA engines were. What I did not consider—and in hindsight, it is perfect—was whether this tool was something developers would actually use. This was a tough lesson for me.
When we deployed this platform, we selected and deployed it, but it took probably three times as long as it should have. The problem was that I was asking the developers to actually do the build and compilation to build the software, and then log into another platform and upload it to actually perform the scan. This was a huge struggle. I had planned for one year in the planning phase, but it took three years to actually achieve 100% coverage and 100% visibility into security risks across the application portfolio.
This lesson leads to this last principle. And you will see this theme throughout this. It is that we want to provide an easy button for developers. The lesson I learned is that when you think about an AppSec program, whether you are building something greenfield or restarting an AppSec program you already have, you really want to meet the developers where they are. This means from the perspective of tool selection, as well as the method of communication, it means not adding extra processes to what they are doing. We truly want to provide them with an easy button.
This will be seen in many different aspects, whether it is technology or simple communication. Much of this is based on my own personal experience, but there is actually a field of science called behavioral economics. The TLDR of behavioral research is that humans are inherently lazy. I am inherently lazy. If given the choice to take action or to take no action, I choose to take no action. That is the reality. When thinking about AppSec, and when we think about AppSec, we really needed to be thorough and make it easy for them.
Planning Phase: Stakeholder Analysis and Program Charter Formulation
In terms of a practical roadmap, there is nothing special here. AppSec and driving behavioral change is truly not rocket science. This is not a technology problem. It is more of an organizational change management problem than a technology problem. In the spirit of using an easy button, I want to keep it simple for you. There are four phases, and you can use this for a greenfield program or a brownfield program that you are trying to restart: plan, prepare, execute, and scale. For the rest of the session, we will dive deep into each of these four.
The planning phase is really about stakeholder analysis. It is about identifying and engaging stakeholders, understanding who they are, and what their business is. It is very important to keep business goals in mind, because we, as a security team, want to be a function that truly enables the business, not a traffic controller. Identify and engage stakeholders, understand high-level risks, and understand what keeps them up at night. From there, collaborate with them to establish clear, measurable, and achievable goals and metrics.
From there, it is about preparation. This includes performing code scanning across the entire environment and application portfolio to understand what security risks exist in source code and third-party packages. Next, I talked about communicating expectations. This is really about defining risk tolerance, then defining standards, requirements, and policies, and communicating those expectations to stakeholders.
Third, training builders in threat modeling. There are never enough security engineers to support the number of developers. I have been in that position before, and it is impossible even if you work 24/7, 365 days a year. We really want to empower and train builders on security. We want them to identify risks at the design phase and build securely, rather than waiting until after code has been pushed to production.
The execution phase is the stage where we are in a steady state. We are actually incorporating threat modeling as a standard part of the design process. We are discovering and fixing security issues within the IDE before a single line of code is committed to a source code repository. It also includes deploying security tests into the pipeline. This is the idea of wanting to take a defense-in-depth approach when applying controls.
Finally, it is about scaling. Once you have visibility and a continuous process in place where you can see what the application security risk actually is, you can start identifying systemic issues. Then, you can support developers by building secure design patterns, or by providing so-called golden path design patterns or packages. For example, one of the things we do at Amazon is to provide our customers with a consistent authorization experience. We have a golden path pattern for that, as well as all the libraries and packages that we all use as part of that design pattern. This is how you start thinking about scaling.
Finally, what is really important is seeking feedback from the program stakeholders, truly understanding who the stakeholders are, and having a good relationship with them. It is not about saying no immediately, but about how to get to a secure yes. Now, let's take a closer look at the plan phase. As I mentioned briefly, what is really important is identifying and engaging stakeholders. Perform an inventory of applications to first understand what you are dealing with. Understand who those owners are, who the business is, and the operational context.
The biggest pro-tip I will give you here is that whether you are restarting a program or building something greenfield, getting leadership buy-in is paramount. The second is to find security-friendly organizations or leaders to help you generate some quick wins. Engage with those organizations and find high-risk, high-value applications where supporting them will have significant impact. By achieving some quick wins and building momentum, your program will then really start to accelerate. Above all, reframing your mindset is crucial. We will look at some examples of this, as there are subtle differences in communication. But again, it is about meeting developers where they are, not the other way around.
Preparing Phase: Communication Strategy Utilizing the EAST Model
Now, from the planning phase, once you have obtained the charter, engaged stakeholders, have a clear vision, mission, and goals, and have obtained buy-in from a leadership perspective, the next step is preparation and ensuring portfolio visibility. Let's deploy testing. Understand what security issues are in the source code. What are the most vulnerable third-party packages? Identify systemic issues and develop mitigation strategies for high-risk, high-impact applications.
This is quite interesting. Now, we have switched to the communication aspect. And we talked about this concept of an easy button. I like using this framework called the EAST model. When you start engaging with stakeholders and communicating, think of these four letters: EAST. Keep it Easy, Exciting, Attractive (gamify it), and Social. Interestingly, there is a psychological phenomenon called social proof. When you face an unfamiliar situation and do not know what to do, your human tendency is to look at those around you to see what they are doing and thinking. And you tend to do the same thing they do. From here, you will see examples of reframing and ways of communicating that actually encourage a lot of behavioral change; part of that is this concept of social proof. You can see it being put into practice in the next slide. And keep it Timely—meaning, reading the room when you communicate. Being able to understand the best time to talk to someone. Try to identify and remove barriers to action or inaction. But everything comes back to the easy button. You can use the EAST model for communication when engaging with stakeholders.
So, let's go back to the lesson I learned. When I was deploying this AppSec platform, let's call it the "AppSec widget." This probably looks like 80% of the communication at your company. It is not this long, but take a moment to read it; it is quite boring. But what I want you to focus on here is this bolded line: "Action Required: Please enable scanning in your respective source code repositories by the specified date." So, I am deploying an AppSec platform and I want developers to actually start scanning their applications so we can have visibility. It is boring, asks for a lot of action, and makes it difficult, right? For me, this is a barrier to action—a barrier to actually doing something. This is what I was writing probably 10 years ago when I was trying to restart this AppSec program.
Now, let's think about the EAST model in the context of the next email. Take a moment to read it, but there are a few things I want to point out here. The first is the concept of keeping it truly easy. Look at the call to action; we are actually using a default. It says, "If you need to opt-out of scanning for specific repositories, please follow the exception process by January 31, 2026." In other words, we are enabling repository scanning by default to gain visibility, and we are not asking much of the developers. By actually making them opt-out, we are making it easier.
A subtle reframing technique makes a huge difference in how you communicate and collaborate with developers. You also see things like the first bolded line: "Actually, 90% of builders tested found it easy." This is the power of making it attractive. I want to gamify it, make it exciting, and show that most developers are actually using this and think it is a cool, easy-to-use platform. Subtle reframing makes a big difference in how you communicate, as you can see.
Execution Phase: Threat Modeling and Code Scanning with Amazon Kiro
We have come this far. We talked about the communication part, so now let's move on to the execution phase. Daniel, thank you. We started with the preparation and planning phases, but now I would like to discuss how we can actually execute, how we can utilize frameworks and our services to execute the AppSec program within your organization.
Let's start with threat modeling. We want to perform threat modeling on everything. Whether it is a new feature or a new product, we want to start by understanding what could go wrong, and what the worst-case scenario is. There are several phases and frameworks to start threat modeling, some of which we will introduce in a moment. But first, your goal is to identify these risks as early as possible in the software development lifecycle. If a code change is needed, or if you need to change the architecture or include another service or tool, we want to make those changes on the whiteboard, not after the application has already been developed and deployed.
Now, this is an example of a framework, the Four Question Stack framework. You can leverage this and other frameworks when conducting threat modeling, but the principles are very simple. Start by asking what you are working on. Is it a new service, a new app, a new feature, or an existing service? Who is the customer? What is the business logic? What is the exact expected result? Next, what could go wrong? If there were a malicious user, what is the worst that could happen? Can they extract sensitive information? Can they impact data integrity? If the app becomes unavailable for a few hours, what is the risk to availability, and what is the business consequence?
Then, what are you going to do about it? Which tools, which services can you implement to mitigate the risk? You might use a different software package, or you might push a code change. What exactly can you do to mitigate or minimize the risk? Finally, you need to review. Did you do a good job? Were you able to truly minimize what you wanted to mitigate? Did you accept some risks? Can you accept the current state of the application? This process is iterative. You will likely learn from other applications, other projects, and security issues. You need to take these learnings and make sure you are asking the right questions as part of this threat modeling process again.
Now, this is something we are doing here at AWS as well. When delivering new products, features, or services, threat modeling needs to be an integral part of this process. If you want to go a step further on exactly what you need to do in threat modeling, first, make sure you have diagrams and documentation, and understand what the data flow is and what the architecture is. If you don't know what the system looks like, how can you do threat modeling, right? Next, you need to bring all the security teams, developers, and business stakeholders into the same room—or a virtual room—and work together to identify risks and various mitigations.
Then you need to document it. As I mentioned, you want to document everything, and you can actually use some tools. One example of a tool is Threat Composer. This is a tool available as an open-source tool in a GitHub repository. We will share the link later. But the idea is that it helps you conduct this process and helps you actually document the information and decisions you make during threat modeling.
Next, I would like to talk about another topic: code scanning. You want to scan your code and repositories and perform software composition analysis, right? I believe most of you, and most of your teams, are leveraging these tools in development. I am going to talk about Amazon Kiro and Amazon Inspector, and how these tools can help you execute your AppSec process.
Let's start with Kiro, our agent-based IDE solution. This is an example of the easy button that Pat mentioned earlier. Kiro can help your builders and developers write code and be more productive. You all know this already, right? But it can also help with code scanning execution, security testing, and security analysis of code. It stays where the developers are; it really stays with the developers. I talked about the easy button earlier; developers use IDEs to develop code. So why not include these tools as part of the IDE so they don't have to open another process, another screen, or another window to follow the AppSec process? To make it easy for the developers.
Next, I would like to show you Kiro in action. I want to show you a short demo on how you can leverage Kiro for AppSec. Before we get into the demo, I have a simple question. Who here likes french fries? Please raise your hand if you like french fries. That is great, I like french fries too. I probably need to cut down on how much I eat, but I am a huge fan. If I wasn't a security engineer, I probably would have opened an online french fry shop. So, I did that for this demo.
You can see the Fry Factory here. It is my online shop for selling french fries. We have various types of fries here. There are classic fries, but also cheese fries. Truffle fries are actually my favorite. Since this is an AppSec talk, if you go to the My Order section, you can see that with a simple SQL injection query, you might be able to get sensitive information. This is very sensitive information about previous orders: the amount of salt, the crispiness, and how much ketchup was in each order. So, this is something you probably want to investigate and protect.
Now, let's quickly move to the source code. This is the IDE I mentioned, Kiro. Looking at the source code for the Python app, you can see it is using Flask. And there are some dictionaries representing the database. If you look further down, there are also some hard-coded credentials. So, I think you can all agree at this point that this app is a bit vulnerable. Now, you can use Kiro to mention these issues, or ask Kiro to perform a security scan. That is fine. But, I would actually like to show you something a bit more advanced from a different angle.
We are going to use Kiro's customization documents. Kiro's customization documents help you define prompts. These can include standards, security requirements, templates, etc., and can be reused across different projects or throughout the organization. If you go to the Kiro folder and open customization, you will see various files. First, there is a file that helps you define documentation standards. That is how the documents should look. This is how we want to structure all project documents. Another example is threat modeling. Earlier, we discussed threat modeling and how we can automate it. Here, we can actually use STRIDE, and I want to use these risk scoring metrics, these considerations, and this template.
Another example I want to show you is security standards. This might be the most relevant one this time. Here is a document defining our security standards. As you might notice, sections 2 and 3 are directly related to the security issues we noticed earlier. There is secret management. We know we aren't actually saving secrets in a secure place. We also saw hard-coded credentials. And there is also injection prevention. This is an example where we can actually perform a SQL injection on the sample app. This customization document can be incorporated into Kiro to help you perform fixes.
That is fantastic. I actually want to go one step further. We will use Kiro agents. Kiro agents help you define different agents with different roles. The input to these agents can be those customization documents. You can see there is a threat modeler agent here. It conducts threat modeling using STRIDE. Your role is to analyze the application and identify security issues.
Agents actually define the actions allowed for these agents, the specific actions that this agent can perform. It is also pulling in the same steering document I showed you earlier as a resource. This allows you to perform threat modeling easily.
Let's move on to the security scanner. There is another agent dedicated to performing security scans. This agent also has a prompt saying that it is performing SAST scans and needs to run security scans on the project. It is pulling in the same resources I mentioned earlier, but this time it also includes tools. I have included ASH, the Automated Security Helper. You can integrate your own tools into agents to perform security operations. ASH in this case is a code security scanning tool available as open source on GitHub. We will share the link for this as well. But what I want to convey here is that with the power of Kiro agents and MCPs, you can create a truly end-to-end integration by using business context, security standards, security requirements, projects, and the roles and prompts you are actually running on the agent.
Utilizing Amazon Inspector and Scaling: Distributed Ownership through the Guardians Program
Now, let's see how it works in practice. We will call the agent to run a security scan. Since it already has the context, we don't need to provide additional guidance. We will call the security agent we defined here. The MCP is loaded, and I will run a security scan with a simple prompt.
It takes a little time, but eventually the scan runs, my tool is triggered, and it provides a context-aware security report based on our security standards, the agent's guidance, the results found in the repository, what the tool found, what I instructed in the prompt, and our security standards and instructions. Here, you can confirm the secret management and SQL injection issues as well.
Next, I really want to take this to the next level. You can open and check the report, share it with developers, or let developers review it. But I can go even further and use Kiro again to take this report and provide specific actionable items that need to be run against the code repository. When I do that, it takes a little time again. It will probably take a little time, but eventually, you can see a report showing what the specific issues are, what needs to be fixed, and how you can implement it.
This really connects to the same easy button Pat mentioned earlier, and we will continue repeating this concept. Make sure you make it easy for developers. I want to show you another example of an easy button, another tool that helps you execute security in your organization. This time, it is Amazon Inspector, our vulnerability management tool. Amazon Inspector can integrate with various AWS accounts and run scans against containers, compute resources, and code repositories. This is truly an easy button, because we aren't asking developers to do anything special. You can integrate Amazon Inspector with GitHub or GitHub repositories and have unified visibility into security issues across the entire organization.
Let's actually do it. This is the Amazon Inspector console, and I will go to Code Security. I have already integrated Amazon Inspector with a GitHub repository, and it was done in just a few clicks. I will create a new scan configuration. There are several parameters I can change here. For example, how often I want to run the scan. I will leave it as default. It runs weekly and on every push commit to main. I can also select various security scans, so I will stick with Infrastructure as Code scan, Static Code Analysis, and Software Composition Analysis.
You can really filter which repositories you want to run the scan against. I will run it against all repositories here.
Now, in this case, it will be executed in the next weekly period. I think I selected Monday here, so instead of waiting until next Monday, I can run an on-demand scan. A few minutes after running the on-demand scan, you can check the scan results, and you can see a detailed full report of the security issues. Since I scanned both code and packages, I can find different types of findings.
Here, you can see an example of hard-coded credentials, showing specifically what the problem is and how you can fix it. Next, there is another example of a package vulnerability; in this particular case, it shows which version it will be fixed in. So, Amazon Inspector is a very easy-to-use tool, and I hope it will be beneficial to all of you.
After explaining some execution steps, I showed you how to use Kiro and Amazon Inspector, and we discussed threat modeling and how to scale it. Of course, you can scale with Amazon Inspector and Kiro as well, but I want to dive deep into scaling mechanisms. First—and Pat mentioned this a bit earlier—we want developers to think about security. Here at AWS, developers are focused on shipping and delivering new amazing features and products, but all of them are thinking about security. Everyone has security in mind, and you can measure that security. We have various programs for secure development, which we will share later.
Make sure that developers recognize the importance of writing more secure code, and make it easy for them. Make it easy with various tools and automation, and do not make it harder to write more secure code by adding another step. One example: if there are solutions or processes that developers need to follow, it would be a good idea to create reusable artifacts they can utilize. For example, if there is a standard for how authentication should work within the organization, don't try to reinvent the wheel every time; have a package for authentication ready that they can import into their projects, which already includes the security requirements and standards they need to follow.
If you know what a three-tier web application should look like, provide a reference architecture. Provide Infrastructure as Code templates. By having environments already built with security controls embedded, it becomes easier for them to start building. Another point is to ensure they have autonomy in decision-making. Don't let development teams constantly depend on the security team. The security team is usually centralized and can become a bottleneck. We really want to enable development teams, product teams, and builders to make security decisions. I want to give an example here as well.
At AWS, we have a Guardians Program. Has anyone here heard of the Guardians Program? Yes, one person raised their hand. The Guardians Program is a program we have internally. There are already some public resources available as well. We bring together developers and builders from different product teams and train them on security. They act as security guardians for their teams. These team members know their teammates the best, know the products the best, and understand the team's business goals, but they are also trained on how to implement security, how to perform threat modeling, and how to follow centralized security teams and security requirements.
This has really helped speed up our security and AppSec processes because these security guardians are helping product teams execute threat models, helping guide documentation, and helping implement security controls. We still have a centralized security team. We need to perform penetration tests and obtain sign-off from the centralized security team. However, having a security guardian on the team ensures you get everything you need, and it can really make this process smooth.
Conclusion and Introduction to Practical Resources
We have really touched on the different phases of building an AppSec program in an organization. We started with planning. There, Patrick showed examples of how to define goals, how to define metrics, and how important it is to measure success before you start executing the program. You define what success looks like. Next, in the preparation phase, we touched on how to communicate with stakeholders and how to train the team. We saw an example of an email where changing just a few words and sentences made a huge difference.
Then we discussed execution. We saw threat modeling, what questions you need to ask, what you need to collect, how you can use Kiro steering documents, and how to use Amazon Inspector and code repository integration. And we discussed scaling. We talked about creating reusable artifacts whenever possible, we talked about the Guardians program, and we talked about distributing ownership to product teams.
Now, if there is one big point that I want you to take away from this talk, it is to "make it easy." Do not make AppSec difficult for your teams. Integrate it into the process. Make it easy for your teams to run code scans, get results, and ensure they are following security requirements. Work backward from the development teams, and make sure you integrate security requirements into their processes.
We promised some resources, so I will introduce the resources we discussed today. If you want to learn more deeply about how to perform threat modeling, please check out the threat modeling workshop. There is Threat Composer, an open-source tool I mentioned earlier, which you can use to perform threat modeling against your applications. ASH, Automated Security Helper, is an open-source tool for code security scanning, an example of which I showed using MCP agents. And you can take a look at the Security Guardians blog if you want to hear and learn more about the Guardians program.
I truly hope this session has been helpful to you. We will be here after this if you have any questions, so please do fill out the survey. It is very important to us. Thank you very much.
- This article was automatically created using Amazon Bedrock while maintaining information from the original video as much as possible.
Discussion