The patch window is collapsing: Why security needs a new control plane

For decades, cybersecurity defenders have relied on a relatively straightforward model: a vulnerability is disclosed, security teams assess exposure, test available fixes, deploy patches into production, and ultimately close the risk before attackers can exploit it at scale. 

That model increasingly reflects a world that no longer exists.

Today’s enterprises operate thousands of interconnected workloads across hybrid and multicloud environments. Mission-critical applications power revenue-generating services, customer experiences, and core business operations that cannot simply be taken offline whenever a security update becomes available. At the same time, vulnerabilities are becoming more visible, more widely distributed, and more rapidly weaponized than ever before.

The result is a growing gap between how quickly organizations can safely remediate vulnerabilities and how quickly adversaries can exploit them. It is time to rethink how the industry approaches security during the critical period between disclosure and remediation. 

The patch window has collapsed 

Traditional vulnerability management was built on the assumption that defenders could move faster than attackers. In many cases, they could.

When a vulnerability was disclosed, organizations had time to understand the issue, assess affected systems, test patches, coordinate change windows, and deploy fixes before widespread exploitation occurred.

Today that timeline is rapidly shrinking.

Modern attack campaigns operate at internet scale. Security research, public disclosures, proof-of-concept exploits, and threat intelligence circulate globally within hours. A vulnerability announced in the morning can become the focus of active scanning and exploitation efforts by the afternoon.

Meanwhile, the operational realities of enterprise environments have not changed. Organizations still must: 

Understand the vulnerability and its business impact. 

Identify affected systems across large estates. 

Evaluate dependencies and compatibility concerns. 

Validate fixes in test environments. 

Coordinate deployment schedules. 

Monitor for regressions and operational risk. 

These are not signs of inefficiency. They are necessary safeguards for business-critical environments. The challenge is that while defensive processes continue to require days or weeks, offensive timelines are increasingly measured in hours. 

That creates one of the most dangerous periods in modern cybersecurity: the window between awareness and remediation.

AI is expanding the defender’s challenge 

AI is helping organizations modernize operations, accelerate development, and improve security outcomes. But the same technological advances are also changing the economics of offensive operations.

Historically, transforming a newly disclosed vulnerability into an effective attack often required extensive manual research and deep technical expertise. Security researchers and attackers alike needed to analyze documentation, understand exploit conditions, study affected software, and develop attack techniques.

Many of those steps can now be accelerated.

AI-assisted workflows can help analyze vulnerability disclosures, identify likely attack paths, evaluate technical dependencies, and summarize complex technical information far more quickly than traditional manual processes.

As these capabilities become more accessible, the timeline between disclosure and exploitation continues to compress. The result is a structural imbalance. 

Defenders remain responsible for protecting entire environments that may include thousands of servers, applications, databases, containers, and network assets. Attackers only need to identify a single viable path to exploitation. 

This asymmetry is driving organizations to ask an increasingly important question: What happens before the patch is deployed?

Why existing security approaches fall short 

The security industry has invested heavily in improving visibility.

Organizations today have access to more vulnerability data, threat intelligence, analytics, and detection capabilities than ever before. Security platforms can rapidly identify affected systems, prioritize remediation, and alert defenders to emerging threats.

These capabilities are essential. But awareness alone does not reduce exposure. Many organizations find themselves in a position where they know exactly which systems are vulnerable but cannot immediately patch them. 

For example, a business-critical application may require extensive validation before updates can be deployed. A manufacturing system may depend on software that cannot be taken offline during production hours. A regulated environment may require additional testing and approval processes before changes can be implemented.

In these situations, the challenge is not identifying risk. The challenge is reducing risk while remediation is still underway.

Visibility, detection, and prioritization help organizations understand the problem. They do not necessarily provide a mechanism for containing that risk immediately.

As attack timelines continue to compress, the industry needs a complementary approach focused on exposure reduction rather than simply exposure awareness.

Why the network is emerging as the fastest control plane 

When a workload cannot immediately defend itself, another layer must help provide protection. Increasingly, organizations are looking to the network. 

