CISA’s ScubaGear repository describes a three-step process: PowerShell queries Microsoft 365 APIs, Open Policy Agent compares returned settings with policies derived from CISA’s Secure Cloud Business Applications baselines, and the tool produces HTML, JSON, and CSV reports. Current coverage includes Microsoft Entra ID, the Microsoft security suite, Exchange Online, Power BI, Power Platform, SharePoint, and Teams.
\r\nCISA developed SCuBA principally for federal cloud security, while also recommending that other organizations review the baselines and apply practices where appropriate. A result is therefore not, by itself, a private-sector certification, a complete Microsoft 365 security assessment, or proof that every control is appropriate to a particular tenant.
\r\nThe official configuration documentation supports a YAML or JSON file for product selection, environment details, exclusions, annotations, and policy omissions. It warns that exclusions and omissions can introduce blind spots and says omissions should be approved through the organization’s risk-management process. Rationales and expiration dates can be recorded. The repository also advises users to review prerequisites, permissions, updates, and product-specific limitations.
\r\nThese facts matter when comparing two reports. A changed result might reflect tenant drift, a new ScubaGear release, a revised SCuBA baseline, different permissions, a changed configuration file, an API response difference, or a corrected policy implementation. Calling every difference tenant drift would overstate what the evidence proves.
\r\nGive each run an owner, approved scope, tenant identifier, purpose, and protected execution location. Use only the documented permissions needed for the selected products. Separate interactive testing from any unattended identity, protect its certificate or other authentication material, and remove unnecessary access when scheduled collection is not required. Treat the reports as sensitive because they can expose security configuration and exceptions.
\r\nPreserve a run manifest with UTC time, ScubaGear version, baseline or policy version, dependency versions, selected products, environment, invoking identity, configuration-file hash, command parameters, completion status, and output hashes. Store the original HTML, JSON, CSV, console log, and configuration together under access control. This creates reproducibility without claiming the tool captured every relevant setting.
\r\nBefore remediation, DSE recommends comparing each finding with current official Microsoft documentation for the tenant’s licensed services and recording the setting’s actual enforcement scope. Controls can interact across products or depend on licensing. Capture those dependencies so a passing point result is not mistaken for end-to-end enforcement.
\r\nRun again on an organization-defined schedule and after material tenant, licensing, identity, or baseline changes. Compare normalized policy identifiers and results, but retain both manifests. Distinguish a tenant change from a tool or policy change in the review record. New checks should enter triage rather than being silently treated as old failures; removed checks should not disappear from the risk register until their disposition is understood.
\r\nThis operating model differs from DSE’s Microsoft Secure Score article. Secure Score is a Microsoft-maintained improvement work queue. ScubaGear compares observed settings with CISA policy logic. Neither substitutes for threat modeling, application testing, licensing review, or accountable risk acceptance.
\r\n