feat(googleworkspace): add rules service checks

[lydiavilchez]

Context

Rules service checks for the Google Workspace provider. This PR implements 8 CIS controls from Section 6 of the CIS Google Workspace Foundations Benchmark v1.3.0, covering system-defined alert rules that notify super administrators when security relevant events occur in the domain.

Description

Implements 8 checks in a new rules service using the Cloud Identity Policy API (rule.system_defined_alerts namespace):

• 6.1 — rules_password_changed_alert_configured: PASS if alert is ACTIVE, email notifications ON, and recipients include all super admins. FAIL if absent (default: INACTIVE)
• 6.2 — rules_government_backed_attacks_alert_configured: PASS if all 3 conditions met. FAIL if absent (default: ACTIVE but no email notifications)
• 6.3 — rules_suspicious_activity_suspension_alert_configured: PASS if all 3 conditions met. FAIL if absent (default: ACTIVE but no email notifications)
• 6.4 — rules_admin_privilege_granted_alert_configured: PASS if all 3 conditions met. FAIL if absent (default: INACTIVE)
• 6.5 — rules_suspicious_programmatic_login_alert_configured: PASS if all 3 conditions met. FAIL if absent (default: ACTIVE but no email notifications)
• 6.6 — rules_suspicious_login_alert_configured: PASS if all 3 conditions met. FAIL if absent (default: ACTIVE but no email notifications)
• 6.7 — rules_leaked_password_alert_configured: PASS if all 3 conditions met. FAIL if absent (default: ACTIVE but no email notifications)
• 6.8 — rules_gmail_employee_spoofing_alert_configured: PASS if all 3 conditions met. FAIL if absent (default: ACTIVE but no email notifications)

Each check verifies 3 conditions: alert is ACTIVE and sent to the alert center, email notifications are enabled, and recipients include all super administrators. This goes beyond ScubaGoggles, which only checks active/inactive state.

The rule.system_defined_alerts setting only appears in the Policy API when an admin has explicitly modified a rule. Unmodified rules running at Google defaults are handled by the service layer, which applies the documented default state for each rule.

CIS vs API gap: The Policy API does not expose severity level or email notification toggle as separate fields, severity and recipients are nested inside action.alertCenterAction. All 3 CIS conditions are fully verifiable from this structure.

Checklist

Community Checklist

• This feature/issue is listed in here or roadmap.prowler.com
• Is it assigned to me, if not, request it via the issue/feature in here or Prowler Community Slack

• Review if the code is being covered by tests.
• Review if code is being documented following this specification https://github.com/google/styleguide/blob/gh-pages/pyguide.md#38-comments-and-docstrings
• Review if backport is needed.
• Review if is needed to change the Readme.md
• Ensure new entries are added to CHANGELOG.md, if applicable.

SDK/CLI

• Are there new checks included in this PR? Yes / No
  • If so, do we need to update permissions for the provider? Please review this carefully.

UI

• All issue/task requirements work as expected on the UI
• If this PR adds or updates npm dependencies, include package-health evidence (maintenance, popularity, known vulnerabilities, license, release age) and explain why existing/native alternatives are insufficient.
• Screenshots/Video of the functionality flow (if applicable) - Mobile (X < 640px)
• Screenshots/Video of the functionality flow (if applicable) - Table (640px > X < 1024px)
• Screenshots/Video of the functionality flow (if applicable) - Desktop (X > 1024px)
• Ensure new entries are added to CHANGELOG.md, if applicable.

API

• All issue/task requirements work as expected on the API
• Endpoint response output (if applicable)
• EXPLAIN ANALYZE output for new/modified queries or indexes (if applicable)
• Performance test results (if applicable)
• Any other relevant evidence of the implementation (if applicable)
• Verify if API specs need to be regenerated.
• Check if version updates are required (e.g., specs, uv, etc.).
• Ensure new entries are added to CHANGELOG.md, if applicable.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

✅ Conflict Markers Resolved

All conflict markers have been successfully resolved in this pull request.

[github-actions]

Compliance Mapping Review