Unlike endpoint-based controls, network-level protections operate around workloads rather than inside them. This distinction becomes particularly important during periods of elevated risk.

The network already understands communication patterns, connectivity requirements, trust relationships, and traffic flows. It sits at a strategic position where organizations can influence how systems interact with one another without necessarily modifying the applications themselves.

This creates opportunities to reduce exploitability while remediation efforts are underway. Network-enforced protections can help: 

Restrict access to vulnerable systems. 

Limit exposure to potential attack paths. 

Reduce opportunities for lateral movement. 

Segment high-risk assets. 

Contain potential blast radius. 

Adjust controls dynamically as new information becomes available. 

Perhaps most importantly, network controls can often be implemented significantly faster than enterprise software patches can be validated and deployed.

The objective is not to avoid patching. The objective is to create a meaningful layer of defense during the period when patching has not yet been completed.

As AI compresses the time between vulnerability disclosure and exploitation, organizations need a defensive layer that can act immediately, without waiting for every workload to be patched, every application to be modified, or every endpoint agent to understand a new threat.

The network is uniquely positioned to become that control point: it already sits in the path of communication, has visibility across heterogeneous workloads, and can enforce protections consistently across large cloud estates without changing the applications themselves. More importantly, network controls can increasingly move beyond simple IP, port, and signature-based blocking toward context-aware, adaptive enforcement that constrains the specific behavior an exploit depends on while preserving legitimate traffic.

Consider an HTTP/2 denial-of-service vulnerability: the safest interim guidance may be to disable HTTP/2 entirely until systems are patched, but that can carry significant application and performance impact. A more precise network and workload-aware response could instead bound the exploitable behavior—limiting concurrent streams, tightening request constraints, or rate-limiting abusive connection patterns—while keeping the service available. This is why the network is becoming more than a connectivity layer: it can serve as a programmable, ubiquitous enforcement fabric that buys organizations the most valuable commodity during a zero-day—the time to patch safely.

In an era where vulnerabilities may be weaponized within hours, every day of risk reduction matters.

The rise of adaptive security 

The next evolution of cybersecurity is unlikely to rely solely on static policies or manual response processes. Modern environments are simply too large, dynamic, and interconnected. 

Organizations increasingly need security systems capable of understanding risk, evaluating context, and adapting protections as conditions change. This shift points toward a broader industry trend: adaptive security. 

Adaptive security systems aim to move beyond predefined rules toward continuously improving risk management. Rather than treating every vulnerability equally, they seek to understand the specific conditions that make a flaw exploitable and determine the most effective way to reduce exposure. At a high level, these systems must solve three critical challenges. 

First, they must understand the vulnerability itself. 

This requires ingesting information from security advisories, vulnerability disclosures, threat intelligence, exploit research, and other sources to develop a meaningful understanding of how a threat operates.

Second, they must correlate that understanding with real-world environments. 

A vulnerability only becomes a material risk when specific systems, configurations, connectivity paths, and exposure conditions exist. Understanding this context is essential to determining actual risk.

Third, they must translate intelligence into action. 

Insight without enforcement provides limited value. The ultimate goal is to reduce exposure through controls that can be applied quickly, consistently, and at scale.

AI is expected to play a significant role throughout this process, not merely as an analytical tool, but as an enabling technology that helps security systems understand complex relationships and make informed decisions faster than would otherwise be possible.

Looking at the future of cybersecurity

The cybersecurity industry has spent decades improving vulnerability management, patch deployment, and security operations. Those investments remain essential and will continue to be foundational elements of every organization’s security strategy. But the environment around us is changing.

Attackers are moving faster. Infrastructure is becoming more complex. AI is compressing timelines across the entire threat landscape. In this new reality, organizations cannot rely on patching alone. 

The future of cybersecurity will depend on an organization’s ability to reduce risk during the time between disclosure and remediation. Success will come from combining strong patch management practices with compensating controls capable of responding at machine speed.

