Docker joins the Athena coalition: a cross-industry collaboration for supply chain security

The obvious takeaway from 2026’s biggest incidents is that attackers are increasingly using AI to move fast. Docker’s CISO, Mark Lechner, wrote about this shift and what every engineering team should do now.

What worries us is that the bar is about to drop further. For most of the last decade, finding a serious vulnerability in widely used open source took time and specialized skill. Frontier models now read code, reason across dependencies, and surface novel, chained vulnerabilities at machine speed, including flaws that survived years of expert review. Anthropic’s Mythos, and the more powerful models that follow it will find more vulnerabilities, faster, and by a wider margin than skilled humans could. The gap between a vulnerability being discovered and exploited has shrunk from years to hours, and a growing share are weaponized before they are ever public.

We believe the durable response in this reality is twofold: build products that are secure and transparent by default, and collaborate deeply across the ecosystem to share signals and intelligence. No single vendor sees the whole picture, and customers are best protected when supply chain technologies work together rather than in isolation.

Secure-by-default tools for devs, as AI embeds into the SDLC

As coding agents take on more of the software lifecycle, secure defaults have to cover more than what you build with. They have to cover where agents run and what they can reach. Today, Docker’s investment spans three areas covering sandboxes for local developers, secure dependencies, and governed access to vetted MCP tools. These capabilities and our upcoming products in the near future collectively help secure the developer environment as AI embeds itself into the SDLC:

Isolated, sandboxed execution for agents: Docker Sandboxes run AI coding agents in isolated microVMs, each with its own kernel, filesystem, and deny-by-default network, so a compromised dependency an agent pulls cannot reach the host, its credentials, or other workloads.

Trusted, open source foundations: Docker Hardened Images Community is free and open source under Apache 2.0. DHI are minimal, low-CVE images rebuilt from source with SLSA Build Level 3 provenance and signed SBOMs, built on Alpine and Debian. The catalog now spans over 3,500 hardened images and tens of thousands of hardened system packages, extending across container images, system packages, Helm charts, and MCP servers. DHI makes secure dependencies the easy, default choice.

Governed access to tools: Docker MCP Catalog and Gateway give agents a trusted, hardened set of MCP servers, plus centralized policy, secret blocking, and audit logging, so the connections agents make are verified rather than assumed.

Together these tools give developers a secure default from the first docker build through to the agent running in their environment. 

Working with the ecosystem on behalf of every developer

The second part of our approach is how we work with the ecosystem. For example, with the axios compromise earlier this year and the TeamPCP campaign, Docker worked with partners including Socket, the Trivy team, Checkmarx, and others to analyze the attacks and contain the blast radius (recap). The damage potential with these attacks could have been very large, however sharing signals across company lines, in real time, is what kept the blast radius relatively small. We have said it before, this is a posture we believe the ecosystem needs more of.

Docker is joining the Athena alliance

Athena is the next step in our journey of collaboration. Announced today, it is an industry coalition for the coordinated defense of open source software in the era of AI-accelerated vulnerability discovery, and Docker is a founding participant. Athena brings together organizations from across the software ecosystem to share findings and coordinate responses before vulnerabilities become public. Docker sits at a distinctive point in the supply chain, with millions of developers relying on us to build, distribute, and run software built on open source, so helping make that ecosystem more resilient is consistent with our mission. We look forward to working with the coalition on key ways in which Docker is uniquely placed to provide expertise and scale to this important cross-industry effort.

Further reading

Docker Sandboxes

Docker Hardened Images

Defending your software supply chain (Docker CISO Mark Lechner)

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

AWS DevOps Agent expands with custom SRE agents and MCP/A2A protocols

AWS DevOps Agent now supports custom SRE agents, bring-your-own sub-agents, and headless access via MCP and A2A protocols. These capabilities enable teams to automate recurring SRE workflows, extend DevOps Agent by connecting it to other agents, and access its capabilities from the tools they already use, including Kiro, Claude, and other coding assistants. With custom SRE agents, teams can create and schedule agents within Agent Spaces that run on a cadence. For example, create a daily database health report that checks for slow queries and parameters that need tuning, or build an agent that reviews logs from the past 24 hours and flags anomalies. In headless mode, developers can invoke DevOps Agent from the tools and agents they already use via A2A or MCP protocols. For example, the Kiro power for AWS DevOps Agent lets developers check production health and investigate issues without leaving their IDE. Teams can also connect their own sub-agents built with Amazon Bedrock or third-party frameworks via A2A to extend DevOps Agent capabilities. AWS DevOps Agent also introduces chat enhancements, incident-skip support based on customer-defined rules, enhanced knowledge with memories and Git-managed skills, human labeling and customer-created dashboards for tracking task quality, and is available in five new Regions. See all the latest AWS DevOps Agent features on the recent improvements page. For the list of AWS Regions where AWS DevOps Agent is available, see the supported Regions table.
Quelle: aws.amazon.com

