Skip to content

Amazon Inspector

Introduction

Welcome to the Amazon Inspector Best Practices Guide. The purpose of this guide is to provide prescriptive guidance for leveraging Amazon Inspector for continuous monitoring of software vulnerabilities and unintended network exposure in AWS workloads such as Amazon EC2, AWS Lambda functions, and Amazon ECR. Publishing this guidance via GitHub will allow for quick iterations to enable timely recommendations that include service enhancements, as well as, the feedback of the user community. This guide is designed to provide value whether you are deploying Inspector for the first time in a single account, or looking for ways to optimize Inspector in an existing multi-account deployment.

How to use this guide

This guide is geared towards security practitioners who are responsible for monitoring and remediation of security events, abnormal activity, and vulnerabilities within AWS accounts (and resources). The best practices are organized into different categories for easier consumption. Each category includes a set of corresponding best practices that begin with a brief overview, followed by detailed steps for implementing the guidance. The topics do not need to be read in a particular order:

What is Amazon Inspector?

Amazon Inspector is a vulnerability management service that continuously monitors your AWS workloads for software vulnerabilities and unintended network exposure. Amazon Inspector automatically discovers and scans running Amazon EC2 instances, container images in Amazon Elastic Container Registry (Amazon ECR), and AWS Lambda functions.

What are the benefits of enabling Amazon Inspector?

Amazon Inspector continuously discovers resources across your AWS Organization. After you deploy Amazon Inspector it will identify and automatically assess your resources for vulnerabilities. Keeping a continuous state of your environment Amazon Inspector understands when resources no longer exist or more importantly when new resources are deployed so that it can begin assessing these resources for vulnerabilities without requiring any manual configurations.

Continuous assessment of your resources including Amazon EC2 instances, images in ECR, and Lambda functions for vulnerabilities so that you are always up to date on the current state of your resources, even as new vulnerabilities are discovered. Amazon Inspector continues to assess your environment throughout the lifecycle of your resources by automatically monitoring resources in response to changes that could introduce a new vulnerability, such as: installing a new package in an Amazon EC2 instance, installing a patch, and when a new common vulnerabilities and exposures (CVE) that impacts the resource is published. Unlike traditional security scanning software, Amazon Inspector has minimal impact on the performance of your fleet.

Amazon Inspector creates a finding when it discovers a software vulnerability, code vulnerability, or network configuration issues. A finding describes the vulnerability, identifies the affected resource, rates the severity of the vulnerability, and provides remediation guidance. Amazon Inspector also provide an Amazon Inspector score that provides context into the severity of a vulnerability. Visit the Inspector documentation to learn more about the Amazon Inspector score. You can analyze findings using the Amazon Inspector console, or view and process your findings through other AWS services.

Integration with Organizations enables you to quickly deploy and see vulnerability posture across all of their accounts from a single location and verify that Amazon inspector is automatically enabled and performing assessments as new accounts are added to the organization. This reduces the amount of effort needs to maintain a ready state of vulnerability management across your AWS environment.

Getting started

In this section we will cover what you need to consider before activating Amazon Inspector in your AWS Organization.

AWS SSM Agent

Although not required, it is recommended when using Amazon Inspector to detect software vulnerabilities in Amazon EC2 instance, the instance is managed instance in AWS Systems Manager (SSM). An SSM managed instance has the AWS SSM Agent installed and running, and SSM has permission to manage the instance. AmazonSSMManagedInstanceCore is the recommended policy to use when you attach an instance profile. This policy has all the permissions needed for Amazon Inspector EC2 scanning. If you are already using SSM to manage your instances, no additional steps are needed for Amazon Inspector to begin scans.

If you have instances that do not or can not have an SSM agent for example because of an unsupported operating system you will still be able to scan them for software vulnerabilities using Inspector agentless scanning also referred to as hybrid scanning mode. Scanning with the SSM agent uses an event driven pattern, for example when new packages are installed on an instance Inspector will initiate an evaluation of the package. With agentless scanning, Inspector scans instances once per 24 hours.

