Skip to main content

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

  1. Open Amazon Inspector

  2. View your findings

    • In the left navigation, click Findings then All findings
    • Review the list of active findings sorted by severity
  3. Understand each finding

    • Click on a finding to see details
    • Note the Severity (Critical, High, Medium, Low)
    • Review the Affected resource and Remediation guidance
  4. 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
  5. 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:

  1. Wait for Inspector to rescan - Inspector automatically rescans resources. Most findings update within 24 hours.

  2. Check the finding status - Return to the Inspector console and verify the finding shows as "Closed" or is no longer listed.

  3. 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

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_exist to inspector2_active_findings_exist in newer versions.