Skip to main content
emnode
Sign up
Compliance High severity

AWS Security Hub · Inspector

Inspector.4: Lambda is not fully covered by Inspector

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub Inspector.4 check?

Inspector.4 fails when Amazon Inspector Lambda standard scanning is not enabled in the account and region. Standard scanning is the default Lambda scan type: it inspects the application package dependencies you add to your function code and layers for known software vulnerabilities, producing Package Vulnerability findings.

Why does Inspector.4 matter?

Most serverless code ships with a tree of third-party dependencies bundled into the function and its layers, and a CVE in any one of them is exploitable in production exactly like a vulnerable library on a server. Lambda standard scanning continuously matches those packaged dependencies against the Amazon Inspector vulnerability database and re-scans whenever a new CVE lands. Leaving it off means your serverless dependencies are the one part of the stack nothing is watching for known vulnerabilities.

How do I fix Inspector.4?

  1. Enable the Lambda standard scanning scope with aws inspector2 enable --resource-types LAMBDA, delegated from the Organization admin.
  2. Verify the scope is active per region with aws inspector2 batch-get-account-status.
  3. Review the resulting Package Vulnerability findings in Security Hub and update or patch the affected dependencies in your function code and layers.
  4. Turn on auto-enable so new accounts and regions inherit the coverage.

Remediation script · bash

# Enable the GuardDuty base detector in every Region (run from the delegated admin account).
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  existing=$(aws guardduty list-detectors --region "$region" --query 'DetectorIds[0]' --output text)
  if [ "$existing" = "None" ]; then
    aws guardduty create-detector --enable \
      --finding-publishing-frequency FIFTEEN_MINUTES --region "$region"
    echo "$region: GuardDuty detector created"
  fi
done

# Turn on Inspector EC2/ECR/Lambda scanning for this account and Region.
aws inspector2 enable --resource-types EC2 ECR LAMBDA

# Enable Macie (free bucket inventory clears Macie.1; discovery jobs are scoped separately by risk).
aws macie2 enable-macie --status ENABLED --finding-publishing-frequency FIFTEEN_MINUTES

Full walkthrough (console steps, edge cases and verification) in the lesson Enable threat detection and vulnerability scanning.

Is Inspector.4 a false positive?

As with the other Inspector controls, in a delegated-admin org the finding is generated only in the administrator account, and a suspended member account that doesn't have Lambda standard scanning enabled keeps the administrator's finding FAILED until you disassociate it. An account that runs no Lambda functions still has to enable the scope to pass, so a FAILED result on a purely non-serverless account is expected rather than a sign of exposure; suppress it instead of chasing it if you have deliberately chosen not to enable the scope there. Standard scanning is the prerequisite for Lambda code scanning (Inspector.3), so an account that intends to run code scanning must enable standard scanning here first.

Full lesson Enable threat detection and vulnerability scanning Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for Inspector controls ↗ Check your own account for Inspector.4 →
Part of the learning path See what's happening

More Inspector controls

  • Inspector.1 EC2 is not being scanned for vulnerabilities
  • Inspector.2 Container images are not scanned by Inspector
  • Inspector.3 Lambda code is not scanned by Inspector