The AWS SSM Agent is installed by default on Amazon EC2 instances created from some Amazon Machine Images (AMIs). For more information, see About SSM Agent in the AWS Systems Manager User Guide. However, even if it is installed, you may need to activate the AWS SSM Agent manually, and grant SSM permission to manage your instance.

In addition to providing the visibility that is needed to look for vulnerabilities on Amazon EC2 instance the presence of the AWS SSM agent provides value for activities such as scheduling automated patching, creating maintenance windows, reporting on patching compliance, providing a mechanism to run automation across your fleet of instances, and provide secure access to instances without the need to expose port 22 or 3389 for remote access to SSH or RDP.

If you're interested in using the AWS SSM agent, refer to the section below on enabling default host management in AWS Systems Manager.

Enabling Default Host Management in AWS Systems Manager (SSM)

Hybrid scanning in Amazon Inspector includes agent-based scanning and agentless scanning. By default, Amazon Inspector uses these scan methods on all eligible Amazon EC2 instances. Agent-based scanning uses the SSM agent to collect software inventory. Agentless scanning uses Amazon EBS snapshots to collect software inventory. By default, the SSM agent is already installed in Amazon EC2 instances based on Amazon Machine Images. However, you might need to activate the SSM agent manually in some cases. For more information, see Working with the SSM agent in the AWS Systems Manager User Guide. To manage EC2 instances automatically with Systems Manager, use the Default Host Management Configuration setting.

For assessing network reachability of Amazon EC2 instances, vulnerability scanning of container images, or vulnerability scanning of Lambda functions, no agents are necessary.

  1. Sign in to your organization management account for AWS Organizations.
  2. Navigate to Systems Manager and open the Quick Setup page.
  3. Click Create for Default Host Management Configuration.
  4. Make sure the box is selected for Enable automatic updates of the SSM Agent every two weeks.
  5. Click Create. You will see a banner stating, "Your Default Host Management Configuration Quick Setup is being updated.". It normally takes up to 30 minutes for the agent to connect with Systems Manager and the EC2 instance to appear in the Systems Manager Inventory as a managed instance (required for Inspector to perform agent-based scanning).
  6. You may continue to the next steps without waiting 30 minutes for the Host Management Configuration to complete.

Deployment Considerations

To deploy Inspector across your AWS Organization you need to enable it in the AWS management account and the security tooling account whether this is done in the Console, CLI, or API. If you are not familiar with the concept of the security tooling account it is recommended to familiarize yourself with the recommended account structure in the Security Reference Architecture. To summarize, this is a dedicated account in your AWS Organization that is used as the delegated administrator account for native AWS security services such as Amazon Inspector, Amazon GuardDuty, AWS Security Hub, and Amazon Detective.

Region Considerations

Amazon Inspector is a regional service. This means that to use Amazon Inspector you need to enable it in every region that you would like to have vulnerability monitoring capabilities in. You can enable Inspector across all accounts and regions using the AWS CLI script on GitHub or you can do this by toggling between regions in the console.

A question that is often asked is “Should I use a security service in a region that my company is not actively using?”. Although there is not a straightforward answer to this question as there are many factors that might influence your answer such as risk appetite, budget, and compensating controls, among others. There are some things to keep in mind when making this decision.

  1. Inspector is a service that you only pay for what you use. So, if you have a region that has minimal use you can have Inspector on giving visibility into your vulnerability landscape without incurring disproportionate cost associated with the resources being used in a region.
  2. If you have a compensating control associated with none used regions such as a service control policy that blocks all use in this region. It is still recommended to have a detective control to validate detection of this compensating control being changed at any point in the future.

This decision is ultimately one that your company needs to make based on your own circumstances, but a rule of thumb in security is that more visibility before an investigation is better as it often hard, if not impossible to obtain after the fact.

Implementation

In this section we will cover the minimum requirements for enabling Inspector in a stand-alone account and in a multi-account organization.

Stand-alone account enablement

Inspector Getting started Figure 1: Inspector getting started page

The first step is to navigate to the Inspector console. Once you are in the Inspector console you should see a landing page with a getting started button. Click on “Get started”.