AWS Lambda Managed Instances now supports Tag Propagation for Managed Resources

AWS Lambda Managed Instances (LMI) now supports tag propagation, enabling you to automatically apply tags to managed resources such as Amazon EC2 instances, Amazon EBS volumes, and Amazon ENIs. This helps you enforce cost allocation, service control policies (SCPs), and compliance requirements across all resources provisioned by your capacity providers.
LMI lets you run Lambda functions on managed EC2 instances with built-in routing, load balancing, and auto scaling, giving you access to specialized compute configurations including the latest-generation processors and high-bandwidth networking, with no operational overhead. Organizations that use resource tagging for cost tracking, governance, or security previously had no way to propagate tags to the underlying managed resources that LMI provisions on their behalf. This made it difficult to track costs accurately, enforce SCPs, or meet compliance standards that require approved tags on all resources. Now, with tag propagation, you can specify a set of tags on your capacity provider configuration, and LMI automatically applies those tags to all managed resources it creates. This ensures consistent tagging across your EC2 instances, EBS volumes, and ENIs without requiring manual intervention or custom automation.
This feature is available in all AWS commercial Regions where LMI is generally available. To get started, configure the PropagateTags setting on your capacity provider using the CreateCapacityProvider or UpdateCapacityProvider APIs. Set the mode to Explicit and provide your desired tags as key-value pairs. Tag propagation applies to all new managed resources provisioned after the configuration is applied. You can configure these settings using the AWS Management Console, AWS CLI, AWS CloudFormation, AWS CDK, or AWS SAM. To learn more, visit the AWS Lambda Managed Instances product page and documentation.
Quelle: aws.amazon.com

AWS launches Cost Explorer historical data retention for accounts in billing groups

Today, AWS announces Cost Explorer historical data retention for accounts in billing groups.  
Customers can use AWS Billing Conductor and Billing Transfer to map accounts to billing groups, enabling them to view billing data priced at the pro forma rates supplied by the payer account or Bill-Transfer account. Previously, the billing group configuration resulted in restricted access to historical billing data (priced at AWS billable rates) for accounts mapped to billing groups.
With this launch, accounts included in billing groups retain access to their historical billing data in Cost Explorer at their original billable rates. Accounts previously on-boarded to Billing Conductor and Billing Transfer will gain access to their historical data with no additional action required. This enables reporting continuity for customers opting into AWS Billing Conductor and Billing Transfer.
Billing Transfer is available today in all AWS Regions, excluding the GovCloud, China (Beijing) and China (Ningxia) Regions.
To learn more about using Billing Transfer to centralize billing and cost management across your multi-organization environment, visit Billing Transfer product page, AWS Billing documentation, AWS Cost Management documentation, and news blog.
Quelle: aws.amazon.com

Amazon ECS Express Mode is now available in AWS GovCloud (US) Regions

Amazon Elastic Container Service (Amazon ECS) Express Mode is now available in the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions. ECS Express Mode empowers developers to rapidly launch containerized applications, including web applications and APIs, making it easy to orchestrate and manage cloud architecture while maintaining full control over infrastructure resources.
Every Express Mode service automatically receives an AWS-provided domain name, making your application immediately accessible without additional configuration. Applications using ECS Express Mode incorporate AWS operational best practices, serve either public or private HTTPS requests, and scale in response to traffic patterns. ECS Express Mode automatically consolidates up to 25 services behind a single Application Load Balancer, using intelligent rule-based routing to maintain isolation between services. All resources provisioned by ECS Express Mode remain fully accessible in your account, ensuring you never sacrifice control or flexibility. As your application requirements evolve, you can directly access and modify any infrastructure resource, leveraging the complete feature set of Amazon ECS and related services without disruption to your running applications.
To get started, provide your container image and ECS Express Mode deploys your application and auto-generates a URL. ECS Express Mode is available at no additional charge, you pay only for the AWS resources created to run your application. To deploy, use the Amazon ECS Console, SDK, CLI, CloudFormation, CDK, and Terraform. For more information, see the AWS News blog, or the documentation.
Quelle: aws.amazon.com