Mondoo Release Highlights June 2026

Back to releases

Introduction

Plenty of tools can tell you what's misconfigured. The harder question, the one that actually decides your risk, is what an attacker can reach. That's where June's headline work landed. Mondoo now sees internet exposure the way an attacker does: not just whether something is set to public, but whether it's genuinely reachable, across every major cloud. The payoff is fewer false alarms and a clear view of the assets that can really be touched.

We also widened how much of your stack Mondoo can secure. You can now inspect the AI infrastructure running inside your clouds, secure six brand-new platforms, and write custom policy against your clouds, Kubernetes, and infrastructure as code far more easily, all on top of 145 new built-in security checks. Let's dive in.

Smarter Internet Exposure Detection

The riskiest findings are the ones an attacker can actually reach. A resource that's configured as public isn't always reachable, and one that looks private can be exposed through a chain of security groups, load balancers, and routes. This month we heavily expanded on our detection of internet exposure across clouds and other resources.

Exposure you can query directly

We greatly expanded Mondoo's MQL capabilities so that, in a single query, you can tell both whether a resource is configured to be public and whether it's genuinely reachable from the internet. You no longer parse raw security-group rules, route tables, and resource policies yourself, because new building blocks do it for you across the clouds:

• An exposure breakdown on internet-facing assets: Compute instances, databases, and load balancers across AWS, Azure, Google Cloud, OCI, DigitalOcean, and Hetzner now expose an exposure field that combines the public signal (a public IP, an internet-facing scheme, or a publicly-accessible flag) with the security-group or firewall ingress rules that actually open it, so you see not just that something is exposed but how.
• A simple internetReachable flag: Many resources, including AWS EC2 instances, RDS, and Redshift, Azure VMs and SQL, MySQL, and PostgreSQL servers, Google Cloud SQL, OCI Autonomous Database, and DigitalOcean databases, now answer "is this truly reachable from the internet?" as a single boolean that's only true when a public endpoint is paired with permissive ingress.
• Resource-policy isPublic and public-access predicates: Data services exposed through IAM or resource policies, such as AWS S3, ECR, KMS, Lambda, SNS, SQS, OpenSearch, EFS, and Secrets Manager, Google Cloud Storage buckets, BigQuery tables, and Cloud Functions, and Azure Storage, now flag public access directly, so you catch data exposed by policy, not just by network.

A normalized network-exposure resource on each cloud ties this together for fleet-wide exposure queries.

This pays off twice:

• Fewer false positives: Separating "public by configuration" from "actually reachable" filters out exposures that look alarming but can't be hit, so your team focuses on the ones that genuinely matter.
• Custom exposure policies are easy to write: The same fields that power Mondoo's built-in analysis are available to you, so writing your own checks, such as "nothing internet-reachable should be unencrypted," is straightforward.

Exposure baked into the risk score, on more platforms

Mondoo's internet-exposed risk factor moved from asking "is this configured to be public?" to "is this genuinely reachable?", and we extended it to many more platforms and asset types. When a resource is truly reachable from the internet, its risk score rises accordingly, so the assets an attacker can actually touch float to the top of your queue.

• More platforms: Exposure now feeds the risk score across AWS, Azure, Google Cloud, OCI, DigitalOcean, Hetzner, OpenStack, and STACKIT, plus Kubernetes network exposure.
• More asset types: On AWS, Azure, and Google Cloud, reachability-aware exposure now spans databases, container registries, serverless functions, key and secret stores, and managed Kubernetes control planes, surfacing exposed resources Mondoo couldn't flag before.

What's next: attack path analysis

Knowing what's reachable is the foundation. The next question is what an attacker does with it: which exposed asset, which CVE, and which misconfiguration chain together into a path to the data and systems that matter most.

That's what we're building next, right inside the platform. You'll trace the exact route from an internet-reachable entry point to your critical assets, and see the real risk each CVE and misconfiguration carries in the context of that path. Instead of triaging thousands of findings one by one, you'll focus on the handful that actually open a door for an attacker.

There's a lot more coming here. Stay tuned.

Inspect AI Infrastructure Across Your Clouds