Inspector activation Figure 2: Activate Inspector page

After clicking on “Get started” you will be brought to the Inspector enablement page. Review the Service role permissions so that you have an understanding of the permissions Inspector needs in order to provide its features and functions then select the yellow box labeled “Activate Inspector” to enable Inspector.

Once these two steps are done Inspector will be enabled in this account. It is important to refer to sections below to make sure you have enabled all relevant features of Inspector.

Multi-Account organization enablement

When you implement Inspector for the first time in your AWS Organization as stated above you will set the delegated administrator in your organization management account in each region that you want to use Inspector. Keep in mind you will need to use the same account in all regions.

Inspector Getting started Figure 3: Inspector getting started page

The first step is to navigate to the Inspector console in your organizations management account. Once you are on the Inspector console you will see a landing page with a getting started button. Click on “Get started”.

Inspector delegated admin Figure 4: Delegated admin assignment page

After clicking on “Get started” you will be brought to the Inspector enablement page. Next you will need to enter the account ID for the account you want to designate as the Inspector delegated administrator account. Once you have entered the account ID select “Delegate”. At this point you will switch to the Delegated administrator to finish configuring Amazon Inspector across your AWS Organization.

Inspector Getting started Figure 5: Inspector getting started page

Once you are in the Inspector delegated administrator account you will again see a landing page with a getting started button. Click on “Get started”. Once this is complete Inspector will be enabled. There are a few more deployment considerations that we will cover.

Inspector Account management Figure 6: Inspector account management page

Next you will need to make sure you activate scanning for all current accounts and all scanning types including Amazon EC2 scanning, Amazon ECR Scanning, AWS Lambda standard scanning, and AWS Lambda code scanning. It is also highly recommended to “Automatically activate Inspector for new member accounts”. This helps you understand that you don’t have a gap in vulnerability coverage when new accounts are created in your organization. This will also automate the process of onboarding new accounts and automatically aggregate all findings to your delegated administrator account reducing manual tasks and saving time.

  • Sign in to the Delegated Admin account for Inspector.
  • Open the Inspector console.
  • From the Account management page, under Automatically activate Inspector for new member accounts toggle on the option to Automatically activate Inspector for new member accounts.
  • Make sure that all of the options are selected and click Save. You should see a banner with the message "You have successfully updated the auto-activate scan settings for your organization.".
  • Scroll down to where accounts are listed under Organization. Depending on how many accounts you have, you should click the gear icon on the right to view 50 accounts per page.
  • Per page, select all accounts. Click the Activate dropdown menu, select all of the options, and click Submit.
  • Within minutes, resources will start being scanned and you will see any generated findings on the Findings page.

Alternatively, you may enable Inspector across all accounts and regions using CLI. Check out the enablement script on Github.

Coverage

In this section we will cover the enablement of different features to configure Inspector across all supported resources in your environment.

Amazon EC2 Scanning

After enabling Inspector in your Organization there are two more Amazon EC2 scanning related configurations that you need to address.

Inspector Deep Inspection for Amazon EC2 gives Inspector the ability to detect package vulnerabilities for application programming language packages in your Linux-based Amazon EC2 Instances. New accounts enabling Inspector will have deep inspection enabled by default. If you have an account that was previously enabled and want to confirm that this is enabled, you can look at the account management page in the Inspector console and look for any accounts that have deep inspection scanning deactivated like the picture below. For full details on Inspector Deep inspection and instructions on how to configure deep inspection scans refer to the Inspector Deep inspection documentation.

Inspector deep scan activated Figure 7: Inspector EC2 deep scan activated

Inspector deep scan deactivated Figure 8: Inspector EC2 deep scan deactivated

By default, Deep Inspection scanning looks at the default paths below.

  • /usr/lib
  • /usr/lib64
  • /usr/local/lib
  • /usr/local/lib64

All individual accounts can add up to 5 custom paths. The delegated administrator can add an additional 5 paths that will apply across the organization. This amounts to a total of up to 10 custom paths scanned per account in the organization. An example of a custom path would be “/home/usr1/project01”. It is recommended to put in all custom paths applicable to your organization to provide full visibility for Inspector Deep inspection.

