Overview
Overview
A vulnerability is exploitable in a given context if a (simulated) malicious actor could use it to impact the target's desired data confidentiality, integrity, or availability in that context.
Remediation guidance
This workload currently has {{vulnerabilities.exploitableCount}} exploitable vulnerabilities.
Remediate by updating the vulnerable package, base image, or deployed artifact, then redeploy the workload so it no longer runs the affected version.
Kubernetes / generic container workloads
Update the running workload to a patched image:
kubectl set image deployment/{{asset.name}} <container-name>=<patched-image> --namespace <namespace>
Google Cloud Run
Redeploy the service or revision from a patched image:
gcloud run deploy {{asset.name}} --image <patched-image> --region {{asset.region}}
AWS Lambda container images
If the function is image-based, redeploy it with a patched image:
aws lambda update-function-code --function-name {{asset.name}} --image-uri <patched-image-uri>
Virtual machines and compute instances
Patch the operating system and application packages using your image pipeline or instance patching workflow, then verify the vulnerable package versions are no longer installed.
Validation
- Re-scan the workload after redeployment.
- Verify that exploitable vulnerability findings are cleared.
- If a fix cannot be applied immediately, isolate the workload and document a time-bound exception.
References
- Kubernetes
kubectl set image: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_set/kubectl_set_image/ - Google Cloud Run deploy: https://docs.cloud.google.com/run/docs/deploying
- AWS Lambda
update-function-code: https://docs.aws.amazon.com/cli/latest/reference/lambda/update-function-code.html
Service-wide remediation
Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.
AWS
Use AWS Organizations guardrails, AWS Config rules or conformance packs where they fit, approved account baselines, and IaC modules so new resources inherit the secure setting.
Google Cloud
Use organization or folder policies where available, shared project templates, logs and alerting baselines, and IaC modules so new resources inherit the secure setting.
Kubernetes
Use admission policies, baseline cluster configuration, GitOps templates, and namespace or workload guardrails so new deployments follow the control by default.
Operational rollout
- Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
- Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
- Re-scan and track approved exceptions with an owner and expiry date.
Query logic
These are the stored checks tied to this control.
Ensure there are no Compute with exploitable vulnerabilities
Connectors
Covered asset types
Expected check: eq []
{ComputeWithExploitableVulnerabilities {...AssetFragment}}CloudRun revisions with high severity vulnerabilities
Connectors
Covered asset types
Expected check: eq []
{
cloudRunRevisions(
where: {
image: {
findings_SOME: {
vulnerability: {
exploitAvailable: true
}
}
}
}) {
...AssetFragment
}
}Containers with exploitable high/critical vulnerabilities
Connectors
Covered asset types
Expected check: eq []
{
ContainersWithExploitableVulnerabilities {
...AssetFragment
}
}
AWS
Google Cloud
Kubernetes