AWS Inspector v2 Active Findings Exist
Overview
This check identifies whether your AWS account has active (unresolved) findings from Amazon Inspector v2. Inspector v2 is a vulnerability management service that continuously scans your EC2 instances, container images (ECR), and Lambda functions for software vulnerabilities and unintended network exposure.
When this check triggers, it means Inspector has found security issues that need your attention.
Risk
Unaddressed Inspector findings can lead to:
- Security breaches from unpatched software vulnerabilities
- Compliance violations for standards like PCI-DSS, HIPAA, or SOC 2
- Network exposure through misconfigured security groups (e.g., open SSH ports)
- Data exfiltration if attackers exploit known vulnerabilities
The longer findings remain unresolved, the greater your exposure window to potential attacks.
Remediation Steps
Prerequisites
- Access to the AWS Console with permissions to view Inspector findings
- Permissions to modify EC2 security groups (for network findings)
- Permissions to update packages on affected resources (for vulnerability findings)
Required IAM permissions (technical detail)
To view and remediate Inspector findings, you need:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"inspector2:ListFindings",
"inspector2:BatchGetFindingDetails",
"ec2:DescribeSecurityGroups",
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupIngress"
],
"Resource": "*"
}
]
}
AWS Console Method
-
Open Amazon Inspector
- Go to the Amazon Inspector console
- Make sure you're in the correct AWS region (us-east-1)
-
View your findings
- In the left navigation, click Findings then All findings
- Review the list of active findings sorted by severity
-
Understand each finding
- Click on a finding to see details
- Note the Severity (Critical, High, Medium, Low)
- Review the Affected resource and Remediation guidance
-
Address findings by type:
For Package Vulnerabilities:
- Click the affected resource (EC2 instance, container image, or Lambda function)
- Review the vulnerable package name and version
- Update the package to the "Fixed version" shown in the finding
- For EC2: SSH into the instance and run the update command provided
- For ECR: Rebuild and push a new container image with updated packages
- For Lambda: Update your function's dependencies and redeploy
For Network Reachability Issues:
- Click the affected EC2 instance
- Go to the Security tab and click the security group
- Click Edit inbound rules
- Find the problematic rule (e.g., SSH open to 0.0.0.0/0)
- Change the source to a specific IP or CIDR range
- Click Save rules
-
Re-scan to verify
- Inspector automatically rescans resources
- After remediation, the finding should close within 24 hours
AWS CLI (optional)
List all active findings
aws inspector2 list-findings \
--region us-east-1 \
--filter-criteria '{"findingStatus": [{"comparison": "EQUALS", "value": "ACTIVE"}]}' \
--query 'findings[*].[severity,title,findingArn]' \
--output table
Get details for a specific finding
aws inspector2 batch-get-finding-details \
--region us-east-1 \
--finding-arns "arn:aws:inspector2:us-east-1:123456789012:finding/abcd1234abcd1234abcd1234abcd1234"
List findings by severity (Critical and High only)
aws inspector2 list-findings \
--region us-east-1 \
--filter-criteria '{
"findingStatus": [{"comparison": "EQUALS", "value": "ACTIVE"}],
"severity": [
{"comparison": "EQUALS", "value": "CRITICAL"},
{"comparison": "EQUALS", "value": "HIGH"}
]
}' \
--query 'findings[*].[severity,title,resourceType]' \
--output table
Remediate a network finding (remove open SSH access)
# Remove the unrestricted SSH rule
aws ec2 revoke-security-group-ingress \
--region us-east-1 \
--group-id sg-0abcd1234abcd5678 \
--protocol tcp \
--port 22 \
--cidr 0.0.0.0/0
# Add a restricted SSH rule (replace with your IP)
aws ec2 authorize-security-group-ingress \
--region us-east-1 \
--group-id sg-0abcd1234abcd5678 \
--protocol tcp \
--port 22 \
--cidr 10.0.0.5/32
CloudFormation (optional)
CloudFormation cannot directly remediate Inspector findings, but you can use it to create properly configured resources that avoid common issues.
Example: Security group with restricted SSH access
AWSTemplateFormatVersion: '2010-09-09'
Description: Security group with restricted SSH access to avoid Inspector network findings
Parameters:
AllowedSSHCidr:
Type: String
Description: CIDR block allowed for SSH access (e.g., your office IP)
Default: 10.0.0.0/8
AllowedPattern: ^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}$
Resources:
SecureSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Security group with restricted SSH access
GroupName: secure-ssh-access
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 22
ToPort: 22
CidrIp: !Ref AllowedSSHCidr
Description: SSH access restricted to allowed CIDR
Tags:
- Key: Name
Value: secure-ssh-access
Outputs:
SecurityGroupId:
Description: ID of the secure security group
Value: !Ref SecureSecurityGroup
Deploy with:
aws cloudformation deploy \
--region us-east-1 \
--template-file secure-sg.yaml \
--stack-name secure-security-group \
--parameter-overrides AllowedSSHCidr=10.0.0.5/32
Terraform (optional)
Example: Security group with restricted SSH access
variable "allowed_ssh_cidr" {
description = "CIDR block allowed for SSH access"
type = string
default = "10.0.0.0/8"
}
resource "aws_security_group" "secure_ssh" {
name = "secure-ssh-access"
description = "Security group with restricted SSH access"
ingress {
description = "SSH access restricted to allowed CIDR"
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = [var.allowed_ssh_cidr]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "secure-ssh-access"
}
}
output "security_group_id" {
description = "ID of the secure security group"
value = aws_security_group.secure_ssh.id
}
Verification
After addressing your findings:
-
Wait for Inspector to rescan - Inspector automatically rescans resources. Most findings update within 24 hours.
-
Check the finding status - Return to the Inspector console and verify the finding shows as "Closed" or is no longer listed.
-
Re-run Prowler to confirm the check passes:
prowler aws --check inspector2_findings_exist --region us-east-1
Advanced verification with CLI
Verify no active critical/high findings remain
aws inspector2 list-findings \
--region us-east-1 \
--filter-criteria '{
"findingStatus": [{"comparison": "EQUALS", "value": "ACTIVE"}],
"severity": [
{"comparison": "EQUALS", "value": "CRITICAL"},
{"comparison": "EQUALS", "value": "HIGH"}
]
}' \
--query 'findings | length(@)'
Expected output: 0
Get a count of findings by severity
aws inspector2 list-finding-aggregations \
--region us-east-1 \
--aggregation-type SEVERITY \
--query 'responses[*].severityAggregation'
Additional Resources
- Amazon Inspector User Guide
- Understanding Inspector Finding Details
- How to Remediate Amazon Inspector Security Findings Automatically
- Prowler Documentation
Notes
-
This check is informational: Having findings does not necessarily mean you have a security breach. It means you have issues that should be reviewed and addressed based on their severity.
-
Prioritize by severity: Focus on Critical and High severity findings first. Medium and Low findings should be addressed based on your organization's risk tolerance.
-
False positives: Some findings may be acceptable in your environment (e.g., an intentionally public-facing service). Document exceptions and consider using Inspector suppression rules.
-
Continuous monitoring: Inspector scans continuously. New findings may appear as new vulnerabilities are discovered or your resources change. Consider setting up SNS notifications for new high-severity findings.
-
Check renamed: Note that Prowler renamed this check from
inspector2_findings_existtoinspector2_active_findings_existin newer versions.