Inspector EC2 scan settings Figure 9: Inspector EC2 scan settings

Windows Scanning

Amazon Inspector automatically discovers all supported Windows instances and includes them in continuous scanning without any extra actions. Unlike scans for Linux based instances, Amazon Inspector runs Windows scans at regular intervals. Windows instances are initially scanned at discovery and then scanned every 6 hours. However, the default 6‐hour scan interval is adjustable. If 6 hours is your desired scan frequency than no action is needed. If you would like to adjust the scan frequency you can do this using the aws ssm update-association CLI command. For steps on how to adjust the scan frequency please refer to the Inspector Windows scanning documentation.

ECR Scanning

When you first activate ECR scanning, and your repository is configured for continuous scanning, Amazon Inspector detects all eligible images that you have pushed within 30 days, or pulled within the last 90 days. Amazon Inspector continues to monitor images as long as they were pushed or pulled within the last 90 days (by default), or within the ECR rescan duration you configure. You might choose to stop scanning instances after a defined period of time because they are no longer used for applications in your environment or based on other compensating controls you might have in place. You can configure Inspector to re-scan based on either image push date or image pull date. For example, if you select 60 days for push date, and 180 days for pull date configurations, Amazon Inspector will continue to monitor images if they were pushed in the last 60 days or if they have been pulled at least once in the last 180 days. We recommend understanding the application deployment patterns at your organization when deciding the re-scan duration settings. For example if you build images often you might want shorter scan durations. Also, if you utilize ECR lifecycle policies this might affect how long images exist in ECR. For detailed instructions on how to set this duration please refer to the ECR automated re-scan duration documentation.

Inspector ECR scan settings Figure 10: Inspector ECR scan settings

Lambda Scanning

Lambda scanning has two different functionalities. The first is the ability to scan Lambda functions for software vulnerabilities in programming languages and packages. The second is the ability to scan your custom privileged application code for code vulnerabilities. Under account management make sure that these are both activated to provide full Inspector visibility. If you see any accounts with Lambda scanning or code scanning deactivated refer to the Lambda scanning documentation for detailed steps on activation.

Inspector Lambda scanning Figure 11: Inspector Account management page

CI/CD Scanning

You can integrate Amazon Inspector directly in CI/CD tools such as Jenkins. For Jenkins and TeamCity tools Inspector has dedicated plugins that can be installed so you can add vulnerability scanning directly into these pipelines. These plugins can be used as a pass or fail mechanism based on finding severities.

If Amazon Inspector does not provide plugins for your CI/CD solution, you can create your own custom CI/CD integration using a combination of the Amazon Inspector SBOM Generator and the Amazon Inspector Scan API.

CIS Scans

In addition to traditional vulnerability scans many customers also want to run scans to assess adherence to CIS Benchmarks. If you're not familiar, CIS Benchmarks from the Center for Internet Security (CIS) are a set of globally recognized and consensus-driven best practices to help security practitioners implement and manage their cybersecurity defenses. Developed with a global community of security experts, the guidelines help organizations proactively safeguard against emerging risks. Companies implement the CIS Benchmark guidelines to limit configuration-based security vulnerabilities in their digital assets. Just like you can check your AWS environment against CIS Benchmarks using AWS Security Hub, Inspector allows you to run CIS Benchmarks against your operating systems in AWS.

Start by familiarizing yourself with the necessary requirements for running CIS scans such as the need for deep scanning to be enabled and an SSM agent to be present on an instance.

Next, we recommend you think about your desired outcome for CIS scans before configuration. For example, you should answer questions before configuration such as what we have listed below, which is not an exhaustive list. This will help you get the most out of your CIS scans without creating extra findings that don't help with your overall security goals.

  • How often do we build images? Do we need to run frequent scans or run one time scans based on frequent image build?
  • What images / environments need to run level 1 vs level 2 scans?
  • Will you push out CIS scans across your AWS Organization from the delegated administrator account or will individual account owners be responsible for creating them at the account level.
  • Do you have a tag in place that you can use to target instances when configuring your scan configuration settings?