The organizations that thrive will be those that treat security as a continuous, adaptive process rather than a sequence of point-in-time responses. The fundamental question is no longer whether vulnerabilities will emerge. They will. 

The question is how effectively organizations can protect themselves while they work to eliminate them.

As the patch window continues to collapse, the industry will need new approaches that complement traditional remediation strategies, reduce exposure quickly, and help defenders regain the one resource that has become increasingly scarce in modern cybersecurity: time.

Microsoft is investing in new and innovative capabilities able to provide immediate protection from the storm, buying organizations the time they need to safely validate and deploy a permanent patch without exposing their environment to unnecessary risk.
The post The patch window is collapsing: Why security needs a new control plane appeared first on Microsoft Azure Blog.
Quelle: Azure

Moving from Minimus to Docker Hardened Images

The hardened-images space gets better when more people are working on the problem, and Minimus has been a valuable part of that work. That changed this week, when they announced they are ending operations. Though we were competitors, we both believed strongly in the importance of reducing vulnerabilities at the foundation of the software supply chain. Their efforts to bring needed awareness to this challenge will be missed, and our thoughts go out to Minimus employees who are impacted by this decision.

While the human side of this story deserves the most attention, there’s also a practical side: if you’re a customer running Minimus images in production, you’re now facing a migration you didn’t plan for. Their notice commits to a 60-day maintenance window, with images receiving upstream updates until the registry goes offline on October 22, 2026. Images already pulled will keep running after that date, but no further updates will ship to them, and any new CVE stays unpatched from that point on.

If you need a hand, Docker is offering free migration assistance to Minimus customers. Write to minimus@docker.com to walk through your specific image list, your compliance requirements, or questions around your migration plans, and a technical migration expert will get back to you. You don’t need a sales call to start migrating to DHI today.

Docker’s free, open source catalog is available to everyone under Apache 2.0, allows production use, and has no user caps. The migration is about as easy as these things get, a drop-in with minimal workflow changes. It’s more of a swap than a rebuild. It’s easy to find your images’ equivalents in the DHI catalog, and for most of your services, the whole change is updating the FROM line. Use the migration guide for the step-by-step process and the checklist to track each image through the swap and verification. The worked examples show full migrations end to end, and Gordon, Docker’s AI assistant, runs the first pass with you.

Whether you decide to migrate to Docker or somewhere else, we recommend you start that process now, while the maintenance window keeps your current images patched. You can browse the full DHI catalog on Docker Hub, make the first swap, and, of course, reach out to us if you need help.

Docker Hardened Images

Docker Hardened Images are minimal, hardened images built from source and continuously maintained by Docker. The catalog covers 4,000+ images, compatible with Alpine and Debian, so your Dockerfiles and CI keep working as they are. Every image ships near-zero CVEs with full, unsuppressed CVE visibility, and each carries a complete SBOM, SLSA Build Level 3 provenance, and cryptographic signatures. Docker manages the full lifecycle of your image, and teams moving from standard public images see up to 95% CVE reduction and up to 90% attack-surface reduction. Paid tiers add SLA-backed remediation, FIPS and STIG variants, customizations, and up to five years of coverage for versions past end of life.

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

AWS Lambda MicroVMs now supports AWS PrivateLink

AWS Lambda MicroVMs now supports AWS PrivateLink, enabling private connectivity to Lambda MicroVMs directly from Amazon Virtual Private Cloud (VPC) resources without exposing traffic to the public internet. This launch helps regulated workloads in financial services, healthcare, and government meet strict network isolation requirements when building with Lambda MicroVMs. 
PrivateLink VPC Endpoints deliver private connectivity to AWS services from your VPC, ensuring that your traffic does not travel over the public internet when communicating with AWS services. Today’s launch extends this capability to Lambda MicroVMs. Developers and IT teams needing private connectivity to Lambda MicroVMs can now create PrivateLink VPC Endpoints in their VPC to call MicroVM APIs (for example, to create MicroVM images or launch MicroVMs) and to connect to each MicroVM’s HTTP endpoint.
PrivateLink VPC Endpoints for Lambda MicroVMs can be created using the AWS Management Console, AWS CLI, AWS CloudFormation, or the AWS SDKs. This feature is supported in all Regions where Lambda MicroVMs is available. Visit the AWS Capabilities by Region page for the latest region availability.  
To learn more about using PrivateLink with Lambda MicroVMs, see the developer guide. For pricing details, see AWS PrivateLink Pricing. To learn more about configuring private connectivity for AWS services, visit the AWS PrivateLink developer guide. 
 
