All news with #container security tag

📈 Amazon Elastic Container Service now publishes container health status as a new CloudWatch Container Insights metric. When a task defines a container health check, Container Insights emits UnHealthyContainerHealthStatus (0 = HEALTHY, 1 = UNHEALTHY) and includes health-state details in EMF logs during UNKNOWN evaluations. The metric is available at cluster, service, task, and container dimensions, and customers can create CloudWatch alarms to notify teams of unhealthy containers.

⚠️ Check Point Research says VoidLink, a modular Linux malware framework, appears to have been planned, structured, and largely written by AI rather than solely by human developers. Analysts found programmatically generated sprint-style plans, detailed technical specifications, and repetitive code patterns consistent with automated generation. The project reportedly grew to tens of thousands of lines of code in under a week, compressing months of work into days. That speed and planning raise concerns that AI can significantly lower the barrier to producing sophisticated, cloud- and container-focused threats.

📦 Amazon Elastic Container Registry (ECR) now supports cross-repository layer sharing via a capability called blob mounting. By enabling this registry-level setting through the ECR console or AWS CLI, teams can reuse identical image layers across repositories to accelerate image pushes and reduce duplicate storage. Blob mounting is available in all AWS commercial and AWS GovCloud (US) Regions and is applied automatically during image push operations.

🛡️ Researchers at Check Point disclosed VoidLink, a sophisticated modular malware framework targeting Linux servers and containers in cloud environments. Written primarily in Zig with supporting components in Go, C, and JavaScript, the platform uses a two-stage loader and an extensible plugin ecosystem (37 built-in modules) delivered via a professional web-based C2 dashboard to harvest credentials and access source code systems. It detects major cloud providers and container runtimes, adapts evasion strategies based on detected EDR and kernel hardening, and employs rootkits and covert C2 channels to maintain stealthy, long-term access.

🔍 A newly identified cloud-native Linux malware framework named VoidLink targets modern cloud and container environments, providing custom loaders, implants, rootkits, and memory-loaded plugins. According to Check Point, it is written in Zig, Go, and C and adapts behavior based on Kubernetes, Docker, and cloud metadata queries. Communications can use HTTP, WebSocket, DNS tunneling, or ICMP encapsulated in a custom encrypted layer VoidStream, and the framework includes extensive anti-forensics and runtime protections. Analysts assess it appears under active development and may be a commercial or customer-targeted framework rather than evidence of a current widespread campaign.

🛡️ Check Point Research describes VoidLink, a cloud-native Linux malware framework built to maintain long-term, stealthy access to cloud infrastructure rather than targeting individual endpoints. Its modular, plug-in-driven design enables attackers to extend capabilities over time while remaining quiet. Adaptive stealth allows the framework to alter behavior based on defensive visibility, prioritizing evasion in monitored environments and speed where visibility is limited.

🛡️ Check Point Research disclosed a previously undocumented Linux malware framework named VoidLink, designed for long-term stealthy access to cloud and container environments. The cloud-native toolkit is highly modular, written in Zig, and comprises custom loaders, implants, rootkits, and an in-memory plugin system with more than 30 modules. It supports diverse C2 channels (HTTP/HTTPS, WebSocket, ICMP, DNS), peer-to-peer mesh networking, and automated cloud discovery across AWS, GCP, Azure, Alibaba, and Tencent. Check Point assesses the framework as actively maintained and attributes it to China-affiliated actors, warning of significant credential-theft and supply-chain risks for cloud-native ecosystems.

🔒 Chainguard’s quarterly pulse, The State of Trusted Open Source, analyzes anonymized usage and CVE data across a large customer base and catalog of container images to reveal where real production risk concentrates. The report finds Python leading the modern AI stack, while roughly half of production runs on a diverse longtail of images beyond the top 20. Importantly, 98% of remediated CVE instances occurred in that longtail, and compliance drivers like FIPS adoption materially influence image choices. Chainguard also highlights fast remediation performance, averaging under 20 hours for Critical CVEs.

🐳 Docker has open-sourced and made freely available over 1,000 Docker Hardened Images (DHI) under the Apache 2.0 license to provide a secure, minimal foundation for containerized applications. The images are rootless, stripped of unnecessary components, SBOM-verifiable, and shipped with SLSA Build Level 3 provenance and proof of authenticity. Docker will continue to publish fixes for DHI components while reserving a 7-day critical CVE patching SLA for the commercial DHI Enterprise tier. The full DHI catalog and subscription options are available from Docker's product offerings.

🔁 Amazon Elastic Container Registry (ECR) can now automatically create repositories when images are pushed, removing the need to pre-create repositories before a push. Repository creation follows organization-defined repository creation templates, enabling consistent naming and default settings at creation. The create-on-push capability is available in all AWS commercial and AWS GovCloud (US) Regions.

