Checks

AKS clusters are evaluated for the Microsoft Defender security profile (securityProfile.defender.securityMonitoring.enabled=true). Defender for Containers extends security monitoring, threat detection, vulnerability assessment, and security posture insights to Azure Kubernetes Service workloads.

Azure Kubernetes Service clusters are evaluated for local account status. Disabling local accounts forces all cluster authentication through Microsoft Entra ID, ensuring centralized identity management, MFA, and conditional access.

AKS clusters with Kubernetes RBAC enforce authorization through roles and bindings mapped to identities and groups.

This evaluates whether the cluster has RBAC enabled to control access to namespaces and cluster-wide resources.

AKS agent pools use only private addressing, with node public IP assignment disabled (enableNodePublicIP=false). Clusters where any pool assigns a public IP to nodes are identified.

AKS clusters expose a private control plane FQDN and agent pools have enable_node_public_ip=false.

The evaluation focuses on the presence of a private FQDN and the absence of public IPs on nodes.

AKS clusters enforce Kubernetes network policies so that pod-to-pod traffic is governed by explicit ingress and egress rules. The finding evaluates whether a cluster has network policy enforcement enabled to support fine-grained, label-based segmentation between workloads.

AWS Amplify apps and their branches are inspected for hardcoded secrets, such as API keys, tokens, or passwords embedded in environment variables or build settings (buildSpec).

Oracle Analytics Cloud endpoints are evaluated for network exposure. Public endpoints must use restricted allowlists of specific IPs/CIDRs; presence of 0.0.0.0/0 or no allowed sources indicates unrestricted access. Instances using a VCN/private endpoint or public endpoints limited to specific sources align with the intended exposure model.

API Gateway custom domain names for REST APIs are assessed for use of a post-quantum (PQ) TLS security policy such as SecurityPolicy_TLS13_1_2_PQ_2025_09. Custom domains with legacy policies such as TLS_1_0 or TLS_1_2 lack hybrid ML-KEM key exchange, leaving captured traffic vulnerable to future quantum decryption.

API Gateway REST APIs are evaluated for access control: an API-level authorizer is present, or all resource methods use an authorization mechanism. Methods marked NONE indicate unauthenticated access.

API Gateway REST API stages with caching have cache data encrypted at rest. The evaluation targets stages where caching is enabled and verifies that stored responses are protected via the Encrypt cache data setting.

API Gateway stage has a client certificate configured so HTTP/S integrations can perform mutual TLS and authenticate API Gateway to the backend

API Gateway REST API stages with stage logging enabled to emit execution or access logs to CloudWatch

Checks API Gateway REST API stage variables for hardcoded secrets such as passwords, API keys, and tokens. Stage variables should reference AWS Secrets Manager or Parameter Store rather than containing plaintext credentials.

Amazon API Gateway REST APIs are evaluated for endpoint exposure: internet-accessible endpoints versus private VPC-only access via interface VPC endpoints (AWS PrivateLink).

API Gateway REST APIs exposed to the Internet are evaluated for an attached authorizer that enforces caller identity (Lambda authorizer or Cognito user pool) on method invocations.

Focus is on whether public endpoints require authenticated requests rather than accepting anonymous calls.

API Gateway REST API stages have AWS X-Ray active tracing enabled to sample incoming requests and produce distributed traces across connected services.

Amazon API Gateway (REST API) stages are assessed for an associated AWS WAF web ACL. The finding reflects whether a web ACL is linked at the stage level.

API Gateway v2 stages have access logging configured to capture request details and deliver them to a logging destination (e.g., CloudWatch Logs or Firehose). The evaluation looks for logging being enabled at each API stage.

API Gateway v2 APIs use authorizers (JWT/Cognito or Lambda) to authenticate requests. This evaluates whether an API has an authorizer configured to control access to its routes.

The Gemini API (a.k.a. Generative Language API, generativelanguage.googleapis.com) uses API keys to authenticate requests for uploaded files and cached content. For projects with the Gemini API enabled, each API key should have API restrictions configured to limit access to specific services.

Google Cloud API keys have API restrictions limiting calls to specific services. The finding checks that keys are restricted to named Google APIs and do not include the broad cloudapis.googleapis.com, indicating keys are scoped only to intended use.

Google Cloud projects are evaluated for active API keys. The finding indicates whether any keys exist and are enabled in the project, regardless of restrictions or usage.

Google Cloud API keys are evaluated for rotation age using their creation_time. Keys created within the last 90 days are treated as recently rotated; keys older than 90 days are treated as overdue.