AWS re:Invent 2025 - Staying Ahead: Smart Strategies for Effective Vulnerability Management (SEC316)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Staying Ahead: Smart Strategies for Effective Vulnerability Management (SEC316)

In this video, the Amazon Inspector team presents comprehensive vulnerability management strategies for cloud environments. Rick Anthony, Anthony, and Nirali demonstrate how Amazon Inspector provides automated, continuous scanning across EC2, Lambda, ECR, and code repositories (GitHub/GitLab). Key features include hybrid scanning modes combining agent-based and agentless approaches, the Amazon Inspector score for intelligent prioritization using vulnerability intelligence from Recorded Future, and near real-time malicious package detection through OpenSSF partnership. The session showcases code security capabilities that shift left in the development lifecycle, scanning for vulnerabilities in third-party dependencies (SCA), first-party code (SAST), and infrastructure as code. Demos illustrate malicious package detection, container-to-workload mapping, and native GitHub integration that embeds security findings directly into pull requests, enabling developers to identify and fix vulnerabilities without switching tools.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: Challenges of Traditional Vulnerability Management in the Cloud

Good morning, everyone. Welcome to SEC 316. I am Rick Anthony, a senior manager for the Amazon Inspector team. I'm here with Anthony and Nirali. They'll be speaking to you later, and we're going to talk to you about Amazon Inspector and strategies for vulnerability management. So here's a quick agenda for this morning. We're going to talk about some of the challenges of traditional vulnerability management. We're going to talk about what Amazon Inspector is, how it works, and what some of the key capabilities are. We'll show you a couple of demos and talk to you about one of our newer features, code security.

First, let's discuss the challenges with traditional vulnerability management. A lot of traditional solutions haven't been built for the cloud, and one of the superpowers of the cloud is that it's elastic. Resources can be scaled up or scaled down to meet your needs, and there are many different types of compute that you can use as a customer. You can use virtual machines, containers, or serverless, and you want to be able to cover all of those with your solution. Some of the environments that your developers are going to create can be really complex, and that also leads into resource constraints. How do you know what resources are out there and running if they're going to be that dynamic?

Some of the traditional solutions also ask you to license each of your resources. Well, how do you do that when all of your resources are going up and down? How are you also ensuring that you're seeing all of them if you're only scanning periodically? Once you do scan, you end up with a lot of findings. If you scan on Monday, you generate 1,000 findings. If you scan again on Tuesday, you have another 1,000. How do you deal with all those findings? How do you prioritize the findings that you're getting? You could use some simple methods. You could look at the severity and start with the criticals, but increasingly there are a lot of critical vulnerabilities out there, and they may not be the most important ones for you to remediate based on your environment.

Amazon Inspector: Automated and Continuous Vulnerability Management

This is where Amazon Inspector comes in. We launched Amazon Inspector a couple of years ago, and we created it to be an automated vulnerability management service that continually monitors your workloads for software vulnerabilities and unintended network exposures. You can see that we've highlighted two really key features of Inspector right here. One is automated, and what this means is that once you enable Inspector and configure it, it does all the work for you. You don't have to manage it or tell it what to do. Number two is that it continually scans your resources. So in that dynamic cloud environment, as resources come up, Inspector sees them, scans them, and as resources go down, Amazon sees that and automatically closes findings for you. You don't have to manage the service. It does it for you.

Our goal is for you to worry about remediation and taking action, and that's it. When we launched Amazon Inspector, we launched it with support for virtual machines through Amazon EC2, container images through Amazon ECR, and then we added support for serverless functions through AWS Lambda. Most recently this year, we also added support for managed code repositories through our interactions and interfaces to GitHub and GitLab. So here's a quick overview of Amazon Inspector. When we talk about Amazon Inspector and how you use it, we really talk about four different phases. Phase one is enablement, and this is when you, as a customer, go in and turn Amazon Inspector on either for your account or for your entire organization. You can do both. Second, once you do that, Amazon Inspector will start looking at your environment. It will discover all your resources and scan those resources to get an initial set of findings so that you know where you are in terms of your exposures. Then it'll start monitoring, so as changes take place, Amazon Inspector follows suit. The third phase is looking at your findings. Inspector will contextualize your findings so that you can prioritize what's important. Severity is not the only critical thing.

Some resources are exposed to the Internet, while others are not. Some have vulnerabilities that can be exploited, while others do not. Inspector takes a lot of different pieces of information together to give you a prioritization score that you can use to take action. Taking action is our fourth phase, where once you have your findings, you need to decide where you want to do your work. You can do your work in Inspector, you can do it in Security Hub, and we give you lots of different options. We're going to dig into each one of these quickly.

