How to Find Vulnerable Libraries in Azure and AWS Workloads

Retrospective: this article looks back at events from December 2021, written in 2026 with the benefit of hindsight.

When a library vulnerability like Log4Shell hits, the first question is "where are we affected?" Here is how to answer it across Azure and AWS workloads.

Step 1: Scan running workloads

• Azure: Defender for Servers vulnerability assessment and Defender for Containers scan VMs and container images for vulnerable packages. Search findings by CVE.
• AWS: Amazon Inspector scans EC2 instances, ECR container images and Lambda functions for software vulnerabilities, including language packages. Filter findings by CVE.

Step 2: Scan code and dependencies

• Use software composition analysis in your repositories (for example, GitHub Dependabot alerts and dependency graph).
• Search for the library across repositories — including transitive dependencies.

Step 3: Check third-party software and appliances

Review vendor advisories for every commercial product you run. Maintain a list of vendors and their response status.

Step 4: Check managed services

Cloud providers patch managed services, but check advisories for services where you supply code or configuration (for example, application runtimes).

Step 5: Mitigate while patching

• Enable WAF managed rules targeting the vulnerability.
• Restrict outbound connections from affected workloads.
• Apply vendor-recommended configuration mitigations.

Step 6: Patch and redeploy

Update the library, rebuild images and redeploy. Verify the fixed version is running.

Step 7: Hunt for exploitation

Search logs for exploit strings and look for unusual outbound connections from affected workloads during the exposure window.

Prepare for next time

Generate SBOMs for your applications and store them, so the next "where are we affected?" takes minutes.