Welcome to March 2023 release highlight of Mondoo.
We are excited to share with you the release of our SSPM solution, BigQuery Integration, along with several other significant improvements for this month:
Chapters
We are thrilled to unveil our SaaS security posture management (SSPM) solution combined with xSPM capabilities and an open public registry of policies for SaaS. Our SSPM solution provides organizations with the assurance that their SaaS applications are secure and up-to-date.
Mondoo’s open SSPM is based on a trusted open source foundation and helps continuous monitoring for misconfigurations of cloud-based SaaS applications.
Find out more in our blog post.
After agentless integrations for GCP, Azure, and MS365, we're excited to announce that Mondoo now offers agentless continuous scanning for Google Workspace and Okta SaaS environments. With no downloads or installations required, you can easily set up integrations with service accounts or tokens to securely scan your SaaS services every 8 hours.
Mondoo is excited to announce our integration with Google BigQuery, a game-changer for your security intelligence and insights! By combining Mondoo with Google BigQuery, we're creating a powerful team to enrich security data lakes and customize the security with full assessment. This means your security operations can quickly detect and respond to potential security incidents.
Exports are configured just like other integrations in Mondoo and run daily without the need to install anything into your infrastructure.
Once the data is exported it can be combined with other data in BigQuery and analyzed with BigQuery's machine learning and BI features.
Find out more in our blog post.
We've reworked our Vulnerabilities page to make it quicker to find vulnerabilities in your environment, identify the worst offending assets, and investigate newly released CVEs. A new Vulnerabilities menu now includes individual options for Advisories, CVEs, Affected Assets, and Mondoo Vulnerability Database (VMD).
The Advisories and CVEs pages allow you to dive into specific vendor security advisories and CVEs that impact your environment. You can see when these issues were first discovered, progress towards patching them, and get more details on the advisory/CVEs, including impacted assets.
The new Affected Assets page lets you quickly dive into assets with unpatched CVEs or vendor advisories in your space.
The completely reworked Mondoo Vulnerability Database (MVD) gives you a single UI to research new vendor CVEs and advisories even if they don't apply to your assets. Curious about that new CVE you read about online? Look it up to learn more, including details on the CVSSv3 score and any impacted assets in your environment.
We improved the Fleet page so that Microsoft 365 assets are now grouped together, making it easier and faster to find them.
Finding a specific asset has been made easier with our new links to open individual organizations and alphabetical sorting of all spaces. This simplifies the process of locating an asset when you have a large number of organizations or spaces.
With a splash of Mondoo purple and orange, we have redesigned our old login page to give you a more enhanced login experience.
Kubernetes moves fast, so ensuring your security policy matches the latest and greatest security recommendations is essential. Mondoo now includes the latest CIS benchmarks for Kubernetes distributions with updated auditing and remediation steps as well as new checks for the control plane in cloud distributions:
New: CIS Kubernetes V1.24 Benchmark 1.0
Updated: CIS Amazon Elastic Kubernetes Service (EKS) Benchmark 1.2
Updated: CIS Google Kubernetes Engine (GKE) Benchmark 1.3
Updated: CIS Azure Kubernetes Service (AKS) Benchmark 1.2
Updated: CIS RedHat OpenShift Container Platform v4 Benchmark 1.1
The CIS Google Kubernetes Engine (GKE) Benchmark policy has been enhanced with the following new checks and is now fully certified by CIS:
5.1.1 Ensure Image Vulnerability Scanning using GCR Container Analysis or a third-party provider
5.6.4 Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled
Our all-new Microsoft Workstation Security policy provides security guidance for workstations running Windows 10 and 11.
We've updated the Linux and Microsoft Azure Security by Mondoo policy environment secure out of the box:
Updated Linux Workstation Security
We expanded boot loader security to include permissions on /boot/loader/loader.conf so you can rest assured your boot sequence hasn't been tampered with.
Updated Linux Security Policy
We improved the reliability of auditd package checks on some SUSE releases.
The CIS Microsoft Azure Foundations Benchmark policy has been updated from 1.5 to 2.0. This new release includes reworked audit and remediation steps that match Azure's latest UI and CLI experiences.
We've updated our Google Workspace Security by Mondoo policy with three new checks:
Mondoo now includes a new Slack Team Security policy with seven checks to secure your Slack Team (Workspace):
New Okta Security policy enhancements
We have shipped continuous Okta scanning integration in the Mondoo Console. Now we have a new Mondoo security policy and improvements to Okta MQL resources so you can secure your Okta environment in just minutes.
Our new Okta Security Policy by Mondoo includes 11 checks to keep your Okta environment secure out of the box:
Ensure MFA is active for everybody accessing the Okta platform
Ensure a limited session lifetime has been enforced
Ensure OpenID or SAML authentication is used for app access
Ensure normal users cannot unlock themselves
Ensure Secure Web Authentication (SWA) is disabled for critical apps
Ensure the option "at every sign-in" is enabled for MFA
Ensure "Persist session cookies across browser sessions" is disabled
Ensure the users with Super Admin rights are limited to 3
Ensure the strong factor is used for MFA
Ensure that MFA is configured to use password/IdP plus another authentication factor
Ensure the "Password/IdP plus Another" factor is chosen for MFA
VMware vCenter Incident Response Pack
New VMware vCenter Incident Response Pack
Gather critical information on your vSphere and ESXi systems in the event of a security incident with this new incident response pack.
Mondoo has you covered for inspecting any of your GCP infrastructure, from your entire organization to a single folder:
cnquery scan gcp org 342423 # <-- scan GCP organization
cnquery scan gcp project mondoo-dev # <-- scan GCP project
cnquery scan gcp folder 3421423 # <-- scan GCP folder
We've updated both cnquery and cnspec to connect to IPv6 hosts directly over SSH or using Ansible inventory files.
cnquery shell ssh chris@fd00::20c:30ff:fe8a:9da0 --ask-pass
Enter password:
→ discover related assets for 1 asset(s)
→ resolved assets resolved-assets=1
___ _ __ __ _ _ _ ___ _ __ _ _
/ __| '_ \ / _` | | | |/ _ \ '__| | | |
| (__| | | | (_| | |_| | __/ | | |_| |
\___|_| |_|\__, |\__,_|\___|_| \__, |
mondoo™ |_| |___/ interactive shell
cnquery>
You can now specify the path to your GCP or Google Workspace credentials using a new --credentials-path flag. Shell environmental variables will continue to take precedence when defining the path, but this is a great method of setting the path if you don't have shell ENV vars set.
With env var:
GOOGLE_APPLICATION_CREDENTIALS=~/mondoo-dev-1111111.json cnquery shell gcp
With --credentials-path:
cnquery shell gcp --credentials-path ~/mondoo-dev-1111111.json
Gone are cryptic asset connection error messages when scanning multiple assets! In their place you now see better formatted and parsed error messages that make it easier to track down exactly why assets can't be scanned.
The Mondoo Homebrew tap now installs both cnquery and cnspec as dependencies, giving you the complete power of Mondoo in one installation.
Cloud Kubernetes security extends beyond the kubelet and cluster workloads, so we've added new data-gathering capabilities for the GKE control plan. Use this new data to take inventory of your GKE configuration or to write custom security policies for your organization.
addonsConfig
nodePools management
Cluster networkConfig
Cluster workloadIdentityConfig
ipAllocationPolicy
binaryAuthorization
legacyAbac
masterAuth
cnquery> gcp.project.gke.clusters{ addonsConfig{*} }
gcp.project.gke.clusters: [
0: {
addonsConfig: {
horizontalPodAutoscaling: {
disabled: false
}
id: "gcp.project.gkeService.cluster/12345/addonsConfig"
gkeBackupAgentConfig: {}
gcePersistentDiskCsiDriverConfig: {
enabled: true
}
networkPolicyConfig: {
disabled: false
}
gcpFilestoreCsiDriverConfig: {
enabled: false
}
dnsCacheConfig: {
enabled: false
}
httpLoadBalancing: {
disabled: false
}
kubernetesDashboard: {
disabled: true
}
configConnectorConfig: {}
cloudRunConfig: {}
}
}
]
cnquery> gcp.project.gke.clusters{ nodePools{ management } }
gcp.project.gke.clusters: [
0: {
nodePools: [
0: {
management: {
autoRepair: true
autoUpgrade: true
upgradeOptions: {}
}
}
1: {
management: {
autoRepair: true
autoUpgrade: true
upgradeOptions: {}
}
}
]
}
]
cnquery> gcp.project.gke.clusters{ networkConfig{*} }
gcp.project.gke.clusters: [
0: {
networkConfig: {
enableL4IlbSubsetting: false
id: "gcp.project.gkeService.cluster/12345/networkConfig"
dnsConfig: {}
serviceExternalIpsConfig: {
enabled: false
}
subnetworkPath: "projects/project-1/regions/us-central1/subnetworks/mondoo-gke-cluster-2-subnet"
privateIpv6GoogleAccess: "PRIVATE_IPV6_GOOGLE_ACCESS_UNSPECIFIED"
datapathProvider: "DATAPATH_PROVIDER_UNSPECIFIED"
networkPath: "projects/project-1/global/networks/mondoo-gke-cluster-2"
subnetwork: gcp.project.computeService.subnetwork name="mondoo-gke-cluster-2-subnet"
enableIntraNodeVisibility: false
defaultSnatStatus: {
disabled: false
}
network: gcp.project.computeService.network name="mondoo-gke-cluster-2"
}
}
]
cnquery> gcp.project.gke.clusters{ workloadIdentityConfig }
gcp.project.gke.clusters: [
0: {
workloadIdentityConfig: {
workloadPool: "mondoo-edge.svc.id.goog"
}
}
]
cnquery> gcp.project.gke.clusters{ ipAllocationPolicy{*} }
gcp.project.gke.clusters: [
0: {
ipAllocationPolicy: {
id: "gcp.project.gkeService.cluster/12345/ipAllocationPolicy"
stackType: "IPV4"
tpuIpv4CidrBlock: ""
useRoutes: false
createSubnetwork: false
nodeIpv4CidrBlock: ""
subnetworkName: ""
servicesSecondaryRangeName: "cluster-2-ip-range-svc"
useIpAliases: true
clusterSecondaryRangeName: "cluster-ip-range-pods"
clusterIpv4CidrBlock: "10.20.0.0/16"
ipv6AccessType: "IPV6_ACCESS_TYPE_UNSPECIFIED"
servicesIpv4CidrBlock: "10.30.0.0/16"
}
}
]
cnquery> gcp.project.gke.clusters{ binaryAuthorization }
gcp.project.gke.clusters: [
0: {
binaryAuthorization: {
enabled: false
evaluationMode: "EVALUATION_MODE_UNSPECIFIED"
}
}
]
cnquery> gcp.project.gke.clusters{ legacyAbac }
gcp.project.gke.clusters: [
0: {
legacyAbac: {
enabled: false
}
}
]
cnquery> gcp.project.gke.clusters{ masterAuth }
gcp.project.gke.clusters: [
0: {
masterAuth: {
clientCertificate: ""
clientCertificateConfig: {}
clientKey: ""
clusterCaCertificate: "***"
password: ""
username: ""
}
}
]
Identifying publicly exposed assets is critical to securing your cloud infrastructure.
Use the new publicIpAddresses data available in the azure.subscription.computeservice.vm and azure.subscription.networkservice to quickly identify assets that may be incorrectly publicly exposed.
Identify all public IP addresses in a subscription:
cnquery> azure.subscription.network.publicIpAddresses{*}
azure.subscription.network.publicIpAddresses: [
0: {
name: "super-cool-public-ip"
id: "/subscriptions//resourceGroups//providers/Microsoft.Network/publicIPAddresses/"
location: "uksouth"
tags: {}
ipAddress: "255.255.255.255"
}
]
Identify public IP addresses on specific VMs:
cnquery> azure.subscription.compute.vms{publicIpAddresses{*}}
azure.subscription.compute.vms: [
0: {
publicIpAddresses: [
0: {
name: "super-cool-public-ip"
id: "/subscriptions//resourceGroups//providers/Microsoft.Network/publicIPAddresses/"
location: "uksouth"
tags: {}
ipAddress: "255.255.255.255"
}
]
name: "vm-name"
}
]
cnspec and cnquery now ship with additional Azure resources so you can inventory and secure all aspects of your Azure infrastructure:
This new Azure resource lets you query each instance of Application Insights.
cnquery> azure.subscription.monitor.applicationInsights
azure.subscription.monitor.applicationInsights: [
0: azure.subscription.monitorService.applicationinsight id = /subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/cloud-shell-storage-westeurope/providers/microsoft.insights/components/app-insight-test
]
cnquery> azure.subscription.monitor.applicationInsights {name kind location}
azure.subscription.monitor.applicationInsights: [
0: {
name: "app-insight-test"
location: "centralus"
kind: "web"
}
]
This new Azure resource lets you query all bastion hosts, including their names, locations, and product SKUs.
cnquery> azure.subscription.network.bastionHosts
azure.subscription.network.bastionHosts: [
0: azure.subscription.networkService.bastionHost id="/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/cloud-shell-storage-westeurope/providers/Microsoft.Network/bastionHosts/test-bastion-host" name="test-bastion-host" location="uksouth"
]
cnquery> azure.subscription.network.bastionHosts{name location sku}
azure.subscription.network.bastionHosts: [
0: {
name: "test-bastion-host"
sku: {
name: "Standard"
}
location: "uksouth"
}
]
This new Azure resource lets you query the virtual network rules on an SQL server and is similar to firewall rules resources.
cnquery> azure.sql.servers[1].virtualNetworkRules{*}
azure.sql.servers[1].virtualNetworkRules: [
0: {
id: "/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/cloud-shell-storage-westeurope/providers/Microsoft.Sql/servers/sql-server-mondoo-test/virtualNetworkRules/newVnetRule1"
properties: {
id: "/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/cloud-shell-storage-westeurope/providers/Microsoft.Sql/servers/sql-server-mondoo-test/virtualNetworkRules/newVnetRule1"
name: "newVnetRule1"
properties: {
ignoreMissingVnetServiceEndpoint: false
state: "Ready"
virtualNetworkSubnetId: "/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/DefaultResourceGroup-CUS/providers/Microsoft.Network/virtualNetworks/prelav-test-VN/subnets/default"
}
type: "Microsoft.Sql/servers/virtualNetworkRules"
}
virtualNetworkSubnetId: "/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/DefaultResourceGroup-CUS/providers/Microsoft.Network/virtualNetworks/prelav-test-VN/subnets/default"
type: "Microsoft.Sql/servers/virtualNetworkRules"
name: "newVnetRule1"
}
]
This new Azure resource lets you query the Azure Cosmos DB service.
Query databases:
cnquery> azure.subscription.cosmosDb.accounts
azure.subscription.cosmosDb.accounts: [
0: azure.subscription.cosmosdbService.account name="test-cosmosdb-mondoo" location="West US"
1: azure.subscription.cosmosdbService.account name="test-mondoo-cassandra" location="West US"
]
Write assertions to secure configuration:
cnquery> azure.cosmosDb.accounts{properties['isVirtualNetworkFilterEnabled'] name}
azure.cosmosDb.accounts: [
0: {
properties[isVirtualNetworkFilterEnabled]: true
name: "test-cosmosdb-mondoo"
}
1: {
properties[isVirtualNetworkFilterEnabled]: true
name: "test-mondoo-cassandra"
}
]
You can now fetch Google Workspace connected apps with a new googleworkspace.connectedApps MQL resource:
googleworkspace.connectedApps { name clientid }
googleworkspace.connectedApps: [
0: {
clientId: "11234434534-abcdefg.apps.googleusercontent.com"
name: "Slack"
}
...
]
You can also filter this data to return specific connected apps:
googleworkspace.connectedApps.where( name == /Slack/) { * }
googleworkspace.connectedApps.where: [
0: {
users: [
0: googleworkspace.user primaryEmail="user1@example.com"
]
tokens: [
0: googleworkspace.token displayText="Slack"
]
scopes: [
0: "https://www.googleapis.com/auth/activity"
1: "https://www.googleapis.com/auth/drive.activity"
2: "https://www.googleapis.com/auth/userinfo.profile"
3: "https://www.googleapis.com/auth/userinfo.email"
4: "openid"
5: "https://www.googleapis.com/auth/calendar.readonly"
6: "https://www.googleapis.com/auth/drive"
7: "https://www.googleapis.com/auth/calendar.events"
]
name: "Slack"
clientId: "11234434534-abcdefg.apps.googleusercontent.com"
}
1: {
users: [
0: googleworkspace.user primaryEmail="user1@example.com"
1: googleworkspace.user primaryEmail="user2@example.com"
2: googleworkspace.user primaryEmail="user3@example.com"
3: googleworkspace.user primaryEmail="user4@example.com"
]
tokens: [
0: googleworkspace.token displayText="Slack"
1: googleworkspace.token displayText="Slack"
2: googleworkspace.token displayText="Slack"
3: googleworkspace.token displayText="Slack"
]
scopes: [
0: "https://www.googleapis.com/auth/userinfo.profile"
1: "https://www.googleapis.com/auth/userinfo.email"
2: "openid"
]
name: "Slack"
clientId: "3321342421-abcdefg.apps.googleusercontent.com"
}
2: {
users: [
0: googleworkspace.user primaryEmail="user1@example.com"
1: googleworkspace.user primaryEmail="user2@example.com"
2: googleworkspace.user primaryEmail="user3@example.com"
3: googleworkspace.user primaryEmail="user4@example.com"
]
tokens: [
0: googleworkspace.token displayText="Slack"
1: googleworkspace.token displayText="Slack"
2: googleworkspace.token displayText="Slack"
3: googleworkspace.token displayText="Slack"
]
scopes: [
0: "https://www.googleapis.com/auth/userinfo.profile"
1: "https://www.googleapis.com/auth/userinfo.email"
2: "openid"
]
name: "Slack"
clientId: "6060606090-abcdefg.apps.googleusercontent.com"
}
]
Outdated packages don't end at the operating system, so we've introduced our first application package resource with the python.packages MQL resource. This new resource discovers packages automatically on macOS, Windows, and Linux in the following locations:
/usr/local/lib/python/*
/usr/local/lib64/python/*
/usr/lib/python/*
/usr/lib64/python/*
/opt/homebrew/lib/python/*
C:/Python/*
/System/Library/Frameworks/Python.framework/Versions
/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions
Each package returns data similar to this pytz package:
cnquery> python.packages[0]{ * }
python.packages[0]: {
author: "Armin Ronacher"
name: "Babel"
dependencies: [
0: python.package name="pytz" version="2022.7.1"
]
summary: "Internationalization utilities"
id: "/usr/lib/python3.11/site-packages/Babel-2.10.3-py3.11.egg-info/PKG-INFO"
file: file path="/usr/lib/python3.11/site-packages/Babel-2.10.3-py3.11.egg-info/PKG-INFO" size=1283 permissions.string="-rw-r--r--"
license: "BSD"
version: "2.10.3"
}
To query a specific package on disk you can provide the path to the METADATA file:
cnquery> python.package("/home/jdiaz/.local/lib/python3.11/site-packages/python_ftp_server-1.3.17.dist-info/METADATA"){ * }
python.package: {
version: "1.3.17"
summary: "Command line FTP server tool designed for performance and ease of use."
file: file path="/home/jdiaz/.local/lib/python3.11/site-packages/python_ftp_server-1.3.17.dist-info/METADATA" size=1186 permissions.string="-rw-r--r--"
author: "Vadym Stupakov"
dependencies: data is not a map to auto-expand
id: "/home/jdiaz/.local/lib/python3.11/site-packages/python_ftp_server-1.3.17.dist-info/METADATA"
license: "MIT"
name: "python-ftp-server"
}
This is the first of many new application package resources we plan to introduce, allowing you to audit and secure your application dependencies. If you have particular application packaging systems you want to see in cnquery and cnspec, be sure to let us know on our GitHub Discussions page.
In this release we've greatly expanded MQL's AWS ECS support with new data and resources:
aws.ecs.task now includes platformVersion data.
aws.ecs.container now includes platformVersion, runtimeId, and containerName data.
aws.ecs.cluster now includes containerInstances data.
aws.ecs.image now includes uri data exposing the URI of the image repository.
New aws.ecs.instance resource.
We've deprecated aws.elasticache.clusters in favor of a new aws.elasticache.cacheClusters resource that presents cluster data in an easier to consume format.
cnquery> aws.elasticache.cacheClusters { * }
aws.elasticache.cacheClusters: [
0: {
arn: "arn:aws:elasticache:us-east-1:ID:cluster:vjtest-001"
notificationConfiguration: ""
cacheSubnetGroupName: "vjtest"
atRestEncryptionEnabled: false
logDeliveryConfigurations: []
ipDiscovery: "ipv4"
authTokenLastModifiedDate: null
numCacheNodes: 1
engine: "redis"
networkType: "ipv4"
region: "us-east-1"
securityGroups: []
transitEncryptionMode: ""
cacheNodeType: "cache.t3.medium"
engineVersion: "7.0.7"
preferredAvailabilityZone: "us-east-1c"
transitEncryptionEnabled: false
cacheClusterId: "vjtest-001"
authTokenEnabled: false
snapshotRetentionLimit: 0
Sometimes queries differ slightly when executed in different environments. This can happen with:
Queries that test for similar things on entirely different targets
Let's take a look at the latter example:
queries:
- uid: no-public-ip
title: No public IPs are allowed on internal instances
variants:
- uid: no-public-ip-aws
- uid: no-public-ip-terraform-aws
- uid: no-public-ip-aws
mql: |
aws.ec2.instances.all( publicIp == "" )
filters: |
asset.platform == "aws"
- uid: no-public-ip-terraform-aws
mql: |
terraform.resources.
where( nameLabel == "aws_instance" ).
all( arguments['associate_public_ip_address'] != true )
filters: |
asset.platform == "terraform-hcl"
This query ensures that “No public IPs are allowed on internal instances.” This query is implemented in two different ways: one for the AWS API (no-public-ip-aws) and one for Terraform (no-public-ip-terraform-aws). You can run this check against both AWS accounts and Terraform files and get consistent reporting.
Additionally, this addresses a common use case where there's a split between things that happen in development and things that run in production. If you have separate tools in different environments, or even separate policies, you previously had to manage exceptions to certain checks across both ends of the lifecycle. Now with variants, you can instead define exceptions on the combined check, making sure that they are treated consistently between development and production.
If you want to define your own business policies for Okta, you're in luck. We've improved our Okta MQL policies, giving your access to more information on your environment:
Gather access policy rules
Fix okta.trustedOrigin.scopes parsing
You can now scan a single namespace in a Kubernetes cluster even if you don't have access to resources outside that namespace. This allows you to scan all workloads in your namespace and browse asset relationships under the namespace in the Mondoo Console.
Example cnquery query against a single namespace:
./cnquery run k8s --namespaces default -c "k8s.pods" --discover namespaces
→ loaded configuration from /Users/ivanmilchev/.config/mondoo/mondoo.yml using source default
→ discover related assets for 1 asset(s)
→ resolved assets resolved-assets=1
k8s.pods: [
0: k8s.pod namespace="default" name="nginx" created=2023-03-14 16:59:07 +0100 CET
]
The gcp.project.gke.cluster resource now includes information on encryption of the etcd database.
cnquery> gcp.project.gke.clusters[0]{databaseEncryption}
gcp.project.gke.clusters[0]: {
databaseEncryption: {
keyName: "projects/***/locations/us-central1/keyRings/***/cryptoKeys/***"
state: "ENCRYPTED"
}
The slack.users resource now includes the type of two-factor authentication (2FA) used by users. This lets you query which users are configured for insecure SMS vs. more secure app-based 2FA.
cnquery> slack.users.where( has2FA == true ){ has2FA twoFactorType }
slack.users.where.list: [
0: {
twoFactorType: "app"
has2FA: true
}
]
We are now publishing Red Hat Universal Base Image-based cnspec and cnquery containers to Docker Hub. These containers are perfect for running cnspec and cnquery in OpenShift clusters. You can find these images along with our standard Alpine-based images at https://hub.docker.com/r/mondoo/cnspec and https://hub.docker.com/r/mondoo/cnquery.
The Mondoo package has been optimized to reduce the space on disk consumed by Mondoo, cnquery, and cnspec commands. The legacy Mondoo CLI is now 200MB smaller on all platforms. Additionally, the cnquery and cnspec CLIs are each ~150MB smaller on Windows systems.
We now sign and notarize all binaries for macOS, not just those installed with the Mondoo .pkg file. This means no matter where you consume Mondoo packages, you will always have a fully secured binary that passes all of Apple's security requirements.
Problem There was no way to isolate cnspec-to-Mondoo-Platform and cnquery-to-Mondoo-Platform communication from non-Mondoo traffic.
Solution A new --api-proxy config flag allows you to specify the proxy server for Mondoo Platform API calls when you register an asset with the cnspec login command. You can also manually add the api_proxy configuration option in your mondoo.yml config.
We've optimized our Lambda-based AWS integration to reduce the number of API calls made by the integration to reduce Lambda costs. Don't worry; you'll still get the same great AWS resource scans, but now with added efficiency.
Mondoo EOL policy now executes on FreeBSD hosts.
cnquery run and cnspec run now properly load Mondoo Platform config to support EOL and package vulnerability queries.
Fix parsing of timestamps in Google Workspace.
Fix setup instructions for Windows on the Integrations page to copy/paste correctly.
Add missing breadcrumbs to the Vulnerabilities page.
Add form validation to the GCP and Okta Integration setup pages.
Don't report successful vulnerability scanning on an asset when zero packages were discovered.
Fix incorrect quoting in the GitLab Docker scanning example
Don't show the hour when reporting an EOL date for an asset.
Fix incorrect GCP project ID validation in the GCP integration setup page.
If an integration has never scanned, then display Never instead of Jan 01, 0001.
Update links on integration pages to go to specific documentation.
Use the latest Microsoft 365 logo on the integrations page.
Improve performance of container image scanning in the Mondoo Kubernetes Operator.
Update tabs on asset pages to match the new navigation UX.
Add the missing Okta token field to the Okta integration setup page.
Link to new CloudShell documentation in the AWS integration setup wizard.
Fix GCP console links in the GCP integration setup page to load properly when logged out of GCP.
Specify UDP or TCP in the ports.listening resource so specific protocols can be queried instead of just ipv4/ipv6.
Resolve failures scanning container registries.
Label container image assets with all discovered tags when scanning container registries.
Don't fail an entire AWS account scan when a single service has a region restriction set.
Fail better when a Kubernetes namespace cannot be scanned due to permissions failures.
Fix cnspec bundle format failure introduced in 8.0.
Update the scanning progress bar to make it more clear when an asset was not scored.
Fix console login page text field text color to be black.
Fix console login page links to user agreement and privacy policy to load in new windows.
Don't display 0 Others for Azure assets in the fleet page.
Fix off-center spinner loaders on the integration pages.
Rename "Latest Advisories" on the overview page to be "Top Advisories" to better match what the widget shows.
Show accurate billing plan data in the console.
Improve rendering on the welcome page on small displays.
Fix failure if the ps command column has no data and warn if data otherwise can't be parsed correctly.
Fix failures setting the AWS integration.
Fix parsing of policies with arrays of remediations instead of simple strings.
Improve the audit/remediation steps in Mondoo security policies.
Update cnspec bundle lint and cnspec bundle fmt commands to support the Mondoo version 8.0+ policy structure.
Update the Ensure events that modify the system's Mandatory Access Controls are collected query in the Linux Security by Mondoo policy to support either SELinux or AppArmor. Thanks @micheelengronne!
Improve reliability of queries in the Okta Organization Security by Mondoo policy.
Replace mondoo shell with cnspec shell in some policy audit instructions.
Improve remediation steps in Mondoo Azure, Google, and AWS policies.
Fix cnspec bundle fmt removing scoring_system from policies when converting between 7.x and 8.x formats.
Fix cnspec bundle fmt not properly parsing typed docs.
When scanning Kubernetes manifests containing resources without a namespace, don't create an unnamed namespace asset as the parent.
Fix failures querying Azure Cloud Defender security contacts when none exist.
Fix failure running github.organization {*} query.
Fix CVSS aggregated score calculation in the platform.advisories resource.
Fix some CIS Kubernetes policies not displaying in the Policy Hub.
Improve ad-hoc scan instructions in AWS/Azure/GCP policies.
Update CIS Azure AKS v.1.2 Pod Security Policy checks to only execute on Kubernetes < 1.25.
Update Linux Security by Mondoo policy's Ensure events that modify the system's Mandatory Access Controls are collected check to expect a trailing slash in directories. Thanks @micheelengronne!
Remove the running and unknown states shown in asset names in the console, which did not consistently or correctly show asset scan status.
Add missing impact scores to Windows Security by Mondoo policy.
Fix the Kubernetes Operator not immediately scanning newly deployed workloads in a cluster.
Update wording on the Azure and MS365 integration pages to make it more clear that the .pem file needs to include both the certificate and the private key.