AI workloads are moving into production inside the clouds you already run, and they bring new attack surface: agents with tool access, knowledge bases full of sensitive data, model endpoints, and the credentials that tie them together. This month Mondoo adds resources across every major cloud that expose AI workload configuration, so you can author custom policies to secure your AI infrastructure the same way you secure the rest of your environment.

• AWS (22 new resources): Amazon Q Business (applications, indexes, data sources, retrievers, plugins, and web experiences) and a deep Bedrock expansion, including agent aliases, inference profiles, imported models, managed prompts, and the full Bedrock AgentCore stack (gateways, runtimes, memory, browser and code-interpreter tools, OAuth2 and API-key credential providers, and workload identity).
• Google Cloud (19 new resources): A broad Vertex AI expansion covering Agent Engine reasoning engines, Colab Enterprise notebooks, RAG corpora, feature groups, managed Ray clusters, fine-tuning and training jobs, batch prediction, context caches, and deployment monitoring, plus Discovery Engine data stores and engines. Many Vertex AI resources now also expose their customer-managed KMS key, run-as service account, and VPC network, so you can check encryption, identity, and network isolation directly.
• OCI (31 new resources): A complete OCI AI namespace spanning Generative AI (dedicated clusters, models, and endpoints), AI Agents (agents, endpoints, knowledge bases, data sources, and tools), Data Science (projects, notebooks, models, deployments, jobs, and pipelines), and the Language, Vision, Speech, and Document AI services.
• DigitalOcean (17 new resources): Full GradientAI coverage, including agents with their guardrails, functions, versions, and API keys, models and custom models, knowledge bases and data sources, indexing and batch jobs, dedicated inference endpoints, and the Anthropic and OpenAI API keys wired into the platform.
• Azure: Azure AI Foundry and Cognitive Services projects, model deployments, and connections to external models, data sources, and tool servers (with network ACL defaults), plus Azure Machine Learning online and serverless endpoints, deployments, compute, and models.

Together these let you bring your cloud AI infrastructure, including agents, models, knowledge bases, endpoints, and the identities and keys behind them, under the same policy-driven security as everything else you run.

New Integrations and Platforms

June brings six brand-new things you can secure with Mondoo, from SaaS integrations to private-cloud platforms and network gear.

New integrations

Two brand-new integrations, each a complete package: connect it in the Mondoo App, scan it from the command line with cnspec, and harden it with an out-of-the-box security policy.

• NextDNS: Bring your NextDNS configuration under continuous security assessment. Scan it with cnspec and harden it with the new Mondoo NextDNS security policy.
• Tailscale: Assess your tailnet alongside the rest of your environment, with cnspec scanning and the Mondoo Tailscale security policy out of the box.

New platform coverage

Brand-new support for four more platforms, each a complete package: scan from the command line with cnspec and harden with an out-of-the-box security policy.

• STACKIT: Bring your STACKIT sovereign cloud under continuous security assessment across compute, storage, databases, networking, and IAM. Ships with the new Mondoo STACKIT Security policy (31 checks).
• Nutanix: Assess your Nutanix private cloud, including clusters, hosts, VMs, identity, and storage managed through Prism Central. The new provider models 28 Nutanix resources and ships with the new Mondoo Nutanix Security policy (28 checks).
• MikroTik RouterOS: Scan your MikroTik routers, switches, and access points for misconfigurations and hardening gaps. Ships with the new Mondoo MikroTik RouterOS Security policy (16 checks).
• Portainer: Audit your Portainer container-management control plane, the security posture Docker itself can't see. Scan it with cnspec to inspect authentication and password settings, users and teams, managed environments and their access policies, edge groups and stacks, and licensing, and harden it with the new Mondoo Portainer Security policy (15 checks).

Deeper Security Coverage Across Your Clouds

Attackers don't wait for you to finish adopting a new service. As your teams reach for more of what each cloud and platform offers, the gaps that lead to breaches (resources exposed to the internet, data left unencrypted, identities with more access than they need) spread into corners that weren't being checked yet. This month we expanded our existing security policies to keep pace, adding 145 new checks across the platforms you already scan, on top of the brand-new policies above.

The new checks concentrate on the failures that cause real incidents:

• Internet exposure: New "not internet-reachable" checks flag databases, load balancers, and compute that shouldn't be open to the world, across AWS, DigitalOcean, and Hetzner, alongside tighter security-group and DNS-firewall rules.
• Encryption everywhere: Customer-managed and at-rest and in-transit encryption checks now span OCI databases, volumes, and file storage, GCP images and snapshots, Azure snapshots, and VMware vSAN, along with key rotation and HSM-backed key management.
• Identity and access: New checks catch stale service accounts, over-broad RBAC, weak password and MFA policy, and missing key rotation across GCP, OCI, OpenStack, and Kubernetes.
• Broader service coverage: Scanning now reaches newer services your teams are adopting, including Azure IoT Hub, GCP Pub/Sub, Firestore, Cloud Run, and Vertex AI, OpenStack Magnum, Trove, and Manila, and DigitalOcean GradientAI.

Here's where the new checks landed:

• Azure Security: 27 new checks
• GCP Security: 24 new checks
• OpenStack Security: 16 new checks
• AWS Security: 15 new checks
• DigitalOcean Security: 13 new checks
• Arista NDM STIG: 12 new checks
• OCI Security: 11 new checks
• Kubernetes Security: 6 new checks
• Linux Security: 5 new checks
• UniFi Security: 5 new checks
• Hetzner Security: 4 new checks
• Dockerfile Security: 3 new checks
• Shodan: 2 new checks
• VMware vSphere: 2 new checks

The result: more of your environment is evaluated the moment you connect it, with the heaviest focus on the exposures and encryption gaps attackers probe for first.

Beyond the new checks, cloud resources now carry far more provenance, so you can see where each one came from and who owns it:

• AWS: Resources report how they're managed (a managedBy signal inferred from provenance tags such as CloudFormation, Elastic Beanstalk, and EKS) and link to the CloudFormation stack that owns them. EC2 images, snapshots, and volumes expose their lineage, the instance, image, or volume they were created from, while S3 buckets, KMS keys, IAM roles, and SNS topics surface IAM Access Analyzer findings for anything shared externally.
• Azure: Nearly every resource now carries creation and last-modification provenance recorded by Azure Resource Manager, and images record the virtual machine they were captured from.
• Google Cloud: Container Analysis exposes full build provenance and attestations (who built an artifact, when, with which commands, and the signatures that verify it), and instance templates and snapshots resolve the resource they derived from.
• OCI: Buckets record the principal that created them, and volumes, boot volumes, images, file systems, and databases expose their clone and backup lineage.

That makes it far easier to attribute a risky resource to its owner and trace exactly how it came to exist.

Expanded On-Prem Cloud Coverage

Your on-prem and private cloud infrastructure deserves the same depth as the hyperscalers. This month we substantially expanded both the OpenStack and VMware vSphere providers, adding dozens of new resources and fields, and shipped new checks in both security policies on top of them.

OpenStack

The OpenStack provider gained 30 new resources, reaching far more of your private cloud:

• Identity and access (Keystone): New credentials, EC2 credentials, trusts (with re-delegation), services, endpoints, regions, role assignments, and role inference rules. Users now expose whether multi-factor authentication is required, along with the MFA rules that apply.
• More OpenStack services: Manila shared file systems (shares, access rules, security services, and share networks), Magnum container clusters and templates, Trove databases, Ironic bare-metal nodes and ports (with owner and lessee), Heat orchestration stacks, and Placement resource providers.
• Network exposure and isolation: New per-server and per-load-balancer internet-exposure summaries, security groups that flag public ingress, rules that classify public sources, Octavia listeners open to the world, load balancers that report whether they enforce TLS, Neutron RBAC policies, and full VPNaaS coverage (services, IKE and IPsec policies, endpoint groups, and site-to-site connections).
• Image integrity, quotas, and ownership: Glance image signatures and integrity hashes, Nova and Cinder quotas and QoS specs, and project and user ownership across servers, ports, routers, subnets, and more.

VMware vSphere and ESXi

The vSphere provider gained 20 new resources and a large set of new fields, with a strong focus on ESXi host hardening and vCenter governance:

• ESXi host hardening: New host security (TPM key persistence and the trusted certificate store), SSH daemon configuration, TLS server profile, lockdown-mode exceptions, account lockout thresholds, shell, SSH, and DCUI idle timeouts, Managed Object Browser state, syslog destinations, and transparent-page-sharing salting.
• vSAN: New cluster-level and host-level vSAN configuration and disk groups.
• vCenter governance and audit: Tags and categories across the inventory, content libraries, custom fields, alarm definitions and currently triggered alarms, scheduled tasks, recent tasks, events, certificates, advanced settings, the SSO account-lockout policy, and remote syslog forwarding.
• Networking: Distributed-switch port-mirroring (SPAN) sessions, vSwitch and port-group MAC management policies, and port-config reset-at-disconnect.
• Operational state: Host boot time, maintenance mode, and pending-reboot detection.

These expansions also power new checks in the Mondoo OpenStack and VMware vSphere security policies, counted in the per-policy breakdown above.

Simpler, Deeper Kubernetes Querying

Last month we rebuilt the Kubernetes provider so workload settings read like the concepts they describe. This month we went further on two fronts: high-level, security-aware fields on nearly every Kubernetes resource, and a complete model of cluster network posture contributed by the community.

Ask the security question directly, skip the YAML

Pulling a security signal out of a Kubernetes workload used to mean walking nested securityContext maps across regular, init, and ephemeral containers. Now you can ask the question directly. Workloads (Deployments, DaemonSets, StatefulSets, ReplicaSets, Jobs, CronJobs, and Pods) expose high-level fields, each already evaluated across every container type:

• Pod security posture: runsPrivileged, runsAsRoot, allowsPrivilegeEscalation, hasWritableRootFilesystem, dropsAllCapabilities, usesHostNamespaces, usesUnconfinedSeccomp, and usesUnconfinedAppArmor, plus rollups like meetsPodSecurityBaseline and meetsPodSecurityRestricted against the Pod Security Standards.
• Image hygiene: usesLatestTag, usesImageDigest, unpinnedImages, risksStaleImage, imageRegistries, and usesAlwaysImagePullPolicy to catch mutable or unpinned images at a glance.
• Resource governance: hasResourceLimits, hasResourceRequests, hasCpuLimit, and hasMemoryLimit.
• Secret usage: usesSecretsAsEnv, mountsSecretVolumes, and consumedSecrets to see exactly what a workload pulls in.

Container-level resources expose their security context as plain fields too: privileged, allowPrivilegeEscalation, runAsNonRoot, runAsUser and runAsGroup, readOnlyRootFilesystem, added and dropped capabilities, and seccomp profile type.

Built-in RBAC, secret, and namespace analysis

• RBAC: Roles, ClusterRoles, and their bindings now surface hasWildcardRule, grantsClusterAdmin, allowsPrivilegeEscalation, and canReadSecrets, with rules available as typed policyRules. ServiceAccounts roll the same analysis up to isClusterAdmin, canEscalatePrivileges, canReadSecrets, and hasWildcardPermissions, and link back to the bindings that grant them.
• Secrets: Secrets now identify themselves (isServiceAccountToken, isImagePullSecret), flag orphaned credentials (isUnused), and surface expired TLS certificates (hasExpiredCertificate, certificateExpiry).
• Namespaces: Pod Security admission is first-class, with podSecurityEnforce, podSecurityAudit, and podSecurityWarn (and their versions) plus an enforcesPodSecurity rollup.

Every resource also gains ownerReferences and managedFields, so you can trace which controller owns an object and which field managers set which fields.

Kubernetes network posture, thanks to the community

A huge thank-you to Maximilian Rink (@MaxRink) for contributing a complete model of Kubernetes network posture. Mondoo now normalizes how workloads are exposed and isolated:

• New k8s.networkExposure, k8s.egressRoute, k8s.egressNat, and k8s.networkPolicyCoverage resources, with cluster- and namespace-level posture plus per-Service, per-Ingress, per-Gateway, and per-NetworkPolicy views.
• Public-exposure classification for Services, Ingresses, and Gateways, including LoadBalancer source-range restrictions and NodePort signals, with routesToPublicEndpoint and externalEndpoints to spot traffic leaving the cluster.
• Pods resolve the Services, Ingresses, and Gateways that route to them, and whether they escape any default-deny network policy.
• NetworkPolicy coverage spanning native Kubernetes policies as well as Calico, Cilium, and MultiNetworkPolicy.

Together these turn "what's reachable from outside, and what isn't covered by a network policy?" into a question you can answer directly.

Max also extended Kubernetes discovery: you can now scope a scan to several namespaces at once with a comma-separated namespace filter, and Mondoo discovers one asset per namespace.

Scale image scanning across large clusters

We reworked how the Mondoo Operator scans container images, increasing image-scanning scalability by more than 6x. The operator runs far leaner in-cluster, so you can scan large container images across large clusters with confidence.

Better Infrastructure as Code Results

Catching misconfigurations in the code that builds your infrastructure is far cheaper than catching them in production. This month strengthens infrastructure as code scanning on several fronts.

Deeper insight into Ansible codebases

The Ansible provider was substantially expanded, so you can write policy against far more of your Ansible infrastructure as code. Mondoo now understands the full shape of an Ansible project, not just individual playbook files:

• Project structure: New ansible.project, ansible.playbook, ansible.role, and ansible.role.meta resources map how your playbooks, roles, and their metadata fit together.
• Inventory: New ansible.inventory, ansible.inventory.group, and ansible.inventory.host resources expose which hosts your automation targets and how they're grouped.
• Galaxy dependencies: New ansible.galaxy.requirements, ansible.galaxy.role, ansible.galaxy.collection, and ansible.galaxy.manifest resources let you audit the external roles and collections a project pulls in.
• Configuration and secrets: New ansible.config, ansible.vault, ansible.vault.file, and ansible.vault.variable resources surface configuration and Ansible Vault usage, so you can check how secrets are handled.
• Collections and plugins: New ansible.collection and ansible.plugin resources round out what a project ships.

Plays and tasks are richer, too. The ansible.play resource now exposes role applications, vars_files, interactive vars_prompt variables, play-wide environment variables, and collection search order. The ansible.task resource now distinguishes the module a task invokes and its arguments, along with imported tasks and imported playbooks, so static analysis can follow how a play is actually assembled.

Simpler Terraform queries

Writing policy against Terraform used to mean handling HCL source, plan, and state as three different shapes. A new terraform.block resource gives you one consistent way to query all of them. Its resourceType (for example aws_instance) and resourceName identify the block, and a values field folds child blocks into the same lists-of-maps shape that plan and state already use, so a single query works no matter which form you scan. An argumentReferences field exposes arguments whose variable and local references are left unresolved (for example var.bucket_acl), so you can write policy against the references themselves regardless of variable resolution. A new terraform.context resource rounds this out. The result is fewer, simpler queries that read the same across source, plan, and state.

For example, flag any S3 bucket configured with a public-read ACL:

MQLCopy
terraform.blocks.where(resourceType == "aws_s3_bucket") {
  values["acl"] != "public-read"
}

Terraform findings annotated right on your pull requests

When you scan infrastructure as code with cnspec, the SARIF output now carries Terraform source context, so every finding maps back to the exact file and line in your code. This matters most in CI: because findings now point at precise locations, Mondoo scans running in your pipeline automatically annotate the offending lines directly on the pull request or merge request, using the same SARIF code-scanning integration your platform already supports. Developers see security issues inline during code review, on the exact lines that caused them, instead of digging through a separate scan log.

Broader Vulnerability Scanning Coverage

A vulnerability scanner is only as useful as the systems it understands. This month Mondoo extends vulnerability detection to more operating systems and distributions, so more of your fleet is covered out of the box.

Operating systems and distributions

• SLES 12 SP5: Vulnerability scanning now covers SUSE Linux Enterprise Server 12 SP5.
• Ubuntu, Debian, and Arch derivatives: Linux Mint, LMDE, Pop!_OS, Manjaro, and EndeavourOS now scan against their upstream distributions, so derived distros get the same vulnerability coverage as the base they're built on.
• Latest Windows builds: Mondoo now covers Windows 11 25H2 and 26H1, along with end-of-life detection for Windows Server 2012.

Package ecosystems

• Homebrew: Packages installed through Homebrew are now matched against vulnerability data, bringing the software your developers install on macOS under the same vulnerability scanning as the rest of your fleet.

Desktop applications

Mondoo now detects known vulnerabilities in more of the desktop applications spread across your macOS and Windows endpoints, including Citrix Workspace, AnyDesk, GoToMeeting, PuTTY, WinSCP, Foxit, and KeePass and KeePassXC.

Infrastructure and DevOps software

Mondoo now tracks vulnerabilities in Progress Chef products, including Chef Infra Client, Chef Infra Server, Chef InSpec, and Chef Manage, so the automation tooling running across your fleet is covered alongside everything else.

A New Source of Exploited-in-the-Wild Intelligence

Knowing a vulnerability is exploitable is one thing. Knowing it's actively being exploited right now is what changes your priorities. Mondoo now incorporates inthewild.io as a new source of real-world exploitation data, joining signals like CISA KEV and Metasploit. When a CVE is being exploited in the wild, Mondoo tells you, so you can act on the vulnerabilities attackers are actually using.

Improved Third-Party Data Imports

Mondoo is most powerful when it works alongside the security tools you already run, turning their output into prioritized, remediable findings next to the rest of your environment. This month we made bringing that data in deeper and more dependable.

A direct Tenable integration

Mondoo's Tenable integration was rebuilt on a direct connection to Tenable Vulnerability Management and Tenable One. It pulls your assets and vulnerabilities through Tenable's bulk export APIs and turns them into full inventory and vulnerability records inside Mondoo, on par with the coverage we already provide for Tenable Security Center.

Remediation guidance for endpoint findings

When you import findings from your endpoint protection tools, Mondoo now enriches them with its own remediation guidance. Findings brought in from Microsoft Defender, CrowdStrike, and SentinelOne gain Mondoo's remediation steps, with the vendor's own remediation text surfaced alongside, so an imported finding tells you not just what's wrong but how to fix it. A new enrichment toggle on those integrations lets you keep each vendor as a detection source while layering Mondoo's deeper insights on top.

Clearer, more reliable imports

• Know what came from where: Data that Mondoo adds to a third-party asset is now labeled "Mondoo Enrichment," so you can always tell Mondoo's analysis apart from what your other tools reported.
• Import time vs. scan time: Mondoo distinguishes when it imported a result from when the third-party tool originally scanned, so you always know how fresh a finding really is.
• Smarter asset classification: Imported devices that used to land as "Unrecognized" are now correctly classified, including VMware and Linux assets, so they slot cleanly into your inventory.
• More resilient ingestion: A range of reliability improvements means data from your other tools lands consistently, with fewer duplicates and dropped records.

Remediation for More of Your Stack

Mondoo doesn't just tell you what's wrong, it tells you how to fix it. This month we expanded remediation guidance to many new types of packages and assets, and made the guidance Mondoo generates more accurate.

Step-by-step fixes for more packages and platforms

Remediation generators now cover far more of your environment, so more findings arrive with a concrete fix instead of just a description:

• VMware ESXi and vSphere: A new remediation generator produces step-by-step fixes for ESXi host and vSphere findings.
• macOS: OS-level findings now come with the exact Software Update path to bring a Mac current.
• Homebrew: Vulnerable Homebrew packages now generate real, catalog-backed remediation steps.
• Windows: Hardened PowerShell update remediation, a new Intune-based remediation action, and remediation that walks the full WSUS and MSRC update chain to point at the right cumulative KB.
• AIX: More reliable AIX remediation, with validated download URLs and safer extraction.

Smarter, more accurate remediation

• Finds fixes hidden in nested advisories: Modern vendor advisories often nest, where a CVE points at an empty vendor stub that in turn points at the advisory carrying the actual patch. Mondoo now walks that chain to surface the real fix, recovering remediation for Microsoft Office and Windows CVEs (including those imported from Defender) that previously showed no remediation at all.
• Honest about "no fix available": When there's no remediation, Mondoo now tells you which of two very different things is true: the vendor acknowledges the vulnerability but hasn't shipped a patch yet ("no fix available"), or it's simply outside Mondoo's coverage. A coverage gap is never disguised as "no fix," so you can trust the message and your team isn't sent chasing patches that don't exist.
• Recovers the right ecosystem: Even when an imported asset's platform is unknown, Mondoo recovers the correct package ecosystem from the advisory so remediation still resolves.

Imported findings benefit too: as covered above, findings brought in from Microsoft Defender, CrowdStrike, and SentinelOne now gain Mondoo's remediation guidance.

Finer-Grained Cloud Discovery

Mondoo increasingly discovers individual cloud resources as their own assets rather than rolling everything up under the account. That granularity pays off in three ways: risk is easier to understand when each asset carries its own score, query output is cleaner and more targeted, and you can open tickets and create exceptions on a single resource instead of the entire account. This month adds finer-grained discovery for:

• Hetzner: Firewalls and load balancers.
• DigitalOcean: Managed databases, Kubernetes clusters, load balancers, firewalls, and Spaces object storage.
• OpenStack: Security groups.

Expanded Linux Distribution Support

Mondoo now recognizes and classifies a wider range of Linux distributions, so more of your fleet is identified correctly and assessed out of the box. New operating system support this month includes:

• Security and privacy focused: Qubes OS and Tails.
• Desktop and developer: KDE neon and NixOS.
• Minimal, embedded, and container: BusyBox, CirrOS, LEDE, and Scratch base images.
• Enterprise cloud: Huawei Cloud EulerOS (HCE).

Mondoo also adds a generic Linux fallback, so distributions it doesn't recognize specifically are still classified and scanned instead of landing as "unknown."

Updated CIS Benchmarks

Staying current with CIS guidance keeps your infrastructure hardened against the threats that matter today. This month brings seven CIS benchmarks up to their latest editions:

• CIS Apple macOS 14.0 Sonoma Benchmark v3.1.0
• CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v2.0.0
• CIS AWS Compute Services Benchmark v2.0.0
• CIS Debian Linux 12 Benchmark v2.0.0
• CIS Microsoft 365 Foundations Benchmark v7.0.0
• CIS Microsoft Windows Server 2019 Benchmark v5.0.0
• CIS Ubuntu Linux 24.04 LTS Benchmark v2.0.0

Finer-Grained Roles and Permissions

Not everyone on your team needs the same level of access. June introduces finer-grained roles, so you can grant people exactly the permissions their job requires instead of choosing between broad, all-or-nothing roles.

Quality-of-Life Improvements

A few smaller additions this month that make everyday work smoother:

• Bulk-close tickets: Select multiple tickets and close them in one action instead of one at a time.
• Searchable Managed Clients list: The Managed Clients list is now searchable and filterable, and shows each client's agent version at a glance.
• Filter findings by detection source: Narrow an asset's findings to the scanner that reported them, whether that's Mondoo cnspec, SentinelOne, Microsoft Defender, CrowdStrike Falcon, Tenable, and more.
• Owner and exposure context on cloud assets: Cloud asset overviews now show who owns or is the contact for an asset and whether it's exposed to the internet, so you can route a finding to the right team and spot risky exposure without leaving the overview.
• Richer asset overviews: Across the board, the asset overview surfaces far more context about each scanned asset, including friendlier TLS version labels and brand-new overview panels for platforms like Active Directory, Atlassian, Datadog, Ansible, and Kubernetes admission, so you can understand an asset at a glance.
• More reliable Windows and SQL Server advisories: A large effort to model Microsoft's update supersedence and nested advisory chains means findings for Windows, .NET, Office, SharePoint, and SQL Server now resolve to the single correct fix far more reliably, with fewer false positives and fewer findings that wrongly appeared to have no remediation.

And There's Even More

Beyond the highlights above, June brought a long list of smaller improvements throughout the product, too many to call out individually. And we're already hard at work on what's next, so look for more new functionality next month.