Enablement and Discovery: Organization-Wide Deployment and Real-Time Monitoring

First, when you turn on Amazon Inspector, you can enable it for your account or you can enable it for your entire organization. We see most of our customers turning on Inspector for their entire organization. What they do is use their management account to assign a delegated administrator. From that delegated administrator account, they can tell Amazon Inspector what to scan and based on what settings. We also provide a way of automatically enabling Inspector for all new accounts added to your organization. The power of that is once you get it set up, if you say turn it on for all new accounts, you no longer have to worry about having gaps in coverage. Inspector will enable itself automatically.

Secondly, that delegated administrator account not only configures your entire organization, it also has visibility into your entire organization. As a user within the delegated administrator account, you have a centralized view of all your findings regardless of account. As a customer, you can manage all your findings for your organization from that one view while your individual accounts still have visibility into their own findings. If you create a ticket to one of your teams saying they have this vulnerability, they can go into Inspector and they'll see the exact same details that the delegated administrator sees. We launched with this capability when Inspector launched a couple of years ago, and we also upgraded that capability to do organization configuration enablement through support for organization policies that just launched this year.

Phase 2 is the discover, scan, and monitor phase. This is where Amazon Inspector, when you turn it on, sees all of your resources. If you ever want to know what your accounts are running, what the resources are, and what they look like, Amazon Inspector knows. It sees these resources as they launch and sees these resources as they terminate, and it updates accordingly. We support EC2 instances, container images in ECR, Lambda functions, and now managed code repositories. Inspector works in near real time so that as changes occur, you get those findings right away.

Amazon Inspector is also intelligent. We talked about one of the challenges of traditional vulnerability management where you as a customer have to decide when you're going to scan. You don't know if you're catching everything. Inspector monitors your environment and scans when it needs to scan. If a new resource is launched, Amazon Inspector scans it. If you install a new software package on a resource, Amazon Inspector scans it. If you patch, Amazon Inspector sees that patch, rescans, and if the findings for a vulnerability are now remediated, it will close those findings. If there's a new CVE published, Amazon Inspector knows which of your resources have that package and will automatically rescan so that at any point in time you can go to Amazon Inspector and know what your security posture is at that moment. You don't have to do any work to get there.

Contextualization and Prioritization: Amazon Inspector Score and Malicious Package Detection

Then phase 3 is contextualization of those findings. Amazon Inspector supports what we call the Amazon Inspector score, and this tries to answer a whole bunch of questions that you have. One question may be, what is the most severe vulnerability that I need to remediate? Is it for a resource that's exposed? Does that vulnerability have an exploit? Is that exploit common in the wild? Amazon uses all that information in order to score up or score down your vulnerabilities so that when you look at the Amazon Inspector score, you're truly looking at the most important things for you to fix within your environment. We do this using a bunch of advanced vulnerability intelligence information that we partner with Recorded Future to gather.

As a security professional, you can go in and see how a vulnerability is mapped to MITRE ATT&CK TTPs, whether there is a known CISA exploit, if there is a malware kit for it, and whether it is commonly exploited in the wild. This allows you to double-check and make your own decisions about what you want to remediate first.

We package all of our vulnerability information into a format where you can search it for yourself. You can look at CVEs and know whether Inspector supports the CVE and what the details are. You can check if it is a high or low severity finding, see what type of resources it impacts, and immediately know which of your resources are impacted by this vulnerability.

A couple of years ago we did a talk very similar to this one where we had a customer join us from Volkswagen Financial Services. They are a user of Inspector, and the speaker Crispin talked about receiving a call from his boss on a Monday morning as he was commuting to work. His boss said, "Hey, I just read about this brand new Windows vulnerability. It looks pretty severe. Are we impacted?" Crispin said that sitting at his desk, he was able to go into Inspector, type the CVE number, see that Inspector supported it, and because Inspector had already scanned all of his resources in near real time, he was able to identify every account and every resource that was impacted. He was able to email a note out to all those owners to perform remediation within 14 minutes because all the information was fresh and at his fingertips. That is the power of near real time and always knowing what your posture is.

One of the new pieces of information that Inspector reports on, which we are really proud of and excited to talk about , is near real time malicious package detection. Through a partnership with the Open SSF, we now pull in malicious package information and use that to determine whether you have packages that are malicious and whether these will cause some unknown or unwanted behavior within your account. We are not only using the information from Open SSF, we are contributing as well. In fact, right now we are one of the largest contributors.

