Docker Hardened Images enhanced vulnerability scanning with Docker and Aikido

Aikido now scans Docker Hardened Images (DHI) with built-in VEX support. Vulnerabilities that Docker has verified as non-exploitable drop out of the queue automatically, so developers spend their time on findings that actually matter. This post walks through what changed, why it matters, and how users can benefit from the new integration.

Why teams are drowning in CVEs

Modern application teams drown in CVEs. And the volume is climbing fast. AI coding agents now generate and assemble software far faster than any team can review it, pulling in dependencies by the hundreds and spinning up new services on demand. Every base image they reach for is another stack of CVEs landing in someone’s queue. The faster code ships, the more it matters that it starts from a foundation that’s already minimal, already patched, and already vetted — which is exactly why hardened images matter more now than they ever have.

Docker Hardened Images addresses this problem at the source. DHI images are purpose-built, often distroless, and ship with only the software the workload needs. The attack surface is smaller by construction. Patches land faster than upstream in many cases.

A smaller attack surface only helps if your scanner can see it. Distroless images break tools that expect a package manager or a shell. Naive scanning produces false positives against components that are not actually present, or flags CVEs in code paths that cannot be reached. Teams end up triaging noise that the image author already knew was not a problem.

The new integration closes this gap. DHI publishes signed VEX attestations alongside each image. Aikido reads those attestations and applies them during triage. The CVEs Docker has already cleared get filtered out, with a clear reason attached.

Before you begin

You need three things to scan DHI with Aikido:

An active Aikido account.

Access to Docker Hardened Images.

A Docker Hub Personal Access Token with read-only scope.

If your Docker Hub registry is already connected to Aikido, skip the next section.

Connect Docker Hub to Aikido

In Aikido, go to Settings > Containers and click Connect Registry.Select Docker Hub.Enter your organization namespace, username, and Personal Access Token.Aikido discovers your repositories and lists them for scanning.

Scan a Docker Hardened Image

Once the registry is connected, open the registry action menu and click Scan repos in registry. There is no extra configuration for DHI. Aikido detects hardened images automatically and applies the right data sources in the background.

Under the hood, the workflow follows the DHI technical spec:

Detection. Aikido identifies the DHI base image from the image reference and registry metadata.

Cataloging. The scanner pulls the signed SPDX 2.3 SBOM published with the image. SBOMs are retrieved through OCI 1.1 referrer lookup against the registry, or from /opt/docker/sbom/ when present. Reading the vetted SBOM produces complete, accurate component data, where indexing a distroless filesystem would not.

Matching. Components are matched by PURL against the Docker OSV feed and upstream advisory feeds.

Applying VEX. Aikido overlays the OpenVEX statements Docker publishes for the image, and suppresses any finding marked as resolved by the attestation.

How VEX status shows up

VEX status

What it means

Fixed

The vulnerability is patched in this image.

Not Affected

Docker has verified the CVE is a false positive or non-exploitable in context. Aikido suppresses these by default.

Under Investigation

Impact is still being assessed by Docker.

Affected

The vulnerability applies, and a fix is not yet available.

What you see in Aikido

Aikido keeps the UI focused on a single question: is this image vulnerable or not. When Docker’s VEX attestation indicates a CVE doesn’t require triage (for example, it’s been fixed or marked not affected), Aikido filters it out of the active queue automatically. You don’t have to triage it, tag it, or click through anything. Findings that remain in the queue are the ones that genuinely apply to the image, so your team spends time only on what matters.

Behind the scenes, Aikido still consumes the full OpenVEX statement (status, justification, image digest) for audit and compliance purposes. It just isn’t surfaced as a status drill-down in the UI, because in practice nobody triaging vulnerabilities wants to dig through VEX metadata.

What the result looks like

On a typical DHI workload, the active queue shrinks dramatically once VEX is applied. A scan that returns several hundred CVEs against a generic base image collapses to the handful of findings the image actually carries.

A concrete example: a CVE in a parser library shows up across most base images. Docker marks it not_affected in the DHI build because the vulnerable code path cannot be reached by an adversary. Aikido reads that statement, files the CVE under “VEX indicates not affected,” and your team never sees it in triage. The justification stays attached if an auditor asks.

For teams pursuing FedRAMP, SOC 2, or other compliance regimes, this matters twice. The findings list is honest. The exceptions are signed, attributable to the image publisher, and traceable back to a public attestation. You are not handing auditors a wall of red.

Recap

The integration is based on the following information provided by Docker Hardened Images:

Signed SBOMs give Aikido complete component data without trying to index a distroless filesystem.

OpenVEX attestations carry Docker’s exploitability verdict, with justification, directly into the scanner.

The outcome is a triage queue that reflects real exploitability in your image, not a flat dump of every CVE that ever touched an upstream package.If you have not started with hardened images yet, the Docker Hardened Images documentation is the place to begin.

Learn more about the integration:

On June 26th, Aikido is hosting a webinar for those interested in learning more about the integration. 

Register for Aikido x Docker: Less Noise, More Signal in Container Security

Resources

Review our Docker Hardened Images documentation.

Set up Docker Hub registry on Aikido

Quelle: https://blog.docker.com/feed/