Operationalizing

Actioning Inspector Findings

Many organizations have a well-established vulnerability management program, but if you don’t or you are unsure of what you do now works with Amazon Inspector we want to highlight a few important themes that you should be thinking about.

Inspector finding detail Figure 12: Inspector finding details

Inspector score Figure 13: Inspector score example

Inspector code remediation Figure 14: Generative AI powered code remediation recommendation

Inspector vulnerability findings give great detail into the resource affected, the CVE, and generative AI powered code remediation suggestions giving security and application teams the context needed to more quickly remediate vulnerabilities in your AWS environment. Inspector findings are also stateful. This means that if you update a package that contained a vulnerability Inspector will see the package change, initiate an assessment, and if the vulnerability was in fact remediated then close the finding. This understanding is important for understanding you will handle Inspector findings. Below will dive into some of the different themes we think you should be thinking through.

  1. A critical component of an effective vulnerability management program is the ability to assess and prioritize security findings. This is where pulling in context, organizational history, and tuning detection systems comes into place. Prioritization of security findings helps establish the appropriate speed for response level. We recommend prioritizing the investigation of all critical and high severity findings.
  2. Understand what you will do with findings when they are created by Inspector. For example, Amazon Inspector has 5 different finding severity levels described here. It is important to understand how quickly you will require teams in your organization to remediate findings. This is likely to depend on severity, as you will want to more quickly respond to critical findings vs informational findings.
  3. After understanding response times, it is important to focus on how you will alert on new vulnerabilities. For example, do you have a ticketing system that you would like to integrate with? If so, this is something that AWS Security Hub can assist with. You might want to send these alerts directly to applications teams for remediation, or maybe they need to be cleared through security first. With Inspectors integration with Amazon EventBridge and AWS Security Hub you have many different alerting and tracking options. It is important to understand what works best for your organization and to have this workflow established.
  4. Remediation of vulnerabilities should be pushed to application owners as they are the ones who understand the implications of updating packages used by their application code. It would be an anti-pattern for security teams to be responsible for software patching. A two-way communication channel between the security teams should be established for communicating risk, its acceptance and/or mitigation.
  5. Ideally at every organization we want to automate as much as possible to save time and potential errors associated with repetitive manual actions from humans. Unfortunately, this can’t also be done 100% of the time, but we should always be working to get there. First work through what services you will use to automate vulnerability remediation such as AWS Systems Manager Patch Manager. Then understand what environments, resources, and CVEs you feel comfortable automatically remediating. The amount of automation that can be created will largely depend on resource timing and ability. There will be an intersection where risk is not great enough to constitute how much time you spent on furthering automation versus working on other high priority projects. Once you start to build this out there are a lot of different resources that can help with automating patch management in AWS. Since there are a number of different resources on this, we have created a dedicated section in the resources section below of valuable resources that you should look at.
  6. In addition to automating where possible many customers use Amazon Inspector to find vulnerabilities in resources early in the development lifecycle and remediate before being deployed in a production environment. Using Amazon Inspector in development and staging accounts during development and testing give you the visibility to understand what vulnerabilities exist in applications before deploying to production. There are also multiple blogs that cover how Inspector fits into a CI/CD pipeline in the resources section.

Inspector finding flow Figure 15: Inspector finding flow

Software Bill of Materials (SBOM) Configuration

In Amazon Inspector you can export a Software Bill of Materials or SBOM for short. If you’re not familiar an SBOM it is a nested inventory of all the open source and third-party software components of your codebase. This can help you gain visibility into information about your software supply, such as your commonly used packages, and associated vulnerabilities across your organization.

To export SBOMs you need to use the Console or API set this up. Steps on how to configure this can be found in the Inspector SBOM documentation. It is important to keep in mind that this is a one-time export. If you need to do this on a regular basis it is recommended to set up a Lambda Function that uses the create sbom export API on a regular schedule to automatically create these SBOMs. This will help you if you need to look at an SBOM you have an update to date SBOM. This could also be event driven, for example running an SBOM export for an instance when it is created.