Earlier this year we started scanning NPM registries. Through a set of our own specialized detection rules that are a combination of static, dynamic, and AI rules, we are able in near real time to detect malicious packages. We post this to OpenSSF, they assign a malware ID, we put this into Inspector immediately, and we begin reporting on this within your own environments. We published a blog a couple of weeks ago where using these techniques we found one of the largest campaigns to do tokenization farming that we think ever occurred. We detected over 150,000 malicious packages in NPM registries. It is a great blog article, and I encourage you to go out and read it. We are really excited about this program, and this is something that we are going to expand into other forms of registries.

Taking Action: Findings Management and Software Bill of Materials

So let me spend a couple of minutes to give you a quick demo of how this would work. One of our security researchers put together a Dockerfile where he installed a known malicious package called @anhackle/test. As a note, please do not repeat this. This is actually a real malicious package. He built the Dockerfile, he pushed it into the ECR registry. ECR is one of the formats that Inspector supports. Here you can see within this account we have Amazon Inspector running. We have scanning for ECR enabled. This is the repository where the file was pushed, and here you can see we have detected that malware package automatically in near real time.

Obviously, we've accelerated this for today's demo, but along with the information for this malware finding, you can see we've detected other CVEs as well. As a customer, there's a lot of different information we provide you, so you can either feed it into other systems or just review it yourself. Here you can see this has an Inspector score of 9.8, sourced from OSSF. This is something we detected. The version of the package and where this package lives are shown, and if you want to look up more information, we give you a reference so you can verify that this was truly a malicious package published by OSSF. Here this is credited to Amazon Inspector as the finding.

Our fourth phase of using Amazon Inspector is taking action with findings. Within Amazon Inspector, using that delegated administrator account, you see the findings for your entire organization. You can operate directly within Amazon Inspector. You could send your findings into Security Hub as another one of our tools to help you focus on your remediation efforts, but you have other options as well. We send our findings out to EventBridge so you can hook those up into other systems using Lambda functions. You can have partner applications that pull in this data, or you can look at it in some of our other services as well. As an example, Amazon ECR will also show findings for your container images.

Finally, another way of looking at your data and taking action is through software bill of materials. With Amazon Inspector, at any point in time you can say to Inspector, please export SBOM for my environment, and you can choose your account or your organization. You can filter the data any way you want. We support SBOM in CycloneDX format and in SPDX format. Once you have that data, there are many different ways you can slice and dice it. You could send it into Amazon Athena to do different types of queries, or you could send it into QuickSight. The SBOM data is free of charge, and you can do whatever you want with it.

Continuous Monitoring Capabilities: EC2, Lambda, and ECR Scanning Modes

I'm going to hand off to Anthony, and he's going to talk about some of the other capabilities of Amazon Inspector. Thank you. Can everyone hear me okay? Great. My name is Anthony, and I'm a product manager for Inspector. I work closely with Rick and Arai. My purpose in this section is to give you an overview of how you as a customer can use Inspector as a product to meet those effective vulnerability management use cases that Rick talked about. Hopefully, as an objective of this section of the presentation, you'll have a deeper understanding of how to use Inspector to start this journey of setting up Inspector and working through these problems.

I'd like to do a quick poll: how many of you are already using Amazon Inspector? Great, so quite a few people here to learn about how to set this up and use this product. Before I get going, I wanted to touch on where we are in the overall lifecycle of developing and launching products and managing software vulnerabilities. The section I'm going to focus on here is really monitor and respond, as well as some components of build and test. The core capabilities of Inspector are really monitoring and providing you that visibility with near real-time visibility on those resources and those findings so that you have an accurate understanding of your security posture.

But as a customer, what you really want to do is start shifting left. I'm going to focus here a little bit more on what we do today to help you in this monitor and respond area. This slide is going to be our map, which will help guide all the capabilities I'm going to talk to you about and will help orient you as we go section by section through each of these. As a mental model, there are really two different groups of capabilities as I like to think of them for Inspector. There's continuous monitoring, which provides that real-time ability into those resources and covers EC2, Lambda, and ECR images. Then we have some additional utility capabilities I call ad hoc, which include managing SBOM, CIS benchmark scanning, and some other tools that help you shift left in build and deploy.

Before I get started with that, I wanted to take a second to talk about and underline the importance of continuous scanning. The purpose of continuous scanning is that essentially the goalposts are always moving in security.