🛑 Amazon Elastic Container Service (ECS) on AWS Fargate now honors container-defined stop signals for Linux tasks by reading the OCI image STOPSIGNAL instruction and sending that signal when a task is stopped. Previously Fargate always sent SIGTERM followed by SIGKILL after the configured timeout, but containers that rely on SIGQUIT, SIGINT, or other signals can now receive their intended shutdown signal. If no STOPSIGNAL is present, ECS continues to default to SIGTERM. Support for container-defined stop signals is available in all AWS Regions and the ECS Developer Guide provides implementation details.

📦 Amazon Web Services announced a new Amazon ECR Archive storage class to lower costs for large volumes of rarely accessed container images. Lifecycle policies can now archive images by last pull time, age, or count, and archived images are excluded from repository image limits. Archived images are inaccessible for pulls but can be restored via Console, CLI, or API within about 20 minutes, and all operations are logged to CloudTrail; the feature is available in AWS Commercial and GovCloud (US) Regions.

🔒 Amazon Web Services announced that Amazon ECR now supports PrivateLink endpoints validated under FIPS 140-3. This allows customers with security and compliance requirements to use FIPS-validated cryptographic modules while keeping traffic private within their Amazon VPCs. The enhancement helps organizations meet regulatory obligations without exposing container registry traffic to the public internet. Availability includes several commercial and AWS GovCloud regions.

⚠ Three high-severity vulnerabilities in the runc container runtime allow attackers to escape containers and gain host-level privileges by abusing masked paths, console bind-mounts, and redirected writes to procfs. Aleksa Sarai of SUSE and the OCI described logic flaws that let runc mount or write to sensitive /proc targets, including /proc/sys/kernel/core_pattern and /proc/sysrq-trigger. Patches are available in runc 1.2.8, 1.3.3 and 1.4.0-rc.3; administrators should update promptly, favor rootless containers where feasible, and monitor for suspicious symlink behaviour.

⚠️ Three newly disclosed vulnerabilities in runC (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) could allow attackers to bypass container isolation and obtain root write access on the host. The issues involve manipulated bind mounts and redirected writes to /proc, and one flaw affects runC releases back to 1.0.0-rc3. Patches are available in recent runC releases; administrators should update, monitor for suspicious symlink/mount activity, and consider enabling user namespaces or running rootless containers as mitigations.

🔐 Amazon Elastic Container Service (ECS) now supports mounting Amazon EBS volumes to containers running as non-root users. ECS automatically sets file system permissions on the attached EBS volume so non-root processes can securely read and write while preserving root ownership. This removes the need for manual chown/chmod or custom entrypoint scripts, simplifying security-first container deployments. The capability is available across all AWS Regions for EC2, AWS Fargate, and ECS Managed Instances.

🔍 Amazon ECS Service Connect now captures per-request telemetry with Envoy access logs to improve visibility into service-to-service traffic for tracing, debugging, and compliance. Access logging is enabled via the ServiceConnectConfiguration and emits Envoy logs to STDOUT alongside application logs, flowing through the existing ECS log pipeline without extra infrastructure. Query strings are redacted by default and the feature supports HTTP, HTTP/2, gRPC, and TCP protocols. The capability is available in all regions where Service Connect is supported.

🔍 Amazon ECS now emits AWS CloudTrail data events for ECS Agent API activities, giving teams detailed visibility into container instance operations. Customers can opt in to the new data event resource type AWS::ECS::ContainerInstance to capture actions such as ecs:Poll, ecs:StartTelemetrySession, and ecs:PutSystemLogEvents. The capability is available for ECS on EC2 across all AWS Regions and for ECS Managed Instances in select regions. Standard CloudTrail data event charges apply.

🔐 Dataproc 2.3 on Google Compute Engine provides a streamlined image that includes only the essential core components for Spark and Hadoop, reducing the attack surface and simplifying compliance. The image is FedRAMP High compliant and leverages both automated CVE remediation and manual engineering intervention for complex fixes. Optional tools like Flink, Hudi, Ranger, and Zeppelin are available on-demand during cluster creation, or can be pre-baked into custom images to speed provisioning while preserving the security benefits of the lightweight base.

🔒 Amazon Elastic Container Service (Amazon ECS) now lets you run Firelens containers as a non-root user by specifying a numeric user ID in the user field of your Task Definition. Running Firelens as non-root reduces the potential attack surface and helps meet security and compliance requirements, including checks surfaced by AWS Security Hub. This capability replaces the previous default of "user": "0" and is available in all AWS Regions. See the Firelens documentation for configuration details.