Inspector SBOM settings Figure 16: Inspector SBOM settings

Suppression Rules

You might have CVEs in your environment that are not applicable because of a compensating control or that you’re unable to remediate and have categorized them as an accepted risk. For these circumstances you can create suppression rules in Inspector. You can use suppression rules to automatically exclude Amazon Inspector findings that match specified criteria. For example, you can create a rule to suppress all findings with a low vulnerability score. Suppression rules don't have any impact on the finding itself and don't prevent Amazon Inspector from generating a finding. Suppression rules are only used to filter your list of findings. If Amazon Inspector generates a new finding that matches a suppression rule, the service automatically sets the status of the finding to Suppressed. The findings that match suppression rule criteria won't appear in the console by default.

Additionally, if you are using AWS Security Hub as your aggregation point for Inspector in other AWS security services you can use automation rules to address findings. For example, you can use automation rules to upgrade all findings for a particular production account to a severity that warrants an immediate action or downgrades the severity of findings for particular environments that have controls in place that don’t allow public resources. To learn more about AWS Security Hub automation rules refer to the AWS Security Hub automation rules documentation.

Amazon Inspector continuously updates its vulnerability database with the latest CVEs to confirm that our customers are able to assess their environments for up-to-date information. From time to time, you might ask “Is Inspector looking for this CVE?”. You can use the vulnerability database search capability in the AWS console to help answer this question, by simply providing a Common Vulnerability and Enumerations (CVE) ID, for example, “CVE-2023-1264“. This allows you to confirm the CVEs covered by Inspector scanning engine and do preliminary research on a CVE.

Inspector vulnerability database Figure 17: Inspector vulnerability database page

Cost considerations

Amazon Inspector pricing is thoroughly covered in the pricing page covering pricing components, and multiple pricing examples that go through examples of what pricing might look like in your environment. We won’t cover that here and instead focus on two different questions that are frequently asked. 1. My organization is cost conscious or going through a cost optimization exercise, I want to confirm that I am using Amazon Inspector in a cost-effective way. 2. I am going to test Inspector or I want to enable Inspector in my environment but I want to estimate costs before getting started.

Amazon Inspector is a cost-effective service that charges you based on usage in your environment. To verify that you are using Inspector cost effectively it is important to understand that since it is usage based you should make sure you do not have extra resources in your environment that are not being used. This will not only save Inspector cost but will potentially save you on Amazon EC2, ECR, and Lambda costs. Secondly each scanning function of Amazon Inspector is optional, so you can choose to use what you need. It is not recommended to disable any of the features as this could potentially cause a lack of visibility into vulnerabilities in your environment and introduce unnecessary challenges, but at every organization there is budgets limits that should be taken into consideration when using Amazon Inspector features. Another option that can be used but should be carefully evaluated is the tag that can be used to exlude scanning for EC2 instances. For more information on how to configure this tag please refer to the scanning Amazon EC2 Instances documentation.

The best way to estimate costs with Amazon Inspector is to take advantage of the 15-day free trial. Inspector can be turned on and off across hundreds or thousands of accounts in an organization in a matter of minutes. Once you enable Inspector you will be able to see the costs associated with running Inspector in your organization past the 15-day free trial.

Troubleshooting

Troubleshooting AWS Systems Manager (SSM) Agent Issues

There are several issues that might cause the SSM agent to work improperly. You can use the Systems Manager Automation runbook to automatically troubleshoot an EC2 instance that SSM is unable to manage

  • Open this link to configure the Systems Manager Automation runbook.
  • Navigate to the AWS Region for the EC2 instance you want to troubleshoot.
  • Under the Input parameters, change the dropdown from "Show managed instances only" to "Show all instances".
  • Select the EC2 instance you want to troubleshoot.
  • Leave all the other settings, and at the bottom of the page, click Execute. This process normally takes up to 5 minutes to complete.
  • Once the automation document has as an Overall status of Success, expand the Outputs section.
  • Review the outputs to see the specific problem with your SSM configuration.

Resources

Workshops

Demo videos

Blogs

Other Resources