Inspector.3: Lambda code is not scanned by Inspector

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub Inspector.3 check?

Inspector.3 fails when Amazon Inspector Lambda code scanning is not enabled in the account and region. This scope scans the custom application code inside your Lambda functions for code vulnerabilities (injection flaws, data leaks, weak cryptography, and missing encryption) based on AWS security best practices.

Why does Inspector.3 matter?

The code your team writes inside a Lambda function carries the same insecure patterns as any application (SQL or command injection, hardcoded secrets and leaked data, weak or missing cryptography) but there is no host agent or SAST gate watching a serverless deploy. Lambda code scanning analyses the function's own application code and surfaces these vulnerabilities into Security Hub so they can be fixed before they ship, rather than discovered after exploitation.

How do I fix Inspector.3?

Enable the Lambda code scan scope with aws inspector2 enable --resource-types LAMBDA_CODE, delegated from the Organization admin. (Code scanning requires Lambda standard scanning to be active first, so enable LAMBDA in the same call if it isn't already on.)
Confirm the scope is active per region with aws inspector2 batch-get-account-status.
Triage findings in Security Hub and remediate the offending application code in the function before the next deploy.
Enable auto-enable so new accounts and regions are covered automatically.

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.3 a false positive?

Lambda code scanning isn't available in every AWS Region, so an account running serverless workloads only in a Region where the feature isn't offered cannot enable this scope and will show FAILED through no fault of its own. Disable the control in those Regions or suppress the finding rather than treating it as a gap. The familiar org gotcha also applies: in a delegated-admin setup a suspended member account keeps the administrator's finding FAILED until you disassociate it from Inspector. If a given account deploys no Lambda functions at all, a documented suppression is more honest than enabling a scope that has nothing to evaluate.

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

Part of the learning path See what's happening

Inspector.1 EC2 is not being scanned for vulnerabilities
Inspector.2 Container images are not scanned by Inspector
Inspector.4 Lambda is not fully covered by Inspector