Checks

GitHub repository default branch enforces required reviews with a minimum of 2 approving reviews before a pull request can be merged.

Assesses whether an approval threshold of at least 2 is configured for code changes targeting the default branch. This protection can be enforced through classic branch protection or repository rulesets.

GitHub repository default branch enforces signed and verified commits (Require signed commits), allowing only commits with valid cryptographic signatures to be pushed or merged. This protection can be enforced through classic branch protection or repository rulesets.

GitHub repository default branch uses required status checks, indicating whether merges are gated by successful check results on pull requests. This protection can be enforced through classic branch protection or repository rulesets.

GitHub Actions repository settings define the default GITHUB_TOKEN permissions granted to every workflow run in the repository.

The evaluation determines whether the repository default is read-only, so that workflows have to opt in to write access through an explicit permissions block.

GitHub repositories are assessed for dependency vulnerability scanning enabled via Dependabot alerts, which monitors the dependency graph for known vulnerable packages and versions.

GitHub repositories declare code ownership via a CODEOWNERS file mapping file patterns to users or teams. This evaluation checks whether such a file exists in standard locations (/, .github/, or docs/) to enable automatic reviewer assignment.

GitHub repository has immutable releases enabled to prevent modification or replacement of published artifacts after publication. When enabled, release assets and binaries become tamper-proof, ensuring artifact integrity throughout the software supply chain.

GitHub repository that remains unarchived and show no activity beyond a configured inactivity window (e.g., 180 days) are identified. The evaluation considers the most recent repository activity to surface long-idle codebases that are still unarchived.

GitHub public repository include a SECURITY.md policy file that tells researchers how to report vulnerabilities. The evaluation focuses on the presence of this file in public repositories.

GitHub repository configuration for secret scanning-which detects secrets (API keys, tokens, passwords) in commits and Git history-is evaluated to determine if detection is active.

AWS Resource Explorer has user-owned indexes present in the account. The assessment determines whether at least one index exists in any enabled Region for resource cataloging and search.

IAM Roles Anywhere profiles that reference an administrative role are assessed for session scoping. A profile defining neither an inline sessionPolicy nor managedPolicyArns vends credentials with the full permissions of its roles. It is flagged only when a referenced role is administrative, since an unscoped session on a least-privilege role is already constrained.

IAM Roles Anywhere trust anchors are assessed for use of a post-quantum digital signature algorithm (ML-DSA). A trust anchor backed by an AWS Private CA whose KeyAlgorithm is RSA or ECC produces signatures vulnerable to forgery by a future quantum attacker, allowing an unintended actor to issue certificates and obtain unauthorized AWS access.

Route 53 records are evaluated for two subdomain takeover vectors: (1) non-alias A records using literal IPs in public AWS ranges that are not assigned to resources in the account (released EIPs/ENI public IPs); and (2) non-alias CNAME records targeting an S3 website endpoint (*.s3-website[.-]<region>.amazonaws.com) whose bucket no longer exists in the account.

Route 53 domain administrative contact has privacy protection enabled, so WHOIS queries return redacted or proxy details.

Evaluates whether contact data is hidden instead of publicly listed.

Route 53 registered domains are assessed for a transfer-lock state, indicated by the clientTransferProhibited status on the domain.

Route 53 public hosted zones have DNS query logging enabled to CloudWatch Logs, recording resolver requests for the zone and writing events to an associated log group.

The User granted Admin privilege system-defined alert rule should be enabled with alerts sent to the alert center, email notifications turned on, recipients set to all super administrators, and severity set to Medium or higher. This ensures administrators are notified when a user is given elevated admin privileges.

The Gmail potential employee spoofing system-defined alert rule should be enabled with alerts sent to the alert center, email notifications turned on, recipients set to all super administrators, and severity set to Medium or higher. This ensures administrators are notified when incoming messages have a sender name matching the directory but from an external domain.

The Government-backed attacks system-defined alert rule should be enabled with alerts sent to the alert center, email notifications turned on, recipients set to all super administrators, and severity set to High or higher. This ensures administrators are notified when Google believes users are being targeted by a government-backed attacker.

The Leaked password system-defined alert rule should be enabled with alerts sent to the alert center, email notifications turned on, recipients set to all super administrators, and severity set to Medium or higher. This ensures administrators are notified when Google detects compromised credentials requiring a password reset.

The User's password changed system-defined alert rule should be enabled with alerts sent to the alert center, email notifications turned on, recipients set to all super administrators, and severity set to Medium or higher. This ensures administrators are promptly notified when user passwords are changed.

The User suspended due to suspicious activity system-defined alert rule should be enabled with alerts sent to the alert center, email notifications turned on, recipients set to all super administrators, and severity set to High or higher. This ensures administrators are notified when Google suspends an account due to a potential compromise.

The Suspicious login system-defined alert rule should be enabled with alerts sent to the alert center, email notifications turned on, recipients set to all super administrators, and severity set to Low or higher. This ensures administrators are notified when Google detects a sign-in attempt that does not match a user's normal behavior.