Quelle: aws.amazon.com

Capacity Reservation Resource Groups now support Amazon EC2 Capacity Blocks and interruptible Capacity Reservations

Starting today, you can add Amazon EC2 Capacity Blocks for ML and interruptible Capacity Reservations to Capacity Reservation Resource Groups. Amazon EC2 offers different reservation offerings such as On-Demand Capacity Reservations (ODCRs), interruptible Capacity Reservations, and Capacity Blocks for ML. Previously, a Capacity Reservation Resource Group could only include ODCRs. Now you can add any type of Capacity Reservation to a Capacity Reservation Resource Group, making it easier to launch EC2 instances across your entire portfolio of reserved capacity.
To use this feature, create a Capacity Reservation Resource Group, add any Capacity Reservation to it, and then target the group in your launch request. When using EC2 Fleet and EC2 Auto Scaling groups, you can also specify your prioritization preferences across reservation types, and configure automatic fall back to EC2 On-Demand capacity when there is no capacity remaining across your reservations.
There are no additional charges for using this feature. This feature is available in all AWS Regions where Capacity Blocks for ML and interruptible ODCRs are supported, excluding AWS GovCloud (US) and China Regions. To get started, see Capacity Reservation Resource Groups and the Capacity Reservations user guide.
Quelle: aws.amazon.com

AWS Batch now supports Amazon ECS Managed Instances

AWS Batch now supports Amazon ECS Managed Instances (ECS MI) as a new compute option, enabling you to run GPU-accelerated and compute-intensive batch workloads on AWS-managed infrastructure. With AWS Batch on ECS MI you can now access GPU-accelerated instances while AWS handles AMI updates, security patching, and instance lifecycle automatically, eliminating the operational overhead of customer-managed Amazon EC2 infrastructure. To get started, create an AWS Batch on ECS MI compute environment using the AWS Batch CreateComputeEnvironment API or the AWS Batch Management Console. You can specify your allowed instance types and networking configuration in the managedInstancesProvider block, associate the compute environment with a job queue, and submit jobs using On-Demand, Spot, or reserved capacity. AWS Batch on ECS Managed Instances is supported in all AWS Regions where AWS Batch is available. For more information, see the AWS Batch User Guide.
Quelle: aws.amazon.com

AWS IoT Core now supports native InfluxDB routing for time-series data

AWS IoT Core now supports InfluxDB rule action that routes time-series data from your Internet of Things (IoT) devices directly to InfluxDB databases, without writing custom device-side code or using intermediate cloud services. AWS IoT Core is a fully managed service that securely connects billions of IoT devices to the AWS cloud, and routes IoT device data to AWS and third-party services.
The new InfluxDB rule action automatically converts time-series data from your device to InfluxDB’s line protocol format and writes it to either an Amazon Timestream managed or a self-hosted InfluxDB cluster. The new rule action also supports the following two batching modes to help you optimize cost and throughput: device-side batching, where your devices send pre-batched payloads to AWS IoT Core; and server-side batching, where IoT rules engine aggregates individual messages before writing to InfluxDB. For example, a life sciences company can batch thousands of telemetry readings from scientific instruments at millisecond granularity and write directly to InfluxDB for monitoring, without building a custom data pipeline.
To get started, connect your IoT devices to AWS IoT Core and define an InfluxDB rule action specifying the destination database, along with authentication and batching parameters. The InfluxDB rule action is available in all AWS Global Regions where Amazon Timestream for InfluxDB is available. To learn more, visit the AWS IoT Core developer guide.
Quelle: aws.amazon.com