AWS announces AWS Workload Credentials Provider

AWS announces AWS Workload Credentials Provider, a lightweight client-side provider that automates deployment of exported certificates from AWS Certificate Manager (ACM) and local caching of secrets from AWS Secrets Manager across AWS and non-AWS workloads. Previously, customers exporting public or private certificates from ACM had to build custom automation using Amazon EventBridge to detect renewals and deploy the updated certificates. With public certificate lifetimes decreasing per the the Certification Authority Browser Forum (CA/B) mandate, this custom automation can become difficult to maintain at scale. AWS Workload Credentials Provider eliminates this complexity by providing a single provider that helps distribute and automate both secrets and certificates to your workloads. You configure it with your certificate ARN and specify options such as file paths and server reload behavior — the provider then handles certificate export and deployment automatically to prevent expiry related failures. It runs on Windows and Linux and supports Apache and NGINX web servers. For secrets caching, the provider maintains full backwards compatibility with the AWS Secrets Manager Agent, enabling you to securely cache application secrets locally across AWS and non-AWS workloads through the same unified provider. AWS Workload Credentials Provider is open source and available on GitHub. You can use it with exportable ACM certificates and Secrets Manager in all AWS Regions. To learn more, visit the AWS Certificate Manager documentation or the AWS Secrets Manager documentation.
Quelle: aws.amazon.com

Amazon Managed Service for Prometheus now supports out of order sample ingestion

Amazon Managed Service for Prometheus now supports out-of-order sample ingestion and a workspace-level rule query offset. All workspaces have a default out-of-order time window of 1 minute, allowing the workspace to accept metric samples arriving outside strict chronological order. You can adjust this window to match your ingestion patterns or set it to 0 to disable the feature and discard out-of-order samples. You can also configure a global rule query offset that introduces a delay before rule evaluation queries run, giving late-arriving samples time to be ingested before rules execute.
Together, these features reduce data loss and improve alerting accuracy for workloads with distributed collectors, batched exports, or variable network latency. Out-of-order sample support ensures late-arriving data points are ingested rather than discarded, preserving metric completeness. The rule query offset compensates for the expected ingestion delay. Without it, rules evaluate instantly and may miss samples that haven’t landed yet, producing results that differ from the same expression evaluated after all metrics arrive. Two new CloudWatch vended metrics, OutOfOrderIngestionRate and OutOfOrderSampleAge give you visibility into ingestion patterns, helping you tune both settings for your workload. 
Out-of-order sample ingestion and rule query offset are available in all AWS regions where Amazon Managed Service for Prometheus is generally available. To get started, configure the out-of-order time window and ruler query offset in your workspace settings via AWS console, API or CLI. For more information, see Amazon Managed Service for Prometheus user documentation.
Quelle: aws.amazon.com

AWS Elastic Beanstalk console now integrates CloudWatch Logs in the Logs tab

AWS Elastic Beanstalk now provides a CloudWatch Logs integration directly in the environment Logs tab of the Elastic Beanstalk console. Previously, customers had to navigate to the CloudWatch console to find the relevant log groups and log streams for their environments. With this launch, customers can view CloudWatch log events without leaving the Elastic Beanstalk console.  
The Logs tab displays log groups that an environment streams logs to, as well as log groups matching the aws/elasticbeanstalk/<env-name>/* prefix. Customers can select a log group to view its log streams, with the most recently active stream selected by default. A log stream dropdown allows switching between streams and filtering results. For deeper analysis, a View in CloudWatch dropdown provides direct links to the log group, log stream, or CloudWatch Logs Insights in the CloudWatch console.
This feature is available across all Elastic Beanstalk platform branches in all AWS Commercial Regions and AWS GovCloud (US) Regions where Elastic Beanstalk is available. For a complete list of supported Regions, see AWS Regions.
For more information about using Elastic Beanstalk with Amazon CloudWatch, see the AWS Elastic Beanstalk developer guide. To learn more, visit the AWS Elastic Beanstalk product page.
Quelle: aws.amazon.com

Amazon MWAA Serverless now supports Amazon EventBridge notifications/

Amazon Managed Workflows for Apache Airflow (MWAA) Serverless now supports workflow and task state change events to Amazon EventBridge, enabling data engineering and platform teams to build event-driven automation for their Apache Airflow workflows.
Previously, monitoring workflow execution required custom polling logic or manual observation. With this launch, MWAA Serverless can emit events when workflows transition between states, including started, running, succeeded, or failed, and when individual tasks change state, such as scheduled, succeeded, failed, or up for retry. With this feature, you can further automate your existing workflows – for example, using EventBridge notifications to trigger alerts when a production workflow fails, automatically restart dependent pipelines when an upstream workflow succeeds, or log state transitions to Amazon S3 for compliance and auditing.
This feature is available in all AWS Regions where Amazon MWAA Serverless is available. For the complete list of supported Regions, see Regions in the Amazon MWAA Serverless User Guide. For pricing details, see Amazon EventBridge pricing.
To learn more, see Monitoring Amazon MWAA Serverless in the Amazon MWAA Serverless User Guide and Amazon MWAA Serverless events in the Amazon EventBridge Events Reference.
Quelle: aws.amazon.com