This PR adds new checks. Please verify that they have been mapped to the relevant compliance framework requirements.

New checks already mapped in this PR

• rules_admin_privilege_granted_alert_configured (googleworkspace): cis_1.3_googleworkspace, cisa_scuba_0.6_googleworkspace
• rules_gmail_employee_spoofing_alert_configured (googleworkspace): cis_1.3_googleworkspace, cisa_scuba_0.6_googleworkspace
• rules_government_backed_attacks_alert_configured (googleworkspace): cis_1.3_googleworkspace, cisa_scuba_0.6_googleworkspace
• rules_leaked_password_alert_configured (googleworkspace): cis_1.3_googleworkspace, cisa_scuba_0.6_googleworkspace
• rules_password_changed_alert_configured (googleworkspace): cis_1.3_googleworkspace, cisa_scuba_0.6_googleworkspace
• rules_suspicious_activity_suspension_alert_configured (googleworkspace): cis_1.3_googleworkspace, cisa_scuba_0.6_googleworkspace
• rules_suspicious_login_alert_configured (googleworkspace): cis_1.3_googleworkspace, cisa_scuba_0.6_googleworkspace
• rules_suspicious_programmatic_login_alert_configured (googleworkspace): cis_1.3_googleworkspace, cisa_scuba_0.6_googleworkspace

Use the no-compliance-check label to skip this check.

[github-actions]

✅ All necessary CHANGELOG.md files have been updated.

[codecov]

Codecov Report

❌ Patch coverage is 95.79288% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.32%. Comparing base (329dfdf) to head (00b6d4f).
⚠️ Report is 17 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11379      +/-   ##
==========================================
+ Coverage   93.96%   96.32%   +2.36%     
==========================================
  Files         237       93     -144     
  Lines       34901     2531   -32370     
==========================================
- Hits        32793     2438   -30355     
+ Misses       2108       93    -2015     

Flag	Coverage Δ
api	?
prowler-py3.10-googleworkspace	96.32% <95.79%> (?)
prowler-py3.11-googleworkspace	96.32% <95.79%> (?)
prowler-py3.12-googleworkspace	96.32% <95.79%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
prowler	96.32% <97.45%> (∅)
api	∅ <ø> (∅)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

🔒 Container Security Scan

Image: prowler:8787e55
Last scan: 2026-05-28 09:18:57 UTC

📊 Vulnerability Summary

Severity	Count
🔴 Critical	13
Total	13

8 package(s) affected

⚠️ Action Required

Critical severity vulnerabilities detected. These should be addressed before merging:

• Review the detailed scan results
• Update affected packages to patched versions
• Consider using a different base image if updates are unavailable

---

📋 Resources:

• Download full report (see artifacts)
• View in Security tab
• Scanned with Trivy

[danibarranqueroo]

Two small suggestions:

• All 8 checks set resource_id="system_defined_alert". Two issues:

  1. camelCase, not snake_case: every other GWS service uses camelCase: calendarPolicies, chatPolicies, securityPolicies, drivePolicies, etc.
  2. Same resource_id across all 8 checks will collapse them into a single row in the API (the resources table is keyed by resource_id, so resource_name gets overwritten by whichever check ran last).

Since each SystemDefinedAlert is a distinct resource, the cleanest fix is a per-rule id:

resource_id=f"systemDefinedAlert/{RULE_NAME}"

• All 8 checks use "forensics-ready", but I think "logging" is a better fit and matches existing precedent.

In the rest of Prowler, "forensics-ready" is used for systems that capture the evidence for investigation (GuardDuty, CloudTrail). "logging" is used for checks that verify alerting on security events is configured.

Something like this works for me for example:

• Credential/auth rules (password_changed, leaked_password, admin_privilege_granted, suspicious_login, suspicious_programmatic_login, suspicious_activity_suspension): ["logging", "identity-access"]
• gmail_employee_spoofing: ["logging", "email-security"] — matches the rest of gmail/
• government_backed_attacks: ["logging"]

[pedrooot]

Nice!!