Version 1.5.0 takes the auditor from 200 to 227 checks. The 27 additions come from two places. Fourteen close gaps against the CISA SCuBA baseline for Google Workspace: controls the baseline requires that no check evaluated before. Thirteen judge data the auditor was already collecting but never scored: admin accounts and roles, group membership settings, device posture, DNS records and licences. This post walks through what each new check catches and why the Admin console makes it easy to miss.
Phishing-Resistant MFA and Passwords
Most tenants that enforce 2-Step Verification stop at excluding SMS and voice. That setting, NO_TELEPHONY, still allows Google prompts and authenticator codes, and both are relayed by a real-time phishing proxy without the user noticing. SCuBA's first common control asks for more. GWS.COMMONCONTROLS.1.1 passes only when 2SV is enforced and the allowed method is PASSKEY_ONLY: security keys or passkeys, nothing that can be typed into a fake login page.
The password policy gets four checks of its own. The auditor already required a 12-character minimum; the new checks cover the rest of the policy page.
-
GWS.COMMONCONTROLS.5.1 · Strong password strength enforced
The Admin console defaults to allowing weak passwords. The check fails on anything other than
STRONG. -
GWS.COMMONCONTROLS.5.3 · Minimum length of 15 characters
SCuBA states 12 as a SHALL and 15 as a SHOULD. This is the SHOULD, so it is a Level 2 check with low severity. It sits next to the existing 12-character check rather than replacing it.
-
GWS.COMMONCONTROLS.5.5 · Password reuse not allowed
A reset that lands on a previously leaked password is no reset at all.
-
GWS.COMMONCONTROLS.5.6 · Passwords do not expire
Scheduled expiry produces predictable variations of the same password. Current NIST guidance, and SCuBA with it, is to rotate on evidence of compromise, not on a calendar. This check fails when an expiration period is set.
Account recovery closes the section. GWS.COMMONCONTROLS.8.1 fails when super admins can recover their own account through a recovery phone or email. It was listed among the auditor's critical checks in earlier documentation, but the check itself did not exist until this release. It does now, rated CRITICAL: whoever controls a super admin's recovery phone number controls the tenant.
Mail That Gets Through Anyway
Gmail's spoofing and authentication protections have two parts: detection, and what happens to a detected message. Nearly every tenant has detection on. Far fewer have changed the consequence from its default, which is to deliver the message to the inbox with a warning banner. Users click through banners. GWS.GMAIL.7.6 reads the five consequence settings behind domain spoofing, employee name spoofing, unauthenticated mail and groups spoofing, and fails on any that is not SPAM_FOLDER or QUARANTINE. The finding names each one, so the remediation is a specific list rather than "review your safety settings".
Three small companions, GWS.GMAIL.5.4, 6.4 and 7.7, confirm that "apply future recommended settings automatically" is on for attachments, links and spoofing respectively. Google adds protections to these pages over time; with the toggle off, a tenant stays on whatever it had the day an admin last visited.
SPF, DKIM and DMARC protect the mail you send. ADD-50 covers the mail you receive. Without an MTA-STS policy, a network attacker between a sending server and Google can strip the TLS upgrade and read the message in transit, because SMTP falls back to plaintext by design. The check looks up the _mta-sts record for every domain that has MX records, fails when it is missing, and warns when the policy exists but the TLS-RPT reporting record that would tell you about failures does not.
The last mail check is about what happens after an account is compromised. Setting up a forward to an outside address is one of the first things an attacker does with a stolen mailbox, and it survives a password reset. ADD-51 reads each mailbox's forwarding addresses and fails on any that is outside your verified domains. It is the one new check that is off by default. Reading per-mailbox settings means the service account impersonates every user through domain-wide delegation and makes one Gmail API call per mailbox. We would rather you enable that knowingly, with collect_mailbox_forwarding: true, than discover it in an audit log. Until then the check reports MANUAL, not PASS.
Admin Accounts Nobody Is Watching
The Admin console shows you who holds each role. It does not tell you which of those accounts has not signed in since last year, which are suspended but still privileged, or how a role reached a user through a group. Five new checks read the directory and the role assignments the auditor now collects, and answer those questions directly. Each is a takeover path.
-
ADD-42 · Super admin accounts are actively used or removed
An active super admin with no sign-in for 90 days (configurable) is a standing target whose owner will not notice a login alert. The break-glass account you created two years ago is the usual finding.
-
ADD-43 · Suspended users do not hold admin roles
Suspending an account does not remove its roles. Whoever can un-suspend it, which includes a helpdesk admin, restores the privileges in one click.
-
ADD-41 · Admin roles are not assigned to groups anyone can join
Assigning a role to a group is convenient. If the group's "who can join" setting allows self-service joining, or it accepts external members, the role is one join request away from anyone. Rated HIGH. Roles on groups with restricted membership are reported for review, since anyone who can add members can grant the role.
-
ADD-48 · Custom admin roles with account-takeover privileges
A custom role built for the helpdesk often accumulates privileges: reset passwords, change security settings, manage roles. Any of those lets the holder take over other accounts, including super admins. The check lists assigned custom roles carrying such privileges.
-
ADD-49 · Who holds Google Vault privileges
Vault gives access to every user's mail and files and can destroy data through retention rules. This is an inventory of the roles that carry Vault privileges and how many people hold each.
These checks need role data, which older cache files do not contain. On the first run after upgrading, run a live collection rather than re-scoring a saved cache, or they will report that roles were not collected.
Where Data Leaves
Drive sharing controls get a lot of attention. The other doors get less. GWS.CHAT.2.1 fails when users can attach files in Chat conversations with people outside the organization, a setting whose default is ALL_FILES. ADD-45 fails when external Chat spaces are enabled for any domain rather than limited to an allowlist.
A Google Group is often an access-control principal: Drive folders, calendars and cloud resources are shared with it. ADD-46 reads each group's own settings and fails when any group can be joined by anyone on the internet. Groups that accept external members are reported separately for review, because some of them exist for exactly that purpose.
Google Takeout lets a user export their entire mailbox and Drive to a zip file. ADD-09 existed before this release but could not see the setting; it now reads the Takeout policy for each of the nine services that carry one and lists exactly which ones still allow export.
Devices close the section. Your mobile management policy may say compromised devices are blocked, but the device inventory is what actually happened. ADD-47 reads the posture attributes on collected mobile and endpoint devices and fails when a device that reports as compromised, unencrypted or without a screen lock still has an approved management state. Basic mobile management does not report these attributes; on such tenants the check says so rather than passing.
Alerting
Google ships several dozen system-defined alert rules. Some are on by default, some are off, and an admin can toggle any of them. SCuBA names 30 that must be on, from "Leaked password" and "Suspicious login" through "Drive settings changed" and "Super admin password reset". GWS.COMMONCONTROLS.13.1 reads the actual state of each rule from the Policy API and fails when any required rule is off, listing them. Optional rules that are off are mentioned for information but do not affect the result. The API only returns rules an admin has touched at least once, so when a required rule is absent the check asks you to confirm it in the console instead of assuming.
GWS.COMMONCONTROLS.8.2 is the user-account counterpart of the super admin recovery check: SCuBA wants self-service recovery off for everyone. Be aware that the CIS benchmark asks for the opposite, and the auditor's existing CIS check still does. A tenant cannot satisfy both. Both checks say so in their remediation text; follow the framework you are assessed against and exclude the other.
Inventory, Not Score
Four of the new checks are informational and do not affect the posture score. ADD-44 lists active accounts with no sign-in for 90 days: licence cost, and accounts nobody would miss if they were taken over. ADD-52 lists active accounts without a Workspace licence, which run with reduced audit-log retention and no Vault coverage. Both produce a list to act on rather than a pass or fail.
GWS.DRIVEDOCS.1.10 and 1.11 cover Google Forms accepting or submitting responses across the organization boundary. No Google API exposes these settings, and SCuBA itself lists them as manual checks. They are included so the report shows every SCuBA control in one place, with a MANUAL result and the console path to verify, rather than leaving a gap you would have to know about.
Upgrading
No scope changes are needed. The role checks use a Directory scope that the standard setup already delegates, and mailbox forwarding uses the Gmail settings scope that has always been in the list. Two options are new in config.yaml:
user_inactive_days: 90
collect_mailbox_forwarding: false
mailbox_forwarding_max_users: 500
Run a live collection after upgrading. Admin roles, MTA-STS records and licence assignments are new datasets, and a cache written by an older version does not have them. The full list of 227 checks, with level, framework, severity and licence requirements, is in the Check Reference, and the complete release notes are in the changelog.