SaaS Security Checks Reference

Overview

This page is a complete reference of every security check Fencer runs when scanning your connected SaaS platforms. For each check you will find what it tests, its default severity, and remediation guidance. The checks below are grouped by platform.

Fencer currently supports checks for Google Workspace (9 checks), Microsoft Entra (11 checks), Zoom (8 checks), and GitHub (37 checks covering organization, repository, workflow, dependency, and release posture). Each check produces a vulnerability in the standard pipeline when a misconfiguration is found, allowing you to triage, assign, and track resolution just like any other finding.

GitHub Actions YAML rules (unpinned actions, OIDC, install-script policy, and similar) run during code scanning, not as SaaS checks. How those map to the OWASP Software Provenance Verification Standard is in OWASP SPVS Coverage.

For an overview of how SaaS scanning works, see SaaS Scanning.

Google Workspace checks

2FA enforcement (High) — Flags the domain when users have 2-Step Verification enrolled but not enforced, and names any affected admin accounts. Without enforcement a compromised password alone grants access. Remediate by navigating to Security > 2-Step Verification and setting enforcement to On.

Super admin hygiene (High) — Flags more than 3 active super admin accounts, suspended accounts that still hold the super admin role, and super admins with no login in 90 or more days. Review Account > Admin roles and revoke super admin from accounts that do not require it.

MFA enrollment gaps (Medium) — Identifies users who have 2FA enforced by policy but have not completed enrollment; they can sign in without MFA during the enrollment grace period. Use the Security dashboard to identify these users and have them finish enrollment.

Weak MFA methods (Medium) — Flags users who signed in with SMS or phone-call verification, which is vulnerable to SIM swapping, and names any admin accounts among them. Encourage users to enroll in Google Prompt, a TOTP app, or a hardware security key.

Third-party app with a known compromise (High) — Flags OAuth apps with a known security incident that users in your domain have granted access to Google Workspace data, and lists the affected users. Revoke the app for every user in Security > API Controls > App Access Control and review what it could access.

External sharing (Medium) — Flags the domain when Drive sharing outside the organization is allowed (with or without a warning). Restrict external sharing in Apps > Google Workspace > Drive and Docs > Sharing settings.

Domain-wide delegation (High) — Flags service accounts granted domain-wide delegation with both admin and data-access scopes (for example Gmail, Drive, or Calendar), which lets them act broadly on behalf of any user. Review and remove unnecessary delegations in Security > API Controls > Domain-wide Delegation.

Audit logging (High) — Flags the domain when no recent events appear in the admin activity or Drive activity audit logs, which suggests audit logging is disabled. Enable it under Reporting > Audit and investigation and configure appropriate log retention.

Data Loss Prevention (Medium) — Flags the domain when no DLP rule activity has been seen in the past year. Create DLP rules for sensitive data in the Google Admin console.

Microsoft Entra checks

MFA enforcement (High) — Flags the tenant when security defaults are disabled, so MFA is not required for users by default. Enable security defaults, or require MFA for all users with a Conditional Access policy in Security > Conditional Access.

Guest user review (Medium) — Flags the tenant when it has guest accounts, which should be reviewed regularly. Review Entra ID > Users filtered by Guest type and remove or restrict accounts that no longer need access.

Global admin count (Medium) — Flags more than 4 Global Administrator assignments (the CIS benchmark recommends between 2 and 4). Use PIM to convert standing assignments to eligible (time-bound) assignments.

Guest permissions (Medium) — Flags guest permissions that allow directory enumeration, that is, any guest role other than Restricted Guest User. Restrict guest access in **External Identities

External collaboration settings**.

Legacy authentication (High) — Verifies an enabled Conditional Access policy blocks legacy authentication clients (Exchange ActiveSync and other clients such as IMAP, SMTP, and POP3). Create a policy blocking all legacy authentication clients.

User consent policies (High) — Flags tenants where users can grant any OAuth app access to their mailbox, calendar, and files without admin approval. Configure the consent policy in Enterprise Applications > Consent and permissions to require admin approval.

Device compliance (Medium) — Verifies an enabled Conditional Access policy requires a compliant or Hybrid Azure AD joined device. Create a policy requiring compliant devices for cloud app access.

Phishing-resistant MFA (High) — Flags tenants that allow SMS-based MFA without an enabled Conditional Access policy enforcing the phishing-resistant MFA authentication strength. Require FIDO2 security keys or Windows Hello for Business, configured in Authentication methods > Policies.

PIM usage (Medium) — Flags Global Administrators with permanent, always-active role assignments not managed by Privileged Identity Management. Enable PIM and convert standing assignments to eligible assignments.

Break-glass accounts (High) — Verifies at least two cloud-only Global Administrator accounts on the *.onmicrosoft.com domain exist for emergency access. Create them per Microsoft guidance and exclude them from Conditional Access policies.

Identity Protection (High) — Flags the tenant when no enabled Conditional Access policy acts on high sign-in or user risk, and separately when users have an unresolved high risk score. Configure risk-based policies in Security > Identity Protection and investigate risky users.

Zoom checks

PMI usage (Medium) — Checks whether scheduled or instant meetings use the Personal Meeting ID, a static, predictable link. Use auto-generated meeting IDs instead.

Meeting passcodes (High) — Tests whether passcodes are required for new, scheduled, and PMI meetings. Enable Require a passcode for all meeting types in Account Management > Account Settings.

Waiting room (Medium) — Verifies you have the waiting room turned on so hosts can screen participants. Enable Waiting Room in Account Settings > In Meeting (Basic).

Join before host (Medium) — Checks whether participants can join before the host is present. Disable Join before host in Account Settings.

Cloud recording access (High) — Checks whether a passcode is required to view shared cloud recordings. Require a passcode for recording links in Admin > Recording Settings.

Screen sharing restrictions (Medium) — Flags accounts where all participants can share their screen, or take over while someone else is sharing. Set Who can share? to Host Only in In Meeting (Basic).

Removed participant rejoin (Medium) — Checks if removed participants can immediately rejoin. Disable Allow removed participants to rejoin in Account Settings.

File transfer (Medium) — Checks whether you allow in-meeting file transfer. Disable File transfer in In Meeting (Basic) if not required.

GitHub checks

GitHub SaaS scanning evaluates the GitHub App code installation and the repositories you have chosen to track. Organization checks run when the installation target is an organization. Missing GitHub App permissions are treated as skipped, not as findings. A failed read of organization rulesets (HTTP 403 or 404), including a detail read that returns no ruleset body, skips the org branch ruleset, tag ruleset, and restricted branch-name checks. It is not reported as a missing ruleset.

Organization

2FA enforcement (Critical) — Tests whether organization two-factor authentication is required, and whether any members still have 2FA disabled.

Privileged role minimization (Low) — Flags organizations where owners/admins are a large share of membership.

Default workflow permissions (Critical) — Requires default GITHUB_TOKEN permissions to be read-only, and disallows workflows approving pull request reviews.

Actions execution policy (Low) — Prefers restricting Actions to verified creators or an allow list instead of allowing every action.

Org-level branch rulesets (High) — Requires pull_request and non_fast_forward on each tracked repository’s default branch. The two rules can come from different active rulesets, as long as each ruleset covers that repository. The check honors ref include and exclude patterns (~DEFAULT_BRANCH, ~ALL, refs/heads…) and repository_name, repository_id, and repository_property conditions, including excludes. An empty include list covers nothing. The finding description names each ruleset that was evaluated and the condition that failed (not active, not branch-targeted, default branch excluded or not included, repositories not covered, missing pull_request, missing non_fast_forward) and lists tracked repositories the rulesets do not cover. A ruleset whose detail request fails is not judged from the list summary. If no ruleset detail could be loaded, the check is skipped.

Org-level tag rulesets (Medium) — Requires an active organization tag ruleset with a deletion rule covering tracked repositories. The same targeting, empty-include, and permission-skip rules apply. The finding description names a missing deletion rule rather than tag updates.

No admin bypass (High) — Flags rulesets that let repository admins bypass organization protections.

Restricted branch name patterns (Low) — Looks for rules preventing sensitive prefixes such as advisory-, internal-, and security-.

GitHub App token minting (Medium) — Flags workflows that mint installation tokens with org-wide or otherwise overly broad scope.

Default repository permission (High) — Organization members must not receive read, write, or admin access to every repository by default. Set Default repository permission to No permission and grant access per repository.

Repository

Branch protection on main (High) — Default branch should require reviews, status checks, and block force-pushes.

Tag immutability (Medium) — Tags should not be movable or deletable after publish.

Immutable releases (High) — Published release assets should not be replaceable.

Deployment environments (Medium) — Repositories with workflows should define GitHub Environments.

Environment approvals (Critical) — Release/production environments should require reviewers.

Deployment branch restriction (Medium) — Release environments should not deploy from arbitrary branches.

Custom protection rules (Medium) — Multiple release environments should mediate promotion with custom protection rules.

Secrets scoped to environments (Critical) — Workflow jobs referencing publishing secrets such as PYPI_TOKEN should gate that job behind an environment: key rather than exposing the secret to every run of the job.

No long-lived registry credentials (Medium) — Workflows should prefer OIDC trusted publishing over static registry tokens such as PYPI_TOKEN or NPM_TOKEN.

Sigstore attestations (Medium) — Repositories that publish releases should attest artifacts.

Sigstore untrusted builder (High) — When attestations exist, the SLSA builder identity must match an accepted prefix (GitHub-hosted runner, GitHub artifact-attestations workflows, or SLSA GitHub generator by default). Unparseable builder IDs fail closed.

Unsigned commits (High) — Recent commits on the default branch must have verified signatures. If you configure an approved signer list, verified commits from anyone else also fail.

Dedicated bot accounts (Low) — Automated commits should come from bot accounts, not humans.

Workflows

Dangerous triggers (Critical on public repositories) — Flags pull_request_target and workflow_run. On private repositories the result is informational and does not create a vulnerability.

Job permission minimization (Medium) — Non-release jobs should not have write permissions.

Impostor commits (Medium) — Pinned Action SHAs must exist in the referenced repository.

Mutable binary downloads (Medium) — Workflows should not download binaries from mutable URLs.

Stale Action pins (Low) — Action SHA pins should still match their version comments.

Archived Actions (Low) — Workflows should not use archived Action repositories.

Self-hosted runners (Critical on public repositories) — Jobs that use runs-on: self-hosted or a runner group persist between jobs and expand the blast radius of a compromised workflow. Public repositories are Critical because pull requests can execute untrusted code on organization-managed machines. On private repositories the result is informational and does not create a vulnerability.

Caching in release workflows (High) — Public release jobs should not use GitHub Actions cache.

Reusable workflow secret overshare (High) — Named secrets passed into a reusable workflow must be declared under the callee’s on.workflow_call.secrets. secrets: inherit is covered by a separate code scanning rule; see OWASP SPVS Coverage.

Invalid workflow YAML (Low) — A workflow file that is not valid YAML is reported with the parser error and its line and column. GitHub Actions cannot run such a workflow, and the other workflow checks skip it.

GitHub Actions YAML rules such as unpinned actions, missing OIDC trusted publishing, install-script policy, and whole secrets context passing run during code scanning. They are listed on the SPVS page, not here.

Dependencies and releases

Lockfile drift (Medium) — The lockfile must satisfy the manifest’s declared version ranges. Compared ecosystems include npm/pnpm/yarn/bun, Python (pyproject.toml / uv.lock), Ruby, Go, Rust, Java (gradle.lockfile), C# (packages.lock.json), PHP, Dart, Swift, and Elixir. See OWASP SPVS Coverage for the file pairs.

Binary blob dependencies (Low) — Lockfiles should not quietly pull packages that ship native binaries.

Tag creation gated on deployment (High) — Creating tags should require a deployment or required workflow.

Fine-grained PATs (Medium) — Post-release automation should use bot accounts and fine-grained tokens, not human or classic PATs.

Examples

Understanding a Google Workspace finding

After connecting Google Workspace, Fencer creates a High severity vulnerability: “Two-factor authentication enforcement is not enabled for domain example.com.” Navigate to Google Admin > Security > 2-Step Verification and enable enforcement. Click Run scan on the SaaS account to confirm the finding resolves.

Remediating Microsoft Entra legacy authentication

Fencer creates a High severity finding: “No Conditional Access policy blocks legacy authentication protocols in Microsoft Entra tenant …” In the Entra portal, go to Security > Conditional Access, create a policy blocking all legacy authentication clients, and enable it in report-only mode before enforcing.

Troubleshooting

A check appears after fixing the setting — Fencer evaluates settings at scan time. Click Run scan on the SaaS account to re-evaluate after making changes.
A check is missing for a connected platform — Verify the integration credentials have sufficient API permissions. Requirements are in each integration’s setup guide.
Severity does not match your risk profile — Use the vulnerability management triage workflow to adjust priority for your organization’s context.