I have a simple illustration to show why scanning today, tomorrow, and two days from now helps you understand when you need to take action. Imagine a scenario where on January 1st, you have 10 packages that inspectors are detecting, but inspectors are not finding any packages associated with a CVE, so there are no findings. Ten days later, on January 10th, a new CVE is published for a package, but that package is not in your ECR container image. However, on January 15th, a new CVE is published and we observe that the package is associated with a vulnerability. At that moment, we cut a finding to you, and you have a finding which you can choose to react to or not react to depending on your risk appetite.

This is really important to illustrate that it's an ongoing job to understand your security posture. The information that Inspector provides informs what you as a customer need to do to take action to secure your environment. I'm going to jump to EC2 scanning. I'll cover EC2 scanning, Lambda, ECR image scanning, and then touch on ad hoc functionality. There are a few key points to understand about Amazon EC2 scanning. An EC2 instance is obviously a virtual machine, and one of the key decisions you have to make as a customer, hopefully as the Inspector delegated administrator across your entire organization, is what kind of scanning mode you want to implement across your environment.

There are two different modes from which you can choose. You have an agent-based approach which uses the AWS Systems Manager agent, the SSM agent. We like to use the term ubiquitous to describe it, and it's meant to be as easy as possible to install across your fleet. When the SSM agent is installed and operating correctly on an EC2 instance and you enable EC2 scanning, Inspector will use the SSM agent and a small piece of technology that we have to execute those scans, do the work, and then cut the findings to you via the Inspector service. There are some capabilities within Systems Manager that you can also leverage to have a full view across your entire AWS organization for every single EC2 instance that will tell you whether every single EC2 instance is being managed by the SSM agent and if not, why not. There are also tools that help you diagnose and remediate common operational issues with that.

Now we have a second scanning mode which we call hybrid, which came after our agent-based approach, and this is actually what we most recommend to customers and is the default experience for new customers. In the hybrid experience, we scan using the SSM agent in the agent-based approach if the SSM agent is there. If the SSM agent is not there, we use an agentless scanning approach. The benefit of this approach is that you can effectively ensure that you have close to 100 percent coverage across all your EC2 instances. There could be operational challenges with managing an agent or getting that agent deployed. In our agentless technology approach, we use EBS snapshots, and an important note here is we'll never take that data outside of your account, which could be a compliance concern for certain customers.

If you're going to take one thing out of this talk in terms of turning on EC2 scanning for Inspector, use hybrid. It's really simple to set up, and I'm going to show you that in the demo. You should get full coverage across all your EC2 instances. I just want to touch on a couple of other points about EC2 scanning for Inspector. The first is that Amazon Inspector has network reachability analysis, so it uses automated reasoning to determine whether or not a VM or an EC2 instance is reachable via the Internet. This is an important indicator because it will help you prioritize those findings that are generated in Inspector.

We use the network reachability score based on our analysis to inform the Amazon Inspector score, which is our proprietary scoring that takes the base score from the vendors and our vulnerability intelligence information, and then overlays information like network reachability to provide you a better indicator of the actual security risk for that specific finding on that specific EC2 instance.

The next capability is Linux deep inspection. As a customer within an account operating as the delegated administrator, you have the ability to specify custom paths that SSM or Inspector will analyze and look for software vulnerabilities as well as application programming package vulnerabilities for those specific paths. If there's a specific structure that you have in place for your developers or the people managing your infrastructure, you can configure Inspector to scan those paths specifically, and Inspector will provide a higher volume of findings for those paths.

Lambda Code Scanning, Enhanced ECR Image Scanning, and Ad Hoc Utility Features

I'll return to my map and move on to the next capability, which is Lambda scanning. Lambda scanning has essentially two modes. The first is Lambda standard scanning, which scans for package vulnerabilities, and the second is code scanning, which scans for application code vulnerabilities. As a customer, you have the ability to either turn on standard scanning for an account or standard and code scanning for a specific account. You cannot have code scanning without standard scanning. Standard scanning works similarly to VM scanning where we look at those packages and cut findings for those CVEs.

Code scanning analyzes that code and looks for things like injection flaws, data disclosure, or weak cryptography. With our continuous scanning approach, we scan when new resources or in this case functions are detected, new versions are published of the Lambdas, or when we have new information in our database that tells us we should reevaluate those Lambda functions. From a remediation perspective, for standard scanning package vulnerabilities, we tell you what package you should upgrade to, which is pretty standard. For code scanning, we highlight the vulnerable lines of code specifically in red, and then we provide an AI-generated snippet of how you can adjust that code to make it more secure.

The third main resource type that Inspector scans for are Elastic Container Registry images. Inspector scans images and not running containers. As a customer, ECR out of the box allows you to turn on Inspector basic scanning, which scans OS vulnerabilities only and scans those images when they're pushed into the repository. This is an on-push action only, so it effectively does not have continuous real-time monitoring. We provide light vulnerability intelligence about those OS vulnerabilities when we cut those findings, which are then visible in Inspector.

Enhanced ECR image scanning is our Inspector-level capability of continuous ECR image scanning. It scans OS vulnerabilities and programming language packages. As a customer, you can configure scanning on push, but you also have the ability to control which images you want to monitor based on their pull or last in-use date. The reason this is important to know in terms of how you're setting up and using Inspector is that you won't necessarily want to scan every single image in the repository, as that may be an operational challenge for you to manage. However, you can use these settings to control which images are actually getting scanned based on those dates and metrics. These are the controls you have to manage the volume of those findings. For enhanced scanning, we also provide the full suite of vulnerability intelligence like we do for all the other continuous monitoring capabilities.

I want to touch on a few other components of ECR image scanning. The first is that earlier this year we launched a feature that enables you to map the image to running containers, so we're actually looking at EKS and ECS information to tell you how many pods or containers are running a specific image.

This is important because as a customer, if you have a finding or a variety of critical findings on a specific image, you may or may not want to prioritize those findings based on the number of containers that are actually using the images. That level of visibility will help you prioritize, and in the demo in a few minutes, I'll show you what that looks like in the console. Lastly, we're always expanding the ecosystems that we're scanning and generating vulnerabilities for. Just a few examples are WordPress and Tomcat, and we continue to expand on this based on customer demand as well.

The last thing I want to cover are some of the ad hoc functionality related to additional utility capabilities that we provide you as a customer for Inspector. I walked through some of those continuous scanning capabilities. As a customer, you can change some of those settings to control how you're actually using Inspector to meet those use cases, but we also provide some other capabilities that you can use as part of your effective vulnerability management strategy.

The first of these is what I'm loosely referring to as manage SBOM. As Rick mentioned, you have the ability to export an SBOM that Amazon Inspector is detecting because we're actually monitoring those resources in near real time. You have the ability to export those, but you also have the ability to use our Scan SBOM API, which takes an SBOM as an input and generates findings in Inspector based on that actual SBOM. That's really the evaluation of the SBOM, but you can make that API call yourself, and that can give you some flexibility in terms of how you use the intelligence and the capabilities of Amazon Inspector. The SBOMs are in CycloneDX and SPDX format.

The second capability is CIS benchmark scanning for EC2. You can execute ad hoc or schedule scanning of EC2 instances against CIS Benchmarks. You can use tags on this. This is not quite as real time as our other capabilities, but in terms of this use case, we believe that this meets customer needs. You can view those results. Certain customers in certain industries are going to need this more than others, but again, this is a piece of capability that you have the ability to use.

Lastly, we have a few CI/CD integrations. You can see here an example with Jenkins, but you can use popular CI/CD tools to orchestrate the integration of the SBOM generation and Scan SBOM to meet use cases like scanning container images before you push them to a registry. You can use these tools to bake into your operational development process, and this is part of your journey to shift left. We'll be talking more about that in a few minutes.

With that, I'm going to show a demo where we'll walk through some of the console to show you where to go in Inspector and how to leverage these capabilities and how to control them. This page here is account management. As a delegated administrator, what you have the ability to do is see this grid of all the different accounts in your organization and which capabilities are turned on, and you can granularly control which ones to turn on or not. In this example, you can see this account with all sixes. It doesn't have Lambda scanning enabled, but I was able to simply click that and turn on and activate Lambda standard and code scanning.

In account management as well, we have this coverage. You can see resources coverage on the left. It's going to fire through some of these screens, but effectively, across your entire organization, what is every single VM that's being scanned or not scanned, and then I can drill in and see those details about those resources themselves. You can see we have the same thing here with Lambda functions and also container images, so we're decorating that information so that you have an understanding of what's actually being covered or not. The key point there being you cannot manage what you cannot see.

And then we just have some other information here in the console showing why something is not being scanned, which would be relevant to understand from a security perspective or if you're reporting to your managers. You can see here also I'm just firing through the SBOM export, so Inspector is continuously monitoring all those resources. You have the ability to simply decide which resources to generate the export the SBOM for, and then you can put that in the S3 bucket or not.

This page here shows our EC2 scanning settings. I talked about the hybrid mode versus the agent-based mode, but it's straightforward to go to the console, click the EC2 scanning settings, and then turn on hybrid scanning. At that point, inspectors are going to start doing the work to detect all those other resources and use our agentless technology. The last real control you have, which I mentioned, is a major piece of control for container image scanning. You have the ability to determine when an image is going to be re-scanned or enter scanning eligibility. You can do this by choosing either a last in-use date or a last pull date plus a push date, so you can use those dates to control the images that are eligible for scanning. Lastly, I'm showing here the vulnerability database search. We're decorating the findings with the information here, but if at any time you want to do research about a specific CVE, you can simply type that in. We'll provide all the information here about the finding as well as any other intelligence that we have to help you understand more about that vulnerability.

This will be a quick minute demo. I'm going to show you what the container image to container mapping capability is. You can see here I drilled into some critical findings for container images. I'm here in the dashboard and I drilled into some of the findings for this particular image. I'm here on the container image. You can see I have a variety of findings here, many findings. I can go view those findings if that makes sense, so I have visibility into what those findings are for this specific resource. Then you can see here there's a hyperlink to the deployed ECS, EKS tasks, and pods. I can see the workload name there, and then I can simply click into that workload and explore all the details about that, where I'm actually using that, which is in ECR itself.

I gave a quick overview on basically how to use Inspector to meet some of those use cases. There's plenty of additional content to help you do that. More or less, you want to be able to set up Inspector to start doing that scanning and play with the controls as an administrator on how to actually use Inspector to start that vulnerability detection. And with that I'll pass it to Nirali.

Shifting Left with Code Security: Scanning GitHub and GitLab Repositories

How many developers here in the audience? A few, good. Actually, more than a few. I like to start talking about code security from the perspective of this iceberg image. What we talked about so far in our journey was the tip of the iceberg. Everything that a security person gets to see when their workloads or images are running in production. Oftentimes, it is harder to patch these running environment workloads in production. The challenges are what's not visible, which is underneath the surface, basically under the water. Our developers are iterating and writing code on a daily basis with a sprint to make changes, oftentimes not knowing what security vulnerabilities or exposures that they may run into.

Let's take an example. Business wants a brand new feature that's going to change the world. Product managers and business owners are working on defining it. Your customers are eagerly waiting for that. Developers have actually worked weeks and weeks trying to write code to get that ready for launch. Monday morning, the launch is set to go, and before you hit the green button, you discover a new critical vulnerability. You're now faced with a decision point. What do you do? Do you actually hit the button and launch it, or do you actually scale back, go back, fix the vulnerability, and delay the launch? How many of us have actually run into that scenario where you've had to make that decision? Sounds familiar? I wish there was a way for developers to know earlier that what I'm writing has these vulnerabilities, has these critical vulnerabilities, so I don't have to wait all the way until Monday or Saturday or Sunday to discover them. That's what code security is doing, throwing light underneath that water surface to be able to catch vulnerabilities early in the development process.

Production workloads have vulnerabilities that you have to patch with high urgency. However, what lies below the surface is all the code that your developers are writing, along with dependencies on open source packages that may have vulnerabilities you may not be aware of. Your infrastructure also contains code—infrastructure as code that you're writing to scale your infrastructure—and you want that to be secure before you actually scale up in production.

We started this journey with Inspector all the way to the right, where we started to monitor everything from EC2 instances, Lambda functions, and the images that are used to bring up your pods and tasks. We introduced an ability to build and test with your CI/CD pipeline. However, you told us that wasn't enough. Using the same iceberg analogy, you need to start catching these vulnerabilities early. It's very expensive to patch and fix vulnerabilities in production, and often you cannot even touch them. You own that risk, and we want to allow you to balance it. So we're further shifting left based on your feedback.

Let me give you an example of why this is important. How many of you here know about Log4J or Log4Shell? The graph shows the downloads of vulnerable Log4J since January 2021. Even today, it's been around for over four years. It was detected in December of the previous year, and even to date, 30 percent of the downloads that happen are vulnerable. We often push that code to production and then have to go and patch it as security owners. It's very important to catch this early enough so we don't need to worry about fixing and patching things in production.

That's why we further shifted left in the development cycle to catch vulnerabilities not only in your third-party dependencies of open source packages that developers are using or pulling, but also in your first-party code, which is your proprietary code that you're running. We're scanning right where your developers are working and iterating on your code, with native integration into GitHub and GitLab repositories. It's very expensive and costly to find these defects further down the line, so we're shifting as far left as we can to meet your developers and allow them to do security from the beginning.

Regarding what is part of code security and what we're going to scan: we'll integrate with your GitHub and GitLab repositories and expand our capabilities. Inspector natively detects third-party open source package dependencies and vulnerabilities in your compute environment. We're expanding the same capability—software composition analysis—further left. In your GitHub or GitLab repositories, if your developer is using third-party or open source packages that they've pulled into your codebase, we'll scan them to detect vulnerabilities early as they write and iterate the code.

We understand that even though 80 percent of your code may still be open source and source code analysis is important, you still have proprietary first-party code that you write, and it's important to scan that as well. We're expanding the capability from not just supply chain or SCA capability; we're also adding static application security testing scans, which scan for security vulnerabilities in your first-party code. Additionally, we typically use infrastructure as code to scale our environment. Making sure that your IaC configurations and files are secure inherently before you use them to scale your cloud environment is very important. No different than scanning the rest of your repository, we will also scan your IaC files—Terraform, CDK—using the same mechanism to find security flaws such as hardcoded secrets and other detectors built into it.

Now, we often talk about security personas wanting to implement guardrails. But from a developer persona, it is very difficult to follow through and always adhere to those guardrails. Oftentimes it comes late in the system where a developer is frustrated with a security person to get that finding generated much later in the development cycle. We talk about DevSecOps, which has been around for a very long time, but in reality, it is very hard to implement that entire DevSecOps journey unless you natively embed and bring the culture into the developers' workflows.

So with code security, we are adding an improved governance model. What do I mean by that? Typically, a developer will work in their own environment, write code, go through the sprint, and at the tail end of the sprint, they will get to know about the vulnerabilities. There will be a bunch of back and forth, they will have to go fix, negotiate with the security person, fix the critical ones, and then move on. But what if I told you that with this capability, we are going to change the governance model where we are natively embedding security within the workflows of the developer tools without them having to switch tools or even go to the security persona to look at what the findings are.

So instead of the developers having full freedom to just iterate on the code but then find out later and slow them down, we want to give them incremental information as they are doing pull requests, as they are merging code back to main, to show them that here are your top vulnerabilities. Let us go fix them. We give them guidance on what we recommend for fixes as well as they write the code, and here is the guardrail defined so that we can build a culture where security is not a blocker but an enabler for allowing developers to write code fast, be agile with security in their mindset, and write secure code right from the beginning.

All of this can be set by a security persona to set and define the guardrails for what your code should look like before you actually merge into main or before you actually go to production. And within those guardrails, your developer now has unfettered freedom to quickly iterate the code, learn, fail fast, and improve so that overall the business has agility, is able to launch features faster in a secure manner, and you are actually de-risking your entire development lifecycle. The other thing that was very important that we touched upon is you have to meet them where they are.

Developer-Centric Security: Native Integration, Governance Models, and Comprehensive Risk Management

The challenge with some other code security capabilities was that security personnel wanted to go ahead and build out guardrails and build out visibility into the code repository, but the only way to look at it was to come into a security persona's view. So you would have to hypothetically come into Inspector to see what the vulnerabilities look like, and developers often do not want to switch tools. I am writing code in my IDE environment, I push it to my code repository in GitHub, and I am iterating on GitHub with pull requests and pushing back code into my main branch, and I am ready to go, and you are asking me now to switch context, go and find the vulnerability somewhere else.

So it was very important for us to have the experience natively embedded into the workflows where the developer is. So you have both personas. If you are a security owner, you certainly have a centralized view with Inspector to look at all the repositories that you actually have or a subset depending on what is important to you, such as show me the findings only for production environment or anything tagged pink for that matter. So what is important to you, you define and you see the vulnerabilities no differently than how you do with Inspector today.

But if you are a developer, you do not have to leave the tools you are using. You are writing code in your GitHub, as you do pull requests, as you merge the code back in, you will get to see all your security vulnerabilities as comments, as well as recommendations on how you would fix the code. Let us quickly go through a demo. I promise it is a short one and the last one. I am going to wear the hat of a developer, not a very security savvy developer. I just want to move fast. This is my standard Python application. I have infrastructure as code.

As well as a web application with built-in vulnerabilities that I want to show you and walk you through in terms of the scenario. I'm now committing it back to my GitHub environment. It's a standard Flask application designed for demo purposes. It has a bunch of vulnerabilities as you can see, including application vulnerabilities as well as infrastructure as code vulnerabilities that I want to walk you through and identify them within my setup and Inspector. As a security person, the setup is no different than how you would do it for the rest of the environment. You would come in, set up an integration depending on what code repository platform you may have, and set up a configuration integration with GitHub. In my case, we'll also highlight all the default configuration settings that we are recommending. We're going to say go ahead and scan them every time you're doing a pull request or pushing back to the main. You also want to scan them weekly and scan across all of it. Scan across your first party code, third party dependencies, as well as your infrastructure code. By default, go ahead and scan all of it and create this scan configuration for you to be able to know exactly what's happening in your code repository. You certainly can filter out depending on what you may need.

I'm going to go ahead and finish the installation. There is an app that gets installed natively. It will walk you through that entire workflow. What the app is actually doing is allowing and giving you permissions. Read-only permissions so that I can discover all the repositories, and write permissions so that I can put comments on your pull request. The write permissions are only for pull requests so that I can get you comments from security findings directly natively into GitHub.

Let's go back to Inspector. I've now discovered the three repositories that I actually had in my setup. We'll go ahead and quickly look at the findings from the setup in my web application. I have not run any scans right now. I'll go ahead and initiate a scan in my repository and generate the findings. I'll go ahead and quickly just run an on-demand scan because I set it up for weekly scans starting Wednesday. Today's Monday, so the next scan will happen on a Wednesday. We'll go ahead and set the scan up to go see the critical findings that are generated automatically. We'll go ahead and see the findings on my web app that I had written poorly and what those findings are.

It was scanned. I can see the project ID, which is important so that you know which project I actually scanned and what the ARN is and what are the vulnerabilities. If you notice here, I have restricted IAM policies. I also have hardcoded secrets, and I have a public read ACL in my repository, which means I have an S3 bucket with access publicly allowed from the outside in. We'll go ahead and highlight what the vulnerability is and when it was actually detected. This one's a package vulnerability. What are the affected packages? Where, if it is code, where exactly in the code the vulnerability exists as well, and what the recommendations are. Real quick, I'm going to actually make a quick change on my Terraform file. I'm going to add a new feature and commit it back to the main. Then run another scan to see if it generates the finding, and we could do the same on a pull request as well. If you notice the scan commit ID changed, we've generated a new finding. Certainly sort by the age. The finding generated this time has the restricted actions with the principal S3 bucket. I continue to write bad code and I get all the findings. Here are the 15 lines of code that has an issue, and it was all detected.

Now real quick, let's just see what happens when I'm doing a pull request. I am going to continue to write bad code, more things I'm going to add in here. I'm going to have a hardcoded secret. I'm also going to expose with remote code execution if exploited, so just bad practice continues to happen. When I'm doing that, what happens when I do a pull request? The findings actually will get generated automatically within the native tool that I have. There's a pull request. I think it's great code. I'm excellent. It's good to go. Let's just do a pull request and see what happens.

There are no conflicts, and I'm going to start generating all the findings associated with it for me to now realize that the code I've written is actually not very good. Here are all the hardcoded secrets that I need to go fix, as well as remote code execution vulnerabilities that, if exploited, would actually put me at risk. So I can go ahead and make the changes in the code while I'm actually doing pull requests.

Just to summarize, we talked about scheduled scans, on-demand scans, and Git event-based scans, which allows your developers to actually iterate code securely with full visibility and a governance model that allows them both to collaborate together. With all of that, right from the production workloads to scanning right in the beginning of the code repository, we want to make the secure thing the easy thing for your developers and your security persona so the organizations can and should build secure software. To get the speed and agility that we need today, just to summarize the same iceberg, with Inspector for vulnerability management, we're not only just showing you what's in production and the vulnerabilities that are available, but we're also shining light underneath that so you can start early to understand all your code, the dependencies, infrastructure as code security vulnerabilities earlier, fix them in the life cycle.

And then when it comes to security, it's not just about vulnerabilities, right? That's one of your problems. Many of you probably already are familiar with Security Hub. Our original Security Hub is now rebranded as Security Hub CSPM. We have a new platform for security finding aggregation that aggregates findings from threat findings from GuardDuty, vulnerability from Inspector, controls for resources exposures, configurations along with sensitive data from Macie. All of that together has a combined risk score. We'll automatically correlate these findings for you and generate a prioritized risk so that you can take action on what's more important to you rather than just looking at one aspect of risk. This is a combined, correlated, aggregated view so you can prioritize and take action based on what's important, and it already has automated response capability built into it for you to do investigation on all your critical findings.

Lastly, there are additional sessions to go deeper into Security Hub, Inspector, code security, or AppSec capabilities. So feel free to step into one of these code talks, breakout sessions, or workshops to get hands-on. Some important blogs and other useful information on Inspector are available if you were curious to learn more. You guys have been a wonderful audience. Thank you so much. Please use the app to give us feedback, and we'd love to learn from you. Thank you so much, and we can take questions in the back if anyone has any. Thank you so much.

---

; This article is entirely auto-generated using Amazon Bedrock.