Supported Services and Risks

Panoptica continually scans your cloud resources for potential risks, security issues and vulnerabilities across dozens of key services. This catalog provides a complete list of the services Panoptica scans across multiple cloud providers and platforms, and the hundreds of risks Panoptica can detect in those services. The results of these scans show up in different aspects of the Panoptica platform:

To view the services Panoptica has identified in your environment, see Asset Inventory.
To view the risks Panoptica has identified, see Security Posture.
To view those risks prioritized and contextualized, see Attack Paths.

The catalog is sorted by provider, service name, and category. In Chrome or Edge, use the Table of Contents to the right to navigate to the information you're looking for. Firefox and Safari, however, are unable to expand a section to display an anchor link within, like Chrome and Edge can. If you're using Firefox or Safari, click the cloud provider header in the Table of Contents (AWS, Azure, GCP, etc.), then select the service you want to expand in the main section.

Amazon Web Services (AWS) - click to collapse

Amazon Web Services (AWS)

Click on a service name below to view a table of the risks Panoptica detects in AWS, along with brief descriptions and attack scenarios.

AWS Certificate Manager

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	ACM Certificate Without Minimum Of 2048-bit Key For RSA Certificate	An ACM certificate that does not use a minimum of 2048-bit key for RSA certificate.	"A key length of 1024 bit is not considered secure, as it can be cracked using brute-force methods. Upgrade your certificates to 2048-bit or 4096-bit RSA certificates which are using stronger encryption algorithms."
Neglected Resource	ACM Certificate Expires In 30 Days	An ACM certificate is going to expire in 30 days.	It is not a best practice to have an expired certificate. An expired certificate can be accidentally deployed to another resource, leading to application errors and credibility damage. Renew the certificate as soon as possible.
Neglected Resource	ACM Certificate Pending Validation	An ACM certificate with 'PENDING_VALIDATION' status.	When an ACM certificate is not validated within 72 hours, it becomes invalid and you have to create a new certificate request.
Neglected Resource	Expired ACM Certificate	An expired ACM certificate.	It is not a best practice to have an expired certificate. An expired certificate can cause an accidental deployment to another resource, leading to application errors and credibility damage.
Neglected Resource	Invalid ACM Certificate	An ACM certificate with 'FAILED' or 'VALIDATION_TIMED_OUT' status.	It is not a best practice to have invalid certificates. Invalid certificates should be deleted.
Neglected Resource	Unused ACM Certificate	Unused ACM Certificate	It is not a best practice to have unused certificates. Unused certificates should be used or removed.

Amazon CloudFront

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	CloudFront Distribution Lacking WAF Protection	This risk highlights a CloudFront distribution that is not protected by a Web Application Firewall (WAF). Without WAF protection, your distribution may be vulnerable to common web exploits that could affect availability or compromise security. To enhance your distribution's security, it's recommended to attach a properly configured WAF to your CloudFront distribution.	"A WAF helps protect web applications by filtering and monitoring traffic. It usually protects web applications from attacks such as cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection. An attacker can use this opportunity to attack your application."
Insecure Configurations	CloudFront Distribution Permitting Insecure HTTP Connections	This risk underscores a CloudFront distribution that allows insecure HTTP connections. Such connections could expose your data to potential risks during transmission. It's advised to enforce secure HTTPS connections for your CloudFront distribution to ensure the security and integrity of your data.	An attacker can gain access to traffic between your CloudFront distribution and the application viewers.
Insecure Configurations	CloudFront Distribution with Logging Disabled	This risk signifies a CloudFront distribution that has logging disabled. Without logging, it can be challenging to monitor and troubleshoot your distribution's activity. It's highly recommended to enable and properly configure logging for your CloudFront distribution to ensure effective operations and prompt issue resolution.	CloudFront distribution logging is used to track all the requests. It is necessary for investigating activities and for auditing purposes.
Insecure Configurations	CloudFront Operating with Unencrypted Origin Server Connection	This risk identifies a CloudFront distribution configured to operate with an unencrypted connection to the origin server. Such a configuration can expose your data to unnecessary risks during transmission. It's highly advised to secure the connection to your origin server with encryption, such as HTTPS, to uphold the integrity and confidentiality of your data.	An attacker can gain access to traffic between your CloudFront distribution and an origin server.
Insecure Configurations	CloudFront With Insecure TLS Ciphers	A CloudFront distribution that does not use secure TLS (Transport Layer Security) protocol versions.	It is recommended to use the latest version of TLS if possible. Older versions (prior to TLS 1.2) may be deprecated or may contain known vulnerabilities that an attacker can use.

Amazon DocumentDB

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	DocumentDB Audit Logs Export Disabled	DocumentDB cluster without export audit logs to Cloudwatch.	Without comprehensive auditing, there's a higher risk of undetected security breaches or unauthorized access to your system.
Insecure Configurations	DocumentDB Cluster has Short Retention Period	DocumentDB cluster has less than 7 days backup retention period.	A backup retention period ensures that you have a reliable copy of your data in case of accidental deletion, corruption, or other data loss events.
Insecure Configurations	DocumentDB without Deletion Protection	Deletion protection is disabled.	Disabling deletion protection in a DocumentDB can introduce several security risks. Deletion protection is a feature that prevents accidental or unauthorized data deletions, and disabling it can make your database more vulnerable to various threats.
Insecure Configurations	DocumentDB Without Storage Encryption	An attacker with access to the DocumentDB can access sensitive data stored in the DB.	This risk indicates an Amazon DocumentDB that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

Amazon DynamoDB

Category	Risk Name	Description	Attack Scenario
Neglected Resource	DynamoDB Table Without Continuous Backup	A DynamoDB table without continuous backups for the point-in-time recovery feature.	It is a best practice to enable continuous backups for your DynamoDB tables. DynamoDB continuous backups, powered by Point-in-time Recovery (PITR) feature, will help you protect your DynamoDB data against accidental writes, deletes, or any loss of data.
Insufficient Monitoring	DynamoDB Streams is disabled	DynamoDB Streams is disabled. DynamoDB Streams is a feature of AWS DynamoDB that captures a time-ordered sequence of item-level modifications in any DynamoDB table and stores this information in a log for up to 24 hours. Whenever an application performs create, update, or delete operations on items in the table, DynamoDB Streams writes a record of the changes to a stream. When DynamoDB Streams is disabled for a table, no stream records will be captured or available for that table. This implies that any applications or services that depend on this stream for triggers or data will not receive any updates. Also, any existing stream data for the table will be inaccessible, and the history of changes will not be stored.	The absence of DynamoDB streams means there is no real-time monitoring or auditing trail of item-level changes, which could delay the detection of unauthorized modifications to the database. As a result it could potentially give an attacker more time to operate unnoticed within the system.
Insufficient Encryption	DynamoDB Encrypted at Rest with Amazon DynamoDB Key	AWS DynamoDB table encrypted with Amazon DynamoDB key.	KMS service allows you to easily create, rotate, disable and audit Customer Master Keys created for your Amazon DynamoDB. Using a default Amazon DynamoDB key to encrypt DynamoDB table in AWS is not recommended due to limited control over key management, potential security risks from shared keys across accounts, and inadequate support for key rotation.
Insecure Configurations	DynamoDB Table without Deletion Protection	Deletion protection is disabled.	Disabling deletion protection in DynamoDB can introduce several security risks. Deletion protection is a feature that prevents accidental or unauthorized data deletions, and disabling it can make your database more vulnerable to various threats.
Insufficient Encryption	DynamoDB Encrypted at Rest with AWS Managed Key (Single)

Amazon EC2

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Default Security Group Assignment	The EC2 instance uses the default Security Group.	An attacker might exploit misconfuguration or wide allowed outbound IP range to obtain network access to the EC2 instance.
Insecure Configurations	EC2 Classic Instance Not Operating Within a VPC	This risk underscores an EC2 Classic instance that is not operating within a Virtual Private Cloud (VPC). Operating outside of a VPC may expose your EC2 instance to unnecessary security risks and limit control over network configuration. It's strongly advised to migrate your EC2 Classic instances to a VPC, providing an additional layer of security and increased control over networking aspects, to bolster your system security.	Current workloads might be interrupted.
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf.
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0.
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.
Public Exposure	Public AWS EBS Snapshot	Publicly shared Elastic Block Store (EBS) volume snapshot with all other AWS accounts.	An attacker can use the public shared EBS snapshot in its own account and potentially expose sensitive data.
Neglected Resource	Unassociated Elastic IP Address	The Elastic IP is unused, not associated with any resource in the cloud environment.	An attacker might leverage the neglected Elastic IP to bypass security mechanisms or direct traffic to a malicious server.
Public Exposure	Public AWS AMI	Publicly shared AWS AMI with all other AWS accounts.	An attacker can attach the public shared AMI to a machine in the attacker's AWS account and inspect the image.

Amazon Elastic Container Registry

Category	Risk Name	Description	Attack Scenario
Permissive Access	Private ECR Repository Allows Anonymous Users To Pull Images	Private ECR repository allowing anyone to pull images.	An attacker can pull images from a private repository.
Permissive Access	Private ECR Repository Allows Anonymous Users To Push Images	Private ECR repository with permissions to push images.	An attacker can push a malicious image to the repository.
Insecure Configurations	Private ECR Repository Without KMS Key	Private ECR repository without KMS encryption.	KMS provides more control over the repository encryption.
Insecure Configurations	Public ECR Repository Allows Anonymous Users Access	Public ECR repository enables any user to perform ECR actions.
Insecure Configurations	Public ECR Repository Allows Anonymous Users To Push Images	Public ECR repository with permissions to push images.	An attacker can push a malicious image to the repository.

Amazon ECS

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	"When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. \nThe metadata information is available by making a request to the IP address of 169.254.169.254. \nThe current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf."
Insecure Configurations	ECS Container Operating in Elevated Privilege Mode	This risk signifies an ECS container that's operating in a privileged mode. When a container is run in privileged mode, it holds potential access to all devices on the host system, thereby posing a significant security risk. This unrestricted access could lead to unauthorized activities or data breaches if the container were to be compromised. It's highly recommended to review the necessity of privileged mode for this container. If not required, a prompt action to modify the container's access privileges is advised to uphold system security and integrity.	An attacker with access to the container can gain unauthorized access to other resources in the enviornment.
Insecure Configurations	ECS Container with Elevated System Administrator Capabilities	This risk underscores an ECS container configured with CAP_SYS_ADMIN capabilities. This configuration grants the container nearly unrestricted system-level permissions equivalent to the root user on the host, which can significantly amplify the potential impact of a security breach if the container is compromised. It's essential to reassess the necessity of such elevated privileges. If these superuser capabilities are not necessary for the container's operations, it is strongly advised to reduce its permissions promptly, thereby bolstering system security and reducing potential attack vectors.	`CAP_SYS_ADMIN` is equivalent to root. An attacker with access to the container can gain root privileges."
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0.
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

Amazon EKS

Category	Risk Name	Description	Attack Scenario
Credentials Exposure	EKS Cluster Operating Without Secrets Encryption	This risk identifies an EKS cluster that is operating without secrets encryption. The absence of encryption could expose your sensitive information and make it vulnerable to unauthorized access or breaches. It's strongly advised to enable secrets encryption for your EKS cluster to enhance the protection of sensitive data. OWASP K08:2022 Secrets Management Failures	By default, Kubernetes secrets are stored in Base64 encoding in the etcd. An attacker with access to the cluster etcd, will be able to use the stored secrets and compromise your cluster.
Insecure Configurations	EKS Cluster Running With Logging Configurations Disabled	This risk signifies an EKS cluster that is operating with disabled logging configurations. Proper logging provides crucial insights into your system's operations and potential issues. A disabled logging configuration could hinder problem detection and system monitoring. It's highly recommended to enable and configure appropriate logging for your EKS cluster to ensure efficient operations and issue resolution. OWASP K05:2022 Inadequate Logging and Monitoring	Logging provides audit and diagnostic logs directly from EKS to CloudWatch Logs in your account. These logs make it easy for you to secure and run your clusters.
Public Exposure	Publicly Accessible EKS API Server Endpoint	This risk underscores an EKS API Server Endpoint that is publicly accessible. Public access to your API Server Endpoint could potentially expose your system to unauthorized access and possible security threats. It's advised to review and restrict access to your EKS API Server Endpoint, limiting it to necessary IP ranges or secure VPN connections, to bolster system security. OWASP K09:2022 Misconfigured Cluster Components	An attacker can access the Kubernetes API server from external IP address and use it as an optional entry point into the environment.
Inadequate Authorization & Authentication	Weak Password on Linux Non-Privileged User	Weak passwords for non-privileged Linux users expose systems to unauthorized access risks.	Compromised accounts could lead to data leaks or be a pivot point for deeper network infiltration.
Inadequate Authorization & Authentication	Weak Password on Linux Privileged User	Weak passwords on privileged Linux accounts pose a critical threat to system security.	Attackers gaining privileged access can execute commands, alter system configurations, or access sensitive data.
Inadequate Authorization & Authentication	Weak Password on Windows Standard User	Standard Windows accounts with weak passwords increase the vulnerability to system breaches.	Unauthorized access might result in information theft, malware installation, or user impersonation.
Inadequate Authorization & Authentication	Weak Password on Windows Administrator	Weak passwords in Windows administrator accounts significantly elevate the risk of system compromise.	Critical system operations can be hijacked, leading to full system control, data exfiltration, or widespread system damage.

Amazon EFS

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Default Security Group
Insecure Configurations	Security Group with Inappropriately Configured CIDR IP	This risk highlights a Security Group with a misconfigured CIDR IP, which may expose your resources to unintended networks, leading to potential unauthorized access. A swift review and correction of CIDR IP configurations in your security groups is strongly recommended to uphold network security.	The Instances that are connected to this security group, can be accidentally exposed to the Internet and compromised.
Public Exposure	Security Group Allows Access From Any IP (0.0.0.0/0)	A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to any port.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group Permits Connections From Any IP (0.0.0.0/0)	This risk points to an AWS Security Group configured to allow incoming connections from any IP address, denoted by the range 0.0.0.0/0. This unrestricted access can lead to potential unauthorized access and data breaches. It's recommended to validate the need for such open access, and if it is not required, promptly implement stricter access control based on specific IP addresses or ranges.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Exposed RDP Port	This risk identifies a Security Group that has the RDP port (3389) open to the public, posing a significant security risk. Unauthorized access to the RDP port can potentially allow cyber attackers to control your AWS resources. It's crucial to review and restrict access to the RDP port, limiting it to specific, necessary IP ranges or secure VPN connections, to strengthen your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Exposed Telnet Port	This risk underscores a Security Group that has the Telnet port (23) open to the public. An open Telnet port can be a significant security vulnerability as it can allow unauthorized access to your AWS resources. This exposure could potentially lead to unauthorized data access, data breaches, or unwanted modifications. It's highly advised to review and tighten access to the Telnet port, limiting it to necessary IP ranges or more secure protocols. Swift action to restrict this access will greatly enhance your AWS security posture and reduce potential cyber attack vectors.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open Cassandra Port	This risk signifies a Security Group that has the Cassandra port (9142) open to the public. This can allow unauthorized access to your Cassandra databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group With Open Kubernetes Kubelet Port (10250)	A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to Kubernetes Kubelet port (10250).	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open MySQL/MariaDB Port	This risk points to a Security Group that has the MySQL/MariaDB port (3306) open to the public. This can allow unauthorized access to your MySQL/MariaDB databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, greatly enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open Redis Port	This risk signifies a Security Group with an open Redis port (6379), providing public access. This could potentially expose your Redis databases to unauthorized access and possible security breaches. A swift action to review and restrict access to the Redis port, limiting it to necessary IP ranges or secure VPN connections, is advised to fortify your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Kafka Port	This risk identifies a Security Group with an open Kafka port (9092), providing public access. This configuration could potentially expose your Kafka servers to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kafka port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Kibana Port	This risk signifies a Security Group with an open Kibana port (5601), providing public access. This could potentially expose your Kibana instances to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kibana port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Memcached Port	This risk highlights a Security Group configured with an open Memcached port (11211), allowing public access. This configuration can potentially expose your Memcached servers to unauthorized access and data breaches. It's recommended to promptly review and restrict access to the Memcached port, limiting it to necessary IP ranges or secure connections, thereby fortifying your server security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Redshift Port	This risk points to a security group configuration that leaves the Amazon Redshift port (5439) open to the public. An exposed Redshift port can increase the risk of unauthorized access and potential data breaches. It's recommended to verify the need for such a configuration and, if unnecessary, promptly restrict access to this port to enhance the security of your Redshift clusters.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible RPC Port	This risk highlights a Security Group configured with an open RPC port (135), making it publicly accessible. This configuration can potentially allow unauthorized access to your AWS resources. Open RPC ports are known to be vectors for certain types of cyber attacks, potentially leading to data breaches or unauthorized modifications. It's strongly recommended to review and limit access to the RPC port, confining it to necessary IP ranges or secure connections. Immediate action to secure this access will substantially enhance your AWS security and reduce potential cyber threats.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Exposed MSSQL Port	This risk signifies a Security Group configured with an open MSSQL port (1433), granting public access. This unrestricted access can potentially expose your SQL Server databases to unauthorized access and malicious activities. It's advised to immediately review and restrict the MSSQL port access to specific, necessary IP ranges or secure connections, enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Exposed Splunkd Port	This risk identifies a Security Group that has the Splunkd port (8089) open to the public. This configuration potentially leaves your Splunkd services vulnerable to unauthorized access and cyber threats. It's strongly recommended to review and limit access to the Splunkd port, confining it to specific, trusted IP ranges or secure VPN connections, to enhance your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted FTP Ports	This risk highlights a Security Group that has FTP ports (20/21) open to the public. An open FTP port can allow unauthorized access to your AWS resources, potentially leading to data breaches, misuse, or unwarranted changes. It's strongly recommended to review and tighten access to these FTP ports, limiting them to specific, necessary IP ranges or secure connections. Prompt action to restrict this access will significantly enhance your AWS security and reduce exposure to potential cyber threats.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted PostgreSQL Port	This risk highlights a Security Group with an open PostgreSQL port (5432). This configuration can expose your PostgreSQL databases to unauthorized access and potential malicious activities. Promptly reviewing and restricting access to the PostgreSQL port, confining it to necessary IP ranges or secure connections, is strongly recommended to enhance your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted SMB Port Access	This risk category identifies a Security Group that has the SMB port (445) openly accessible to the public. An open SMB port can provide an entry point for unauthorized access to your AWS resources, potentially leading to data breaches or malicious modifications. This port is often targeted for exploits like the WannaCry ransomware attack. It's strongly recommended to review and restrict access to the SMB port, confining it to specific, necessary IP ranges or secure VPN connections. Taking immediate action to limit this access will significantly enhance your AWS security posture and reduce potential attack surfaces.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted SSH Port Access	This risk identifies a Security Group that has the SSH port (22) open to the public, potentially permitting unauthorized access to your AWS resources. It's crucial to review and restrict access to the SSH port, confining it to specific, necessary IP ranges or secure VPN connections, to bolster your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured DocDB Port	This risk indicates a Security Group that has the DocDB port (27017) open to the public. This configuration potentially leaves your DocumentDB databases exposed to unauthorized access and potential malicious actions. A swift review and restriction of access to the DocDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured Elasticsearch Ports	This risk highlights a Security Group with Elasticsearch ports (9200/9300) open to the public. These open ports can potentially expose your Elasticsearch clusters to unauthorized access and possible cyber threats. Immediate review and restriction of access to these ports, limiting them to necessary IP ranges or secure connections, is strongly advised to bolster your cluster security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured OracleDB Port	This risk highlights a Security Group that has the OracleDB port (1521) open to the public. This configuration potentially leaves your Oracle databases exposed to unauthorized access and cyber attacks. A swift review and restriction of access to the OracleDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.

Amazon ElastiCache

Category	Risk Name	Description	Attack Scenario
Permissive Access	Elasticache User (Not Default) Access String Allows Access to All Keys and Commands	Allowing access to all keys and commands through the Elasticache User Access String provides overly broad and unrestricted access, which can lead to unauthorized data manipulation or misuse.	An attacker gains access to the Elasticache User Access String with permissions for all keys and commands. They could potentially launch a series of malicious operations, such as deleting critical data, injecting harmful commands, or exfiltrating sensitive information, posing a significant security threat to the system's integrity and confidentiality.
Permissive Access	Elasticache User without Authentication	When a user in Elasticache lacks authentication, a significant security vulnerability arises as there are no authentication mechanisms in place to verify the legitimacy of user requests, potentially exposing the system to unauthorized access and misuse.	An attacker could impersonate a user to gain unrestricted access to the cluster. This could lead to unauthorized data retrieval, manipulation, or even the injection of malicious data into the cache, compromising data integrity.
Permissive Access	Elasticache Default User is in UserGroups	In Elasticache, a default user is automatically configured with the user ID and name "default," and it is added to all user groups, while remaining immutable and unable to be deleted or modified. This user is granted an access string that allows it to execute all commands and access all keys, creating a potential security vulnerability by providing overly broad and unmodifiable access privileges.	An attacker gains access to the cluster using the default user, taking advantage of the absence of authentication requirements and the user's full access privileges, which allows them to perform unauthorized operations.
Permissive Access	Non Default Elasticache User Not Associated With Any Group	A user not associated with any group.
Permissive Access	Non Default Elasticache User Not Associated With Any Group that Has High Permissions	A user in Elasticache who possesses a full access string or is authenticated independently (without relying on IAM) lacks the security benefits of centralized access control and proper management, thereby increasing the risk of unauthorized access, misconfigurations, and making it challenging to efficiently audit and administer user permissions.	An attacker discovers an unsupervised Elasticache user, initially created without specific permissions. If this user is later added to a group with elevated privileges without proper review, the attacker seizes the moment, gaining unauthorized access to critical resources.
Insufficient Encryption	Elasticache Encryption by Rest is disabled	Disabling encryption by rest in AWS ElastiCache can potentially lead to security vulnerabilities, as sensitive data may become exposed to potential unauthorized access, data breaches, or compromises due to the absence of encryption safeguards for stored data.	An attacker gains unauthorized access to the Elasticache cluster. Since Encryption at Rest is disabled, they can easily access and exfiltrate sensitive data, such as cached passwords or confidential information, potentially leading to data breaches or unauthorized data exposure.
Insufficient Encryption	Elasticache Encryption by Transit is disabled	Disabling Encryption in Transit in Elasticache creates a security problem by allowing data transmitted between clients and the cluster to be susceptible to interception, potentially compromising data confidentiality and integrity.	An attacker with access to the network infrastructure or a compromised intermediary device can exploit Elasticache Encryption in Transit being disabled to intercept and eavesdrop on unencrypted data packets transmitted between clients and the cache, potentially compromising data confidentiality and integrity.
Insufficient Encryption	Elasticache Serverless Uses AWS Managed KMS	AWS Elasticache Serverless encrypted with AWS managed key.	KMS service allows you to easily create, rotate, disable and audit Customer Master Keys created for your Amazon Elasticache. Using a default AWS Key Management Service (KMS) key to encrypt Elasticache Serverless in AWS is not recommended due to limited control over key management, potential security risks from shared keys across accounts, and inadequate support for key rotation.
Insecure Configurations	Elasticache User with Password Authentication Only	When a user in Elasticache relies solely on authentication by password, the security concern arises if the chosen password is weak or easily guessable, as it can create a vulnerability where malicious actors may successfully guess or crack the password, leading to unauthorized system access and potential compromises to data integrity and confidentiality.	An attacker can employ brute-force or dictionary attacks to repeatedly guess the password.
Insufficient Encryption	Elasticache Serverless Uses AWS Managed KMS	AWS Elasticache Serverless encrypted with AWS managed key.	KMS service allows you to easily create, rotate, disable and audit Customer Master Keys created for your Amazon Elasticache. Using a default AWS Key Management Service (KMS) key to encrypt Elasticache Serverless in AWS is not recommended due to limited control over key management, potential security risks from shared keys across accounts, and inadequate support for key rotation.

Amazon ELB

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf.
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0.
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

AWS IAM

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	IAM User Access Key Unrotated for Over 90 Days	This risk identifies an Amazon IAM (Identity and Access Management) user whose access key hasn't been rotated for over 90 days. Keeping access keys unrotated for prolonged periods can increase the risk of unauthorized access if the keys are compromised. It's recommended to adopt a practice of regular key rotation, ideally, every 90 days, to ensure secure access management.	An attacker with access to the access key can achieve the user's privileges and perform unauthorized actions in the account.
Identity & Access Management	IAM User Holding Unused, Outdated Access Keys	This risk signifies an IAM user that has access keys not used for over 90 days. Outdated, unused keys can pose a significant security risk if they are compromised. It's strongly advised to review and rotate old access keys, promptly deactivating any that are unused to enhance account security.	An attacker with access to the access key can achieve the user's privileges and perform unauthorized actions in the account.
Identity & Access Management	Inactive IAM User Access Key	This risk indicates an inactive access key associated with an Amazon IAM (Identity and Access Management) user. Despite being inactive, these keys can pose a potential security risk if they were to be reactivated without appropriate controls. It's recommended to routinely review and manage inactive keys, eliminating or rotating those that aren't needed, to maintain a robust access management system.
Identity & Access Management	IAM User With Old Password For Over 90 Days	User unchanged his password in the last 90 days.	Attacker can use this user for getting access to compromised environment.
Identity & Access Management	IAM User Without MFA	This risk identifies an Amazon IAM (Identity and Access Management) user who doesn't have Multi-Factor Authentication (MFA) enabled. MFA provides an extra layer of security by requiring more than just a password for user authentication. Without MFA, the user's account is at a higher risk of unauthorized access. Enabling MFA for all IAM users is strongly recommended to bolster account security.	An attacker can bypass authentication with a password only.
Identity & Access Management	Inactive IAM User In IAM Credential Report	Inactive user is user with unused access key or user that didn't connect to aws console in the last 90 days.	Attacker can use inactive user credentials that leading to environment compromised
Identity & Access Management	IAM Role Configured with Predictable External ID	This risk points to an IAM role that has a predictable external ID. Such easily guessed IDs can potentially allow unauthorized entities to assume the role, posing a risk of unauthorized access and potential security breaches. A review and update of all IAM role external IDs, ensuring they are complex and unpredictable, is strongly recommended to maintain secure role access.	"An attacker can trick a third party that can assume a role in your account, and gain unauthorized access to your resources. External ID is a unique identifier that third parties use to assume a role in your account, and its purpose is to prevent the confused deputy problem. When the external id can be easily guessed, the confused deputy remains a problem. We look for external id values that have less than three different types of characters, contain sequences such as 123, abc, qwe, and more, or that are included in the role ARN (account id, role name)."
Identity & Access Management	IAM Role Configured with Unrestricted Assume Role Permissions	This risk identifies an IAM Role that has been configured to allow 'Assume Role' permissions to any AWS user. This broad configuration increases the potential of unauthorized access to the resources associated with this IAM role. It can lead to misuse of permissions, data breaches, or even alteration of your AWS services. It's highly recommended to review and restrict the 'Assume Role' permissions to specific users or roles, thereby enhancing your AWS security posture by reducing unnecessary exposure.	An attacker with access to any AWS account can assume the role and use its permissions.
Inadequate Authentication & Authorization	Root user with active access key	Root user with active access key.	Providing access keys to the AWS root user is highly risky, as it allows full, unrestricted access to the entire account, potentially leading to unauthorized actions and severe security breaches.
Permissive Access	IAM group with administrator policy attached	IAM user group with a managed administrator access policy attached.	A privileged IAM group allows its users administrator access to AWS cloud services and resources.
Insecure Configurations	IAM Group with full access policy attached	IAM user group with a managed full access policy attached.	A privileged IAM group allows its users full access to AWS cloud services and resources.

AWS Key Management Service

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	KMS Key Allows Anonymous Access	A key policy that allows certain actions to all users.	If there are no other access mechanisms with deny statements that override this permissive key policy, an attacker will be able to perform the specified actions on your key.
Neglected Resource	KMS Customer Managed Key Without Rotation	A customer-managed key with disabled key rotation.	Key rotation reduces the risk of a compromised key being used by an attacker to access your encrypted resources.
Neglected Resource	Unusable Customer Managed Key	A customer-managed KMS key that can't be used. The key is either disabled or pending deletion.	It is not a best practice to have usable keys as it can harm key management processes and increase your monthly AWS bill.

AWS Lambda

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	"When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf."
Insecure Configurations	Lambda Function Security Group
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	"This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0."
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.
Public Exposure	Public Lambda Function Without Authentication	"Lambda Function that is configured with a function URL and without authentication. OWASP A6:2017 <a href=""https://owasp.org/www-pdf-archive/OWASP-Top-10-Serverless-Interpretation-en.pdf""Security> Misconfiguration."	A function URL is a dedicated HTTPS endpoint that allows access and invocation of the function from the public Internet. The configuration of the detected function also supports unauthenticated access, which allows anyone from the Internet to trigger it.
Unsupported Software	Lambda Function Operating on Deprecated Runtime	"This risk identifies a Lambda function operating on a runtime that is deprecated or has reached end of support. Operating on such a runtime can expose the function to unpatched vulnerabilities and reduce overall performance. An immediate update to a supported runtime is recommended to ensure the security and efficiency of your Lambda function. OWASP A6:2017 <a href=""https://owasp.org/www-pdf-archive/OWASP-Top-10-Serverless-Interpretation-en.pdf""Security> Misconfiguration."	An attacker can exploit known unpatched vulnerabilities in the Lambda function runtime

Amazon Neptune

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Neptune Cluster has Short Retention Period	Neptune database has less than 7 days backup retention period.	A backup retention period ensures that you have a reliable copy of your data in case of accidental deletion, corruption, or other data loss events.
Insecure Configurations	Neptune DB Storage Encrypted Enabled
Insecure Configurations	Neptune IAM Database Authentication Disabled	IAM Database Authentication in Amazon Neptune provides an additional layer of security for accessing your Neptune database. Instead of using a traditional username and password for database authentication, IAM Database Authentication allows you to use AWS Identity and Access Management (IAM) credentials to authenticate to your Neptune database.	Attackers might attempt to break traditional authentication methods by brute force or password guessing attacks.
Insecure Configurations	Neptune without Deletion Protection	Deletion protection is disabled.	Disabling deletion protection in Neptune DB can introduce several security risks. Deletion protection is a feature that prevents accidental or unauthorized data deletions, and disabling it can make your database more vulnerable to various threats.
Insecure Configurations	Neptune Without Storage Encryption	An attacker with access to the Neptune database can access sensitive data that stored in it.	This risk indicates an Amazon Neptune database that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

AWS OpenSearch

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Node-to-Node Encryption is Disabled for Amazon OpenSearch Domain	Node-to-node encryption disabled in Amazon OpenSearch Domain.	An attacker who has gained access to the data stored in the domain node can easily read it.
Insecure Configurations	Amazon OpenSearch Domain Allows Unencrypted HTTP Traffic	Amazon OpenSearch domain is configured to allow unencrypted HTTP traffic.	An attacker can easily intercept and manipulate unencrypted HTTP traffic, potentially stealing sensitive information.
Public Exposure	Amazon OpenSearch Domain is Publicly Accessible	Amazon OpenSearch Domain is set to public, potentially exposing it to unauthorized access and attacks.	An attacker may target a publicly accessible domain endpoint and use attacks such as Denial of Service or Brute-force, among others.
Insecure Configurations	Encryption at Rest is Disabled for Amazon OpenSearch Domain	Encryption at rest is disabled for Amazon OpenSearch Domain, increasing the risk of unauthorized access to your data. If enabled, the feature encrypts the following aspects of a domain: All indexes (including those in UltraWarm storage); OpenSearch logs; Swap files; All other data in the application directory; Automated snapshots	An attacker who has gained access to the data stored in the domain can easily read it.
Insecure Configurations	Automatic Software Updates Feature are Disabled for Amazon OpenSearch Domain	Amazon OpenSearch Domain's automatic software updates are turned off.	An attacker can abuse outdated software to exploit known vulnerailities.

Amazon RDS

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	"When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf."
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	"This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0."
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.
Data Security	RDS Cluster Without Configured Backup Retention	This risk signifies an Amazon RDS cluster not configured for backup retention. A lack of backup retention can lead to data loss in case of system failures or errors. It's highly recommended to configure a suitable backup retention policy to protect data and ensure the possibility of recovery in the event of unexpected issues.	The backup retention period determines the period for which you can perform a point-in-time recovery.
Data Security	RDS Database Instance Publicly Accessible	This risk identifies an Amazon RDS database instance configured to allow public access, making it potentially reachable by any AWS user or internet user. Publicly accessible database instances pose a heightened risk of unauthorized data access and potential data breaches. It's recommended to validate whether such public access is necessary and, if not, promptly restrict the access to enhance the security of your data.	An attacker can access the DB leading to data exposure.
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	"When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf."
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	"This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0."
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.
Data Security	RDS Cluster Database Snapshot Publicly Shared	This risk signifies a publicly shared Amazon RDS cluster database snapshot, making it accessible to any AWS user. Publicly sharing snapshots elevates the risk of unauthorized access, data misuse, or breaches. The necessity of this public sharing should be verified; if not required, immediate action to restrict the sharing is advised to minimize potential security risks.	DB cluster snapshot is public and available for any Amazon Web Services account to copy or restore.
Data Security	RDS Cluster Database Snapshot Without Encryption	This risk highlights an Amazon RDS cluster database snapshot that is without encryption. Encryption serves as a vital security layer, safeguarding sensitive data from unauthorized access and potential breaches. An unencrypted snapshot increases the likelihood of data misuse if it's unintentionally accessed or shared. Prompt action to apply encryption is recommended to ensure the security of the snapshot's data.	An attacker can access the data stored in the RDS cluster database snapshot without decrypting it.
Data Security	RDS Database Cluster Snapshot Externally Shared	This risk signifies an Amazon RDS database cluster snapshot shared with an external AWS account, potentially risking exposure of sensitive data. Uncontrolled or untrusted accounts might misuse or further expose this data, leading to potential breaches and compliance issues. Immediate investigation and appropriate action, such as revoking sharing if it violates security policies, are recommended to mitigate potential risks.	An attacker with access to the external account can copy the database cluster snapshot and create a RDS database cluster.
Data Security	RDS Database Snapshot Externally Shared	This risk signifies an Amazon RDS database snapshot shared with an external AWS account, potentially risking exposure of sensitive data. Uncontrolled or untrusted accounts might misuse or further expose this data, leading to potential breaches and compliance issues. Immediate investigation and appropriate action, such as revoking sharing if it violates security policies, are recommended to mitigate potential risks.	An attacker with access to the external account can copy the database snapshot and create a RDS database.
Data Security	RDS Database Snapshot Publicly Shared	This risk signifies a publicly shared Amazon RDS database snapshot, making it accessible to any AWS user. Publicly sharing snapshots elevates the risk of unauthorized access, data misuse, or breaches. The necessity of this public sharing should be verified; if not required, immediate action to restrict the sharing is advised to minimize potential security risks.	DB snapshot is public and available for any Amazon Web Services account to copy or restore it.
Data Security	RDS Database Snapshot Without Encryption	This risk highlights an Amazon RDS database snapshot that is without encryption. Encryption serves as a vital security layer, safeguarding sensitive data from unauthorized access and potential breaches. An unencrypted snapshot increases the likelihood of data misuse if it's unintentionally accessed or shared. Prompt action to apply encryption is recommended to ensure the security of the snapshot's data.	An attacker can access the data stored in an RDS snapshot without decrypting it.
Inadequate Logging & Backup	RDS instance without configured backup retention	This risk signifies an Amazon RDS instance not configured for backup retention. A lack of backup retention can lead to data loss in case of system failures or errors. It's highly recommended to configure a suitable backup retention policy to protect data and ensure the possibility of recovery in the event of unexpected issues.	The backup retention period determines the period for which you can perform a point-in-time recovery.

Amazon Redshift

Category	Risk Name	Description	Attack Scenario
Data Security	Redshift Cluster Publicly Accessible	This risk points to an Amazon Redshift cluster configured to be publicly accessible, potentially making it reachable by any internet user. Publicly accessible Redshift clusters can significantly raise the risk of unauthorized data access and potential data breaches. It's recommended to validate the need for such public access and, if unnecessary, promptly restrict access to strengthen your data security.	An attacker can access Redshift cluster through the cluster endpoint.
Data Security	Redshift Cluster Without Encryption	This risk identifies an Amazon Redshift cluster that has not been configured for encryption, a crucial security measure to protect sensitive data from unauthorized access. Unencrypted Redshift clusters present an increased risk of data exposure or misuse. Implementing encryption to secure your data and adhere to best practices and compliance regulations is strongly recommended.	An attacker can access the data stored in your Redshift cluster.
Insecure Configurations	Redshift is Using Default Port	Using the default port (5439) in AWS Redshift indicates a potential security vulnerability due to the default configuration, which could expose the database clusters to increased risk of unauthorized access and attacks targeting known default ports.	An attacker scans for open ports and identifies an AWS Redshift cluster using the default port 5439, exploits this known configuration by attempting brute-force or dictionary attacks to gain unauthorized access to the database, potentially leading to data theft or manipulation.
Public Exposure	AWS RedShift Enhanced VPC Routing is Disabled	AWS Redshift enhanced VPC routing is disabled.	When using AWS Redshift enhanced VPC routing, Amazon Redshift forces all COPY and UNLOAD traffic between your cluster and your data repositories through your virtual private cloud (VPC) based on the Amazon VPC service. If enhanced VPC routing is not turned on, Amazon Redshift routes traffic through the internet, including traffic to other services within the AWS network.
Inadequate Logging & Backup	Redshift User Activity Logging is Disabled	AWS Redshift logs information about connections and user activities in your database are disabled.	An attacker exploits the lack of AWS Redshift user activity logging, enabling them to perform unauthorized actions within the database without leaving a trace, potentially leading to data breaches or unauthorized modifications.
Inadequate Logging & Backup	Redshift has Short Retention Period	AWS Redshift Cluster has less than 7 days backup retention period.	A backup retention period ensures that you have a reliable copy of your data in case of accidental deletion, corruption, or other data loss events.
Insufficient Encryption	Redshift SSL is Disabled	Redshift cluster is not configured to require SSL.	If SSL is disabled, an attacker could intercept the unencrypted database traffic, potentially capturing sensitive data such as passwords and queries.
Insecure Configurations	RedShift uses default Master Username	Redshift uses default master username.	An attacker can exploit widely known default credentials to gain unauthorized entry into the system.
Insufficient Encryption	Redshift Cluster Uses Default KMS

Amazon Route 53

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Public Route53 Hosted Zone Holding Private DNS Record	This risk points to a Route53 hosted zone that is public yet contains private DNS records. This configuration can lead to unintended exposure of internal resource information, heightening the risk of unauthorized access and potential breaches. A prompt review of the hosted zone's configuration to ensure appropriate privacy for DNS records is strongly recommended.	All DNS in a public hosted zone can be queried from any external internet IP address. An attacker can resolve these records and gain information about your environment.
Insecure Configurations	Route53 Without Auto Renew Domain	A Route 53 domain with the auto renew feature not enabled.	With the auto renew feature enabled, your domains won't get expired. Expired domains leave your application exposed to multiple attacks, so it is best practice to enable the feature.
Insecure Configurations	Route53 Without Domain Transfer Lock	A Route 53 domain with Transfer Lock set to false.	An attacker may be able to transfer your domain to another domain name registrar, and hijack your domain.

Neglected Resource	Route53 Domain Expires In 30 Days	A Route 53 domain is going to be expired in 30 days.	Expired domains leave your application exposed to multiple attacks. Extend the expiration date as soon as possible.
Neglected Resource	Route53 Domain Expires In 7 Days	A Route 53 domain is going to expire in 7 days.	Expired domains leave your application exposed to multiple attacks. Extend the expiration date as soon as possible.
Neglected Resource	Route53 With Expired Domain	An expired domain name is registered in Route 53.	An attacker can hijack the expired domain and use it for malicious purposes. In addition, an expired domain can cause failures or downtime in your application.

Amazon S3

Category	Risk Name	Description	Attack Scenario
Permissive Access	Cross-Account S3 Bucket Access	This risk indicates that an Amazon S3 bucket is configured to permit access from users in different AWS accounts. If not strictly controlled, cross-account access can elevate the risk of unauthorized data access or leakage. It's advisable to scrutinize the necessity of this access configuration and promptly modify the bucket's access policies to enhance your data security if not required.	An attacker from any AWS account can define this S3 bucket as their target bucket for the service logs or configuration.
Data Security	S3 Bucket Contains Potentially Public Objects	This risk identifies an Amazon S3 bucket that contains objects that may be publicly accessible, thereby potentially enabling any internet user to access them. Potentially shared objects in an S3 bucket can heighten the risk of unauthorized data access and potential data breaches. It's recommended to review these objects and their access controls, and if public access is not necessary, promptly update their permissions to secure your data.	An attacker can maybe access some objects in the bucket leading to data exposure.
Data Security	S3 Bucket Encrypted with AWS S3 Managed Key	S3 bucket encrypted with AWS S3 managed key.	Using AWS S3 managed key to encrypt an S3 bucket in AWS is not recommended due to limited control over key management. Managing your own KMS keys allows for better security practices, ensures isolation of resources, and facilitates compliance with industry standards. Creating and using customer-managed keys provides a more robust and customizable approach to data encryption in AWS S3.
Data Security	S3 Bucket Publicly Accessible	This risk points to an Amazon S3 bucket configured as publicly accessible, potentially making it reachable by any internet user. Publicly accessible S3 buckets significantly reduce the risk of unauthorized data access and potential breaches. It's recommended to validate the need for such public access, and if it's not necessary, promptly restrict access to improve your data security.	An attacker can access the bucket and objects leading to data exposure.
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf.
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0.
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

AWS Sagemaker

Category	Risk Name	Description	Attack Scenario
Insufficient Encryption	Sagemaker Endpoint Configuration without Encryption Key	Sagemaker Endpoint Configuration without Encryption Key. Encrypting your AWS SageMaker endpoint configuration with a KMS key is a crucial step in securing your machine learning application. It protects sensitive data at rest, ensuring that unauthorized users cannot access your model's configurations or the data it processes.	An attacker can access your model's configurations or the data it processes.
Public Exposure	Publicly Accessible AWS Sagemaker Domain	AWS Sagemaker domain with public access enabled.	An attacker can access the resource. Allowing unrestricted, public access to cloud services could open an application up to external attack.
Insufficient Encryption	AWS Sagemaker Domain without Customer KMS Key	AWS Sagemaker domain is not encrypted using a KMS key.	An attacker can access your EFS volume attached to the domain.
Public Exposure	Sagemaker Notebook Instance with Direct Internet Access	Sagemaker notebook instance with direct internet access, when your notebook allows direct internet access, SageMaker provides a network interface that allows the notebook to communicate with the internet through a VPC managed by SageMaker.	An attacker can access your notebook instance.
Permissive Access	Sagemaker Notebook Instance with Root Access	Sagemaker notebook instance with root access.	An attacker who gains access to the notebook instance can find a way to get root access to that instance, and then it will have full control over that instance. Using that full control, he might be able to steal important data or even continue his attack using lateral movement techniques.
Insufficient Encryption	SageMaker Notebook Instance not encrypted using a KMS Key	SageMaker notebook instance without KMS key. Encrypting your AWS SageMaker notebook with a KMS key is a vital security practice that safeguards your sensitive data, code, and intellectual property. It enforces robust access controls, ensuring that only authorized personnel can decrypt and interact with your content.	An attacker can access your sensitive data.

AWS Secrets Manager

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Secret Manager Secret Not Rotated Over 30 Days	Secret not rotated for over 30 days.	An attacker with access to the secret can get its content and elevate his privileges.

Amazon VPC

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Default Security Group
Insecure Configurations	Security Group with Inappropriately Configured CIDR IP	This risk highlights a Security Group with a misconfigured CIDR IP, which may expose your resources to unintended networks, leading to potential unauthorized access. A swift review and correction of CIDR IP configurations in your security groups is strongly recommended to uphold network security.	The Instances that are connected to this security group, can be accidentally exposed to the Internet and compromised.
Public Exposure	Security Group Allows Access From Any IP (0.0.0.0/0)	A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to any port.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group Permits Connections From Any IP (0.0.0.0/0)	This risk points to an AWS Security Group configured to allow incoming connections from any IP address, denoted by the range 0.0.0.0/0. This unrestricted access can lead to potential unauthorized access and data breaches. It's recommended to validate the need for such open access, and if it is not required, promptly implement stricter access control based on specific IP addresses or ranges.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Exposed RDP Port	This risk identifies a Security Group that has the RDP port (3389) open to the public, posing a significant security risk. Unauthorized access to the RDP port can potentially allow cyber attackers to control your AWS resources. It's crucial to review and restrict access to the RDP port, limiting it to specific, necessary IP ranges or secure VPN connections, to strengthen your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Exposed Telnet Port	This risk underscores a Security Group that has the Telnet port (23) open to the public. An open Telnet port can be a significant security vulnerability as it can allow unauthorized access to your AWS resources. This exposure could potentially lead to unauthorized data access, data breaches, or unwanted modifications. It's highly advised to review and tighten access to the Telnet port, limiting it to necessary IP ranges or more secure protocols. Swift action to restrict this access will greatly enhance your AWS security posture and reduce potential cyber attack vectors.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open Cassandra Port	This risk signifies a Security Group that has the Cassandra port (9142) open to the public. This can allow unauthorized access to your Cassandra databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group With Open Kubernetes Kubelet Port (10250)	A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to Kubernetes Kubelet port (10250).	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open MySQL/MariaDB Port	This risk points to a Security Group that has the MySQL/MariaDB port (3306) open to the public. This can allow unauthorized access to your MySQL/MariaDB databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, greatly enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open Redis Port	This risk signifies a Security Group with an open Redis port (6379), providing public access. This could potentially expose your Redis databases to unauthorized access and possible security breaches. A swift action to review and restrict access to the Redis port, limiting it to necessary IP ranges or secure VPN connections, is advised to fortify your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Kafka Port	This risk identifies a Security Group with an open Kafka port (9092), providing public access. This configuration could potentially expose your Kafka servers to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kafka port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Kibana Port	This risk signifies a Security Group with an open Kibana port (5601), providing public access. This could potentially expose your Kibana instances to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kibana port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Memcached Port	This risk highlights a Security Group configured with an open Memcached port (11211), allowing public access. This configuration can potentially expose your Memcached servers to unauthorized access and data breaches. It's recommended to promptly review and restrict access to the Memcached port, limiting it to necessary IP ranges or secure connections, thereby fortifying your server security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Redshift Port	This risk points to a security group configuration that leaves the Amazon Redshift port (5439) open to the public. An exposed Redshift port can increase the risk of unauthorized access and potential data breaches. It's recommended to verify the need for such a configuration and, if unnecessary, promptly restrict access to this port to enhance the security of your Redshift clusters.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible RPC Port	This risk highlights a Security Group configured with an open RPC port (135), making it publicly accessible. This configuration can potentially allow unauthorized access to your AWS resources. Open RPC ports are known to be vectors for certain types of cyber attacks, potentially leading to data breaches or unauthorized modifications. It's strongly recommended to review and limit access to the RPC port, confining it to necessary IP ranges or secure connections. Immediate action to secure this access will substantially enhance your AWS security and reduce potential cyber threats.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Exposed MSSQL Port	This risk signifies a Security Group configured with an open MSSQL port (1433), granting public access. This unrestricted access can potentially expose your SQL Server databases to unauthorized access and malicious activities. It's advised to immediately review and restrict the MSSQL port access to specific, necessary IP ranges or secure connections, enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Exposed Splunkd Port	This risk identifies a Security Group that has the Splunkd port (8089) open to the public. This configuration potentially leaves your Splunkd services vulnerable to unauthorized access and cyber threats. It's strongly recommended to review and limit access to the Splunkd port, confining it to specific, trusted IP ranges or secure VPN connections, to enhance your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted FTP Ports	This risk highlights a Security Group that has FTP ports (20/21) open to the public. An open FTP port can allow unauthorized access to your AWS resources, potentially leading to data breaches, misuse, or unwarranted changes. It's strongly recommended to review and tighten access to these FTP ports, limiting them to specific, necessary IP ranges or secure connections. Prompt action to restrict this access will significantly enhance your AWS security and reduce exposure to potential cyber threats.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted PostgreSQL Port	This risk highlights a Security Group with an open PostgreSQL port (5432). This configuration can expose your PostgreSQL databases to unauthorized access and potential malicious activities. Promptly reviewing and restricting access to the PostgreSQL port, confining it to necessary IP ranges or secure connections, is strongly recommended to enhance your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted SMB Port Access	This risk category identifies a Security Group that has the SMB port (445) openly accessible to the public. An open SMB port can provide an entry point for unauthorized access to your AWS resources, potentially leading to data breaches or malicious modifications. This port is often targeted for exploits like the WannaCry ransomware attack. It's strongly recommended to review and restrict access to the SMB port, confining it to specific, necessary IP ranges or secure VPN connections. Taking immediate action to limit this access will significantly enhance your AWS security posture and reduce potential attack surfaces.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted SSH Port Access	This risk identifies a Security Group that has the SSH port (22) open to the public, potentially permitting unauthorized access to your AWS resources. It's crucial to review and restrict access to the SSH port, confining it to specific, necessary IP ranges or secure VPN connections, to bolster your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured DocDB Port	This risk indicates a Security Group that has the DocDB port (27017) open to the public. This configuration potentially leaves your DocumentDB databases exposed to unauthorized access and potential malicious actions. A swift review and restriction of access to the DocDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured Elasticsearch Ports	This risk highlights a Security Group with Elasticsearch ports (9200/9300) open to the public. These open ports can potentially expose your Elasticsearch clusters to unauthorized access and possible cyber threats. Immediate review and restriction of access to these ports, limiting them to necessary IP ranges or secure connections, is strongly advised to bolster your cluster security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured OracleDB Port	This risk highlights a Security Group that has the OracleDB port (1521) open to the public. This configuration potentially leaves your Oracle databases exposed to unauthorized access and cyber attacks. A swift review and restriction of access to the OracleDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.

SNS (Simple Notification Service)

Category	Risk Name	Description	Attack Scenario
Data Security	SNS Topic Encryption is Not Enabled	The absence of encryption for SNS topics exposes transmitted messages to risks of unauthorized access, interception, and tampering, compromising the confidentiality, integrity, and privacy of sensitive information within the messages.	In an environment where an SNS topic lacks encryption, an attacker can gain unauthorized access. Through this access, an attacker can intercept messages transmitted through the unencrypted SNS topic, enabling them to extract sensitive information.
Data Security	SNS Topic is Encrypted With a Default Key	Using the default key for encrypting SNS topics presents limitations in effective key management. Default key does not allow the ability to create, rotate, disable or enable the encryption key used to protect the data.	The default key used for encryption in AWS lacks the necessary mechanisms to provide secure end-to-end encryption and prevent a Man-in-the-Middle attack on SNS topics. This makes it vulnerable to interception and manipulation by an attacker.
Insecure Configurations	SNS Topic Data-in-Transit is Not Enforced	An SNS topic without HTTPS enforcment.	Without HTTPS, a network-based attacker can eavesdrop on network traffic or manipulate it using an attack such as man-in-the-middle.
Permissive Access	SNS Topic Policy Allows 'SNS:Publish' for All Principals Without Conditions	The security finding of an SNS topic policy allowing unrestricted 'SNS:Publish' access increses the risk of unauthorized message dissemination, abuse, compromised data integrity, and non-compliance with security regulations.	An attacker identifies the SNS topic with the open publishing access and leverages this vulnerability to send unauthorized messages to the topic. With the ability to publish messages without restrictions, the attacker can disseminate malicious content, such as phishing links, malware payloads, or false information to the subscribers of the topic.
Permissive Access	SNS Topics Administrative Actions Are Publicly Executable	Preventing public execution of administrative actions on SNS topics is essential to maintain messaging system security, safeguard sensitive data, prevent service disruptions, and ensure compliance by restricting unauthorized users from performing administrative operations.	An attacker identifies a publicly accessible SNS topic and discovers that administrative actions can be executed without authentication. With this control, the attacker can modify topic settings, change access permissions, or delete the topic altogether.
Insecure Configurations	SNS Topics Are Publicly Accessible	Ensuring that SNS is not publicly accessible is important to protect against unauthorized access, data breaches, and other security threats.	An attack targeting the Simple Notification Service (SNS) public access could involve unauthorized actors exploiting the open access configuration of an SNS topic. By identifying a publicly accessible SNS topic, the attackers can abuse it to send messages or notifications to a large number of recipients, potentially causing disruptions, spamming users, or spreading malicious content.

SQS (Simple Queue Service)

Category	Risk Name	Description	Attack Scenario
Data Security	SQS Queue is Not Encrypted With a Customer-Managed Key	SQS (Simple Queue Service) not being encrypted with a customer-managed key increases the risk of unauthorized access and potential exposure of sensitive data.	When SQS is not encrypted with a customer-managed key, the messages stored in SQS are still encrypted using AWS-managed keys. Without customer-managed key encryption. KMS key allows a more granular control over the SQS data encryption/decryption process.
Data Security	SQS Server-Side Encryption is Not Enabled	Disabling AWS SQS Server-Side Encryption (SSE) exposes data to vulnerabilities, non-compliance with data protection regulations, compromises data integrity, and undermines trust in the service.	When Server-Side Encryption (SSE) is not enforced in SQS, an attacker with unauthorized access can intercept and read unencrypted messages stored in the queue, leading to data exposure.
Insecure Configurations	SQS Data-in-Transit Encryption is Not Enforced	Not enforcing data-in-transit encryption in SQS (Simple Queue Service) increases the risk of data interception and unauthorized access during the transmission of messages.	The transmitted messages are vulnerable to interception by malicious actors. Attackers can eavesdrop on network traffic or manipulate it, using an attack such as man-in-the-middle.
Permissive Access	SQS Policy Allows All Actions From All Principals Without a Condition	Allowing all actions from all principals without conditions in AWS SQS eliminates access control, increases the risk of unauthorized operations, data breaches, compliance violations, and operational disruptions.	In a scenario where there is a lack of access control in AWS SQS, allowing all actions from all principals without conditions, any AWS identity or entity has unrestricted access to perform any action on the SQS queues. This absence of granular access controls and restrictions allows an attacker to exploit this lack of control by gaining unauthorized access to sensitive data within the queues.
Insecure Configurations	SQS Policy Allows Public Access	SQS (Simple Queue Service) policy that allows public access increases the risk of unauthorized users gaining access to the queue and potentially manipulating or retrieving sensitive messages.	When an SQS (Simple Queue Service) policy is misconfigured to allow public access, unauthorized individuals can exploit this vulnerability. Attackers can manipulate and retrieve sensitive messages from the queue without any authentication or authorization checks.

Microsoft Azure - click to collapse

Microsoft Azure

Click on a service name below to view a table of the risks Panoptica detects in Azure, along with brief descriptions and attack scenarios.

Azure AI Search Service

Category	Risk Name	Description	Attack Scenario
Public Exposure	Azure AI Search with Public Network Access	Azure AI Search is publicly accessible.	An attacker might focus on azure ai search app that is publicly accessible, aiming to exploit vulnerabilities such as Denial of Service, Brute-force attacks, and others.

Azure App Service

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Azure Function Cross-origin Resource Sharing (CORS) Feature not Implemented	Cross-Origin Resource Sharing (CORS) is a security feature that allows or restricts web applications running at one origin (domain) to make requests for resources from a different origin, subject to certain constraints, to prevent unauthorized access to data. This finding signifies an Azure Function without Cross-Origin Resource Sharing enforcement.	An attacker could exploit permissive CORS policies set on a web application to make unauthorized cross-origin requests, potentially gaining access to sensitive data or performing actions on behalf of a legitimate user without their consent. For example, an attacker might trick a victim into visiting a malicious website that sends requests to a trusted web service using the victim's credentials, allowing the attacker to steal data or perform actions on the victim's behalf.
Insecure Configurations	Azure Function Enables Unencrypted Traffic	An Azure Function without HTTPS enforcment.	Without HTTPS, a network-based attacker can eavesdrop on network traffic or manipulate it using an attack such as man-in-the-middle.
Insecure Configurations	Azure Function Support Insecure Transportation Security Protocol	An Azure Function that uses insecure TLS (Transport Layer Security) protocols.	It is recommended to use the latest version of TLS if possible. Older versions (prior to TLS 1.2) may be deprecated or may contain known vulnerabilities that an attacker can use.
Insecure Configurations	FTP Service Enabled for Azure Function	An Azure Function S/FTP endpoint enabled.	The Azure FTP deployment endpoints are publicly accessible. An attacker might attempt to brute-force the service to gain access to the app/service code base.
Insecure Configurations	Remote Debugging is Enabled for Azure Function	An Azure Function that enables remote debugging.	If remote debugging in Azure Functions is enabled without proper security controls, an attacker could potentially gain unauthorized access to the running code, extract sensitive information, inject malicious code, or disrupt the application, posing a significant security risk.
Unsupported Software	Azure Function Deprecated Runtime	Azure function with a deprecated runtime.	An attacker can exploit known unpatched vulnerabilities in the azure function runtime.

Azure Application Gateway

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Application Gateway Should have Http to Https redirection	Application Gateway has an HTTP listener without a redirection to HTTPS defined. It is important to make sure all communication is encrypted by enabling HTTP-to-HTTPS redirection for all HTTP listeners.
Insecure Configurations	Application Gateway Allows Old TLS versions	Application Gateway is allowing the usage of old TLS versions, such as Version 1.0 and Version 1.1	An attacker can communicate with the application gateway using old and vulnerable versions of TLS such as TLS 1 and TLS1.1 which are vulnerable to downgrade attacks becuase they rely on SHA-1 hash for the integrity of exchanged messages.

Azure Cache for Redis

Category	Risk Name	Description	Attack Scenario
Public Exposure	Azure Cache for Redis is Publicly Accessible	Azure Cache for Redis is publicly accessible to all IP's.	An attacker can expose the database to anyone on the Internet, significantly increasing the risk of malicious access, data breaches, or potential service disruptions.

Azure Container App

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Azure Container App Allow Inbound Traffic From Any IP	Azure Container App allows inbound traffic from any IP address.	An attack could easily access a container app without any restrictions.
Public Exposure	Azure Container App with Public Network Access	Azure Container App is publicly accessible.	An attacker might focus on a container app that is publicly accessible, aiming to exploit vulnerabilities like Denial of Service, Brute-force attacks, and others.
Insecure Configurations	Azure Container App Permissive Cross-origin Resource Sharing (CORS) Policy	Azure Container App is set to allow any (wildcard) origins.	An attacker could exploit permissive CORS policies set on a web application to make unauthorized cross-origin requests, potentially gaining access to sensitive data or performing actions on behalf of a legitimate user without their consent. For example, an attacker might trick a victim into visiting a malicious website that sends requests to a trusted web service using the victim's credentials, allowing the attacker to steal data or perform actions on the victim's behalf.
Insecure Configurations	Azure Container App Allows Unencrypted HTTP Traffic	Azure Container App without HTTPS enforcement.	Without HTTPS, a network-based attacker can eavesdrop on network traffic or manipulate it using an attack such as man-in-the-middle.

Azure Container Instance (ACI)

Category	Risk Name	Description	Attack Scenario
Public Exposure	Public Storage Account Container	Container with public access allowed.	In some cases, an attacker will be able to access data stored in the container.
Insecure Configurations	Azure Container Instance Allows 'Any' DNS Scope Reuse	Azure Container Instance enables the reuse of 'Any' DNS scope, which can potentially lead to malicious subdomain takeover.	An attacker can abuse this configuration to steal the subdomain.
Public Exposure	Azure Container Instance with Public Network Access	Azure Container Instance is publicly available	An attacker might focus on a container instance that is publicly accessible, aiming to exploit vulnerabilities like Denial of Service, Brute-force attacks, and others.
Insufficient Encryption	Azure Container Instance Encrypted with Microsoft Managed Key	Azure Container Instance disk encrypted with Microsoft Managed Key.	An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure Container Instance data.

Azure Cosmos DB

Category	Risk Name	Description	Attack Scenario
Data Security	Cosmos DB Connection From Public Azure Data Centers Enabled	This option configures the firewall to allow all requests from Azure, including requests from the subscriptions of other customers deployed in Azure.	In a scenario where a Cosmos DB account allows connections from IP address "0.0.0.0" (representing all public data centers), an attacker with an unauthorized account could exploit this configuration by gaining access from any location. This attacker could potentially infiltrate the Cosmos DB account, extract sensitive data, launch malicious queries, or even manipulate the database's content, all while leveraging the unrestricted public IP allowance.
Insecure Configurations	Cosmos DB Account "Disabled Key Based Metadata Write Access" is Disabled	A CosmosDB Database with "Disabled Key Based Metadata Write Access" option disabled.	In a scenario where "disabled key based metadata write access" is disabled, an attacker could potentially exploit this vulnerability by gaining unauthorized access to modify or tamper with metadata using compromised keys. This could lead to unauthorized privilege escalation, data manipulation, or confusion in data organization, impacting the integrity and security of the Cosmos DB resources.
Insecure Configurations	Cosmos DB Account is Not Using Virtual Network	Enabling Virtual Network integration for a Cosmos DB account is important as it adds an additional layer of security by restricting data access to specific networks, reducing exposure to potential threats.	In an attack scenario, if Virtual Network integration is not enabled for a Cosmos DB account, a malicious actor could exploit the lack of network restrictions by infiltrating the account through public endpoints, potentially compromising sensitive data or executing unauthorized operations on the database.
Inadequate Authentication & Authorization	Cosmos DB Account Local Auth is Enabled	Cosmos DB account local auth is enabled.	An attacker with access to these static keys, could potentially perform malicious actions such as data extraction, modification, or deletion. Since the keys are long-lived and not subject to regular rotation, the compromise could persist for an extended period, leading to significant data breaches and security breaches.
Insecure Configurations	Cosmos DB Account with Service Managed Encryption Key	Customer-Managed Keys (CMK) provide crucial advantage of retaining full control and ownership over their encryption keys, allowing them to enforce stricter access policies and meet regulatory compliance requirements.	An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access sensitive data stored in Cosmos DB.
Public Exposure	Cosmos DB Account Access is Allowed From All Networks	Azure Cosmos DB with public access enabled.	An attacker could exploit this misconfiguration by remotely connecting to the publicly open database and exfiltrating sensitive data.
Public Exposure	Cosmos DB Account is Not Using Private Endpoints	A CosmosDB database without private endpoints.	Not enabling Virtual Network integration for a Cosmos DB account can result in reduced security, potentially exposing data to unauthorized access.

Azure Database for MariaDB

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	MariaDB Server is Not Using Virtual Networks	Not using virtual networks in a MariaDB account poses a security risk as it exposes the database to potential unauthorized access and data exposure, lacking the additional layer of network isolation and security controls provided by virtual networks.	In a scenario where a virtual network is not configured, the communication occurs over the public internet unless there are other network-level controls in place. If the communication is not encrypted, it becomes susceptible to interception by attackers. These attackers can then execute a Man-in-the-Middle attack to intercept the traffic between the two entities.
Insecure Configurations	MariaDB Server TLS /SSL Disabled	MariaDB with disabled TLS/SSL option.	If TLS/SSL is disabled for a MariaDB account, an attacker on the same network could intercept the unencrypted database traffic, potentially capturing sensitive data such as passwords and queries.
Public Exposure	MariaDB Server Connection From Public Azure Services	Having a firewall rule allowing access from Azure Public Services in MariaDB could pose a security as it might permit access from a broader range of Azure services than necessary, potentially exposing the database to unintended and unnecessary connections within the Azure network.	An attacker exploits a misconfigured MariaDB firewall rule allowing access from any Azure Public Service, potentially gaining unauthorized entry through unintended services. Once inside, the attacker could perform malicious operations on the database, jeopardizing data integrity and confidentiality.
Public Exposure	MariaDB Server Has Full Public Network Access	Having Full public network access for all in a MariaDB account poses a security risk by potentially exposing the database to unauthorized access from any address.	An attacker, aware of the public network access on a MariaDB account for all, could exploit this vulnerability by launching attacks, attempting unauthorized logins, and potentially gaining control over the database, leading to unauthorized data access.
Public Exposure	MariaDB Server is Not Using Private Endpoints	MariaDB without a private endpoint configured.	An attacker could exploit network vulnerabilities to intercept unencrypted database communication, potentially capturing sensitive data or injecting malicious commands.

Azure Databricks Workspace

Category	Risk Name	Description	Attack Scenario
Insufficient Encryption	Azure Databricks Managed Service Encrypt with Microsoft Managed Key	Azure databricks managed services encrypted at rest using server-side encryption with Microsoft-managed key.	An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure Databricks data.
Insufficient Encryption	Azure Databricks Double Encryption for DBFS Root Should be Enabled	Azure Databricks double encryption for DBFS root disabled. Enabling double encryptionprovides an additional layer of security for your data at rest.	When double encryption is not enabled for DBFS root in Azure Databricks, an attacker can get your data because its protected by the default single layer of encryption, which does carry certain risks. Single-layer encryption can leave data potentially vulnerable if the encryption algorithm is compromised or if the encryption key is exposed through a security breach.
Public Exposure	Azure Databricks with Public Network Access	Azure Databricks workspace with 'public network access' enable.	An attacker can access to the exposed resource.
Public Exposure	Azure Databricks Should has a Secure Cluster Connectivity Enabled (No Public IP)	Azure Databricks secure cluster connectivity (No Public IP) disabled. When you enable 'No public IP' your clusters are not directly accessible from the internet, it is reducing the attack surface for potential threats.	When you are not enable 'Secure Cluster Connectivity'public IP addresses are assigned to Azure Databricks clusters, an attacker can exploit it todata theft, extracting sensitive or proprietary information from the datasets processed by the cluster.
Insecure Configurations	Azure Databricks is not in a Virtual Network	Using a Virtual Network (VNet) in Azure Databricks is essential for security and network control. It provides an isolated environment where data processing and analytics can occur away from the public internet, significantly reducing exposure to external threats. VNets allow for the implementation of precise access controls and network traffic filtering using network security groups (NSGs), ensuring that only authorized users and services can interact with the Databricks workspace.	In a scenario where a virtual network is not configured, the communication occurs over the public internet unless there are other network-level controls in place. If the communication is not encrypted, it becomes susceptible to interception by attackers. These attackers can then execute a Man-in-the-Middle attack to intercept the traffic between the two entities.
Insufficient Encryption	Azure Databricks Managed Disk Encrypt with Microsoft Managed Key	Azure databricks managed disk encrypted at rest using server-side encryption with Microsoft-managed key.	An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure Databricks data.
Public Exposure	Azure Databricks without Private Endpoint	'Private endpoint connection' is empty, this feature enables you to connect your Databricks workspace securely to Azure services or your on-premises network through a private IP address within your own virtual network (VNet). This private connection is facilitated by Azure Private Link, which ensures that data traffic between your Databricks workspace and other services traverses only through the Microsoft Azure network, avoiding exposure to the public internet.	An attackers can exploit exposed public endpoints to gain unauthorized access, potentially leading to denial of service attacks and compromising the workspace.

Azure Entra ID

Category	Risk Name	Description	Attack Scenario
Permissive Access	Principal with Role Access Review Operator Service Permission on Management Group	A Principal with permissions to discover and revoke access as needed on management group scope.	An attacker could delete role assignments for all principals at management group scope.
Permissive Access	Principal with high permissions in service ManagedIdentity on Management Group	A Principal with actions:* under Microsoft.ManagedIdentity.	A Principal with permissions to do all actions (*) under Microsoft.ManagedIdentity on management group scope
Permissive Access	Principal with high permissions in service Network on Subscription	A Principal with actions:* under Microsoft.Network.	A Principal with permissions to do all actions (*) under Microsoft.Network on subscription scope.
Permissive Access	Principal with high permissions in service ServiceFabric on Subscription	A Principal with actions:* under Microsoft.ServiceFabric.	A Principal with permissions to do all actions (*) under Microsoft.ServiceFabric on subscription scope.
Permissive Access	Principal with high permissions in service DataShare on Subscription	A Principal with actions:* under Microsoft.DataShare.	A Principal with permissions to do all actions (*) under Microsoft.DataShare on subscription scope.
Permissive Access	Principal with high permissions in service DocumentDB on Management Group	A Principal with actions:* under Microsoft.DocumentDB.	A Principal with permissions to do all actions (*) under Microsoft.DocumentDB on management group scope.
Permissive Access	Principal with Permission to Write Role Definition on Management Group	A Principal with permissions to create or edit custom roles on management group scope (Microsoft.Authorization/ roleDefinitions/write).	An attacker can edit a custom role assigned to themselves to gain a high-privilege role like owner, thus elevating permissions on the control and data plane at the management group scope.
Permissive Access	Principal with User Access Administrator Permission on Management Group	A principal with permissions to manage user access to Azure resources on management group scope.	An attacker can create a custom role, assign it to themselves, and elevate permissions on the control and data plane at management group scope.
Permissive Access	Principal with high permissions in service Batch on Management Group	A Principal with actions: and/or data actions: under Microsoft.Batch.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Batch on management group scope.
Permissive Access	Principal with Role Based Access Control Administrator Permission on Management Group	A Principal with permissions to manage access to Azure resources by assigning roles using Azure RBAC on management group scope.	An attacker can create a custom role, assign it to themselves, and elevate permissions on the control and data plane at management group scope.
Permissive Access	Principal with high permissions in service Kubernetes on Management Group	A Principal with actions: and/or data actions: under Microsoft.Kubernetes.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Kubernetes on management group scope.
Permissive Access	Principal with high permissions in service KeyVault on Subscription	A Principal with actions: and/or data actions: under Microsoft.KeyVault.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.KeyVault on subscription scope.
Permissive Access	Principal with Owner Permissions on Subscription	A Principal with permissions to perform all actions on subscription scope (such as write, read, delete).	An attacker can perform any action on any resource on subscription scope
Permissive Access	Principal with high permissions in service DataLakeAnalytics on Subscription	A Principal with actions:* under Microsoft.DataLakeAnalytics.	A Principal with permissions to do all actions (*) under Microsoft.DataLakeAnalytics on subscription scope.
Permissive Access	Principal with high permissions in service Authorization on Subscription	A Principal with actions:* under Microsoft.Authorization.	A Principal with permissions to do all actions (*) under Microsoft.Authorization on subscription scope.
Permissive Access	Principal with high permissions in service Storage on Management Group	A Principal with actions: and/or data actions: under Microsoft.Storage.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Storage on management group scope.
Permissive Access	Principal with high permissions in service Automation on Management Group	A Principal with actions:* under Microsoft.Automation.	A Principal with permissions to do all actions (*) under Microsoft.Automation on management group scope.
Permissive Access	Principal with Write Permission on Management Group	A Principal with permissions to perform all write actions on management group scope (*/write - all actions that end with write).	An attacker can perform any write action on any resource on management group scope
Permissive Access	Principal with high permissions in service Synapse on Subscription	A Principal with actions:* under Microsoft.Synapse.	A Principal with permissions to do all actions (*) under Microsoft.Synapse on subscription scope.
Permissive Access	Principal with high permissions in service DataLakeStore on Subscription	A Principal with actions:* under Microsoft.DataLakeStore.	A Principal with permissions to do all actions (*) under Microsoft.DataLakeStore on subscription scope.
Permissive Access	Principal with Read Permission on Management Group	A Principal with permissions to perform all read actions on management group scope (*/read - all actions that end with read).	An attacker can perform any read action on any resource on management group scope.
Permissive Access	Principal with high permissions in service DBforMYSQL on Management Group	A Principal with actions:* under Microsoft.DBforMYSQL.	A Principal with permissions to do all actions (*) under Microsoft.DBforMYSQL on management group scope.
Permissive Access	Principal with Delete Permission on Management Group	A Principal with permissions to perform all delete actions on management group scope (*/delete - all actions that end with delete).	An attacker can perform any delete action on any resource on management group scope
Permissive Access	Principal with Permission to Write Role Assignments on Subscription	A Principal with permissions to create or edit role assignments on subscription scope (Microsoft.Authorization/ roleAssignments/write).	An attacker can assign themselves a high-privilege role like owner, thereby elevating permissions on the control and data plane at the subscription scope.
Permissive Access	Principal with high permissions in service Kubernetes on Subscription	A Principal with actions: and/or data actions: under Microsoft.Kubernetes.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Kubernetes on subscription scope.
Permissive Access	Principal with high permissions in service Kusto on Subscription	A Principal with actions:* under Microsoft.Kusto.	A Principal with permissions to do all actions (*) under Microsoft.Kusto on subscription scope.
Permissive Access	Principal with high permissions in service DBforMYSQL on Subscription	A Principal with actions:* under Microsoft.DBforMYSQL.	A Principal with permissions to do all actions (*) under Microsoft.DBforMYSQL on subscription scope.
Permissive Access	Principal with high permissions in service DBforPostgreSQLe on Management Group	A Principal with actions:* under Microsoft.DBforPostgreSQL.	A Principal with permissions to do all actions (*) under Microsoft.DBforPostgreSQL on management group scope.
Permissive Access	Principal with high permissions in service ContainerService on Subscription	A Principal with actions: and/or data actions: under Microsoft.ContainerService.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.ContainerService on subscription scope.
Permissive Access	Principal with high permissions in service DataLakeAnalytics on Management Group	A Principal with actions:* under Microsoft.DataLakeAnalytics.	A Principal with permissions to do all actions (*) under Microsoft.DataLakeAnalytics on management group scope.
Permissive Access	Principal with Read Permission on Subscription	A Principal with permissions to perform all read actions on subscription scope (*/read - all actions that end with read).	An attacker can perform any read action on any resource on subscription scope
Permissive Access	Principal with high permissions in service Communication on Subscription	A Principal with actions:* under Microsoft.Communication.	A Principal with permissions to do all actions (*) under Microsoft.Communication on subscription scope.
Permissive Access	Principal with high permissions in service Cache on Subscription	A Principal with actions:* under Microsoft.Cache.	A Principal with permissions to do all actions (*) under Microsoft.Cache on subscription scope.
Permissive Access	Principal with Permission to Write Role Definition on Subscription	A Principal with permissions to create or edit custom roles on subscription scope (Microsoft.Authorization/ roleDefinitions/write).	An attacker can edit a custom role assigned to themselves to gain a high-privilege role like owner, thus elevating permissions on the control and data plane at the subscription scope.
Permissive Access	Principal with high permissions in service app on Management Group	A Principal with actions: and/or data actions: under Microsoft.app.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.app on management group scope.
Permissive Access	Principal with high permissions in service SignalRService on Management Group	A Principal with actions: and/or data actions: under Microsoft.SignalRService.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.SignalRService on management group scope.
Permissive Access	Principal with high permissions in service Communication on Management Group	A Principal with actions:* under Microsoft.Communication.	A Principal with permissions to do all actions (*) under Microsoft.Communication on management group scope.
Permissive Access	Principal with high permissions in service web on Management Group	A Principal with actions:* under Microsoft.web.	A Principal with permissions to do all actions (*) under Microsoft.web on management group scope.
Permissive Access	Principal with high permissions in service ApiManagement on Management Group	A Principal with actions:* under Microsoft.ApiManagement.	A Principal with permissions to do all actions (*) under Microsoft.ApiManagement on management group scope.
Permissive Access	Principal with high permissions in service DataLakeStore on Management Group	A Principal with actions:* under Microsoft.DataLakeStore.	A Principal with permissions to do all actions (*) under Microsoft.DataLakeStore on management group scope.
Permissive Access	Principal with high permissions in service VisualStudio on Subscription	A Principal with actions:* under Microsoft.VisualStudio.	A Principal with permissions to do all actions (*) under Microsoft.VisualStudio on subscription scope.
Permissive Access	Principal with Administrator Data Plane Permissions on Management Group	A Principal with permissions to perform all data actions on management group scope (such as- write, read, delete).	An attacker can perform any data action on any resource on management group scope.
Permissive Access	Principal with high permissions in service ManagedIdentity on Subscription	A Principal with actions:* under Microsoft.ManagedIdentity.	A Principal with permissions to do all actions (*) under Microsoft.ManagedIdentity on subscription scope.
Permissive Access	Principal with Full Administrator Permissions on Subscription	A Principal with permissions to perform all actions and all data actions on subscription scope(all actions and all data actions- such as write, read, delete).	An attacker can perform any action and data action on any resource on subscription scope
Permissive Access	Principal with high permissions in service Network on Management Group	A Principal with actions:* under Microsoft.Network.	A Principal with permissions to do all actions (*) under Microsoft.Network on management group scope.
Permissive Access	Principal with high permissions in service Synapse on Management Group	A Principal with actions:* under Microsoft.Synapse.	A Principal with permissions to do all actions (*) under Microsoft.Synapse on management group scope.
Permissive Access	Principal with Administrator Data Plane Permissions on Subscription	A Principal with permissions to perform all data actions on subscription scope (such as- write, read, delete).	An attacker can perform any data action on any resource on subscription scope.
Permissive Access	Principal with high permissions in service Automation on Subscription	A Principal with actions:* under Microsoft.Automation.	A Principal with permissions to do all actions (*) under Microsoft.Automation on subscription scope.
Permissive Access	Principal with high permissions in service Sql on Subscription	A Principal with actions:* under Microsoft.Sql.	A Principal with permissions to do all actions (*) under Microsoft.Sql on subscription scope.
Permissive Access	Principal with high permissions in service web on Subscription	A Principal with actions:* under Microsoft.web.	A Principal with permissions to do all actions (*) under Microsoft.web on subscription scope.
Permissive Access	Principal with high permissions in service DataShare on Management Group	A Principal with actions:* under Microsoft.DataShare.	A Principal with permissions to do all actions (*) under Microsoft.DataShare on management group scope.
Permissive Access	Principal with high permissions in service CognitiveServices on Management Group	A Principal with actions: and/or data actions: under Microsoft.CognitiveServices.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.CognitiveServices on management group scope.
Permissive Access	Principal with high permissions in service CognitiveServices on Subscription	A Principal with actions: and/or data actions: under Microsoft.CognitiveServices.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.CognitiveServices on subscription scope.
Permissive Access	Principal with high permissions in service Search on Subscription	A Principal with actions:* under Microsoft.Search.	A Principal with permissions to do all actions (*) under Microsoft.Search on subscription scope.
Permissive Access	Principal with Owner Permissions on Management Group	A Principal with permissions to perform all actions on management group scope (such as write, read, delete).	An attacker can perform any action on any resource on management group scope
Permissive Access	Principal with Role Based Access Control Administrator Permission on Subscription	A Principal with permissions to manage access to Azure resources by assigning roles using Azure RBAC on subscription scope.	An attacker can create a custom role, assign it to themselves, and elevate permissions on the control and data plane at subscription scope.
Permissive Access	Principal with high permissions in service Batch on Subscription	A Principal with actions: and/or data actions: under Microsoft.Batch.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Batch on subscription scope.
Permissive Access	Principal with high permissions in service Kusto on Management Group	A Principal with actions:* under Microsoft.Kusto.	A Principal with permissions to do all actions (*) under Microsoft.Kusto on management group scope.
Permissive Access	Principal with high permissions in service Compute on Management Group	A Principal with actions: and/or data actions: under Microsoft.Compute.	A Principal with permissions to do all actions (*) under Microsoft.Compute on management group scope.
Permissive Access	Principal with high permissions in service Search on Management Group	A Principal with actions:* under Microsoft.Search.	A Principal with permissions to do all actions (*) under Microsoft.Search on management group scope.
Permissive Access	Principal with high permissions in service DomainRegistration on Management Group	A Principal with actions:* under Microsoft.DomainRegistration.	A Principal with permissions to do all actions (*) under Microsoft.DomainRegistration on management group scope.
Permissive Access	Principal with Full Administrator Permissions on Management Group	A Principal with permissions to perform all actions and all data actions on a management group scope(all actions and all data actions- such as write, read, delete).	An attacker can perform any action and data action on any resource on management group scope
Permissive Access	Principal with high permissions in service Cache on Management Group	A Principal with actions:* under Microsoft.Cache.	A Principal with permissions to do all actions (*) under Microsoft.Cache on management group scope.
Permissive Access	Principal with high permissions in service DataBricks on Subscription	A Principal with actions:* under Microsoft.Databricks.	A Principal with permissions to do all actions (*) under Microsoft.Databricks on subscription scope.
Permissive Access	Principal with high permissions in service Sql on Management Group	A Principal with actions:* under Microsoft.Sql.	A Principal with permissions to do all actions (*) under Microsoft.Sql on management group scope.
Permissive Access	Principal with high permissions in service ApiManagement on Subscription	A Principal with actions:* under Microsoft.ApiManagement.	A Principal with permissions to do all actions (*) under Microsoft.ApiManagement on subscription scope.
Permissive Access	Principal with high permissions in service SignalRService on Subscription	A Principal with actions: and/or data actions: under Microsoft.SignalRService.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.SignalRService on subscription scope.
Permissive Access	Principal with high permissions in service NetApp on Subscription	A Principal with actions:* under Microsoft.NetApp.	A Principal with permissions to do all actions (*) under Microsoft.NetApp on subscription scope.
Permissive Access	Principal with Contributor Permission on Subscription	A Principal with permissions to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries on subscription scope.	An attacker with the contributor role could potentially upload malicious data to resources or download sensitive information, such as secrets, directly from existing resources within the Azure environment.
Permissive Access	Principal with high permissions in service ContainerService on Management Group	A Principal with actions: and/or data actions: under Microsoft.ContainerService.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.ContainerService on management group scope.
Permissive Access	Principal with Permission to Write Role Assignments on Management Group	A Principal with permissions to create or edit role assignments on management group scope (Microsoft.Authorization/ roleAssignments/write).	An attacker can assign themselves a high-privilege role like owner, thereby elevating permissions on the control and data plane at the management group scope.
Permissive Access	Principal with Role Access Review Operator Service Administrator Permission on Subscription	A Principal with permissions to discover and revoke access as needed on subscription scope.	An attacker could delete role assignments for all principals at subscription scope.
Permissive Access	Principal with User Access Administrator Permission on Subscription	A Principal with permissions to manage user access to Azure resources on subscription scope.	An attacker can create a custom role, assign it to themselves, and elevate permissions on the control and data plane at subscription scope.
Permissive Access	Principal with high permissions in service app on Subscription	A Principal with actions: and/or data actions: under Microsoft.app.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.app on subscription scope.
Permissive Access	Principal with high permissions in service VisualStudio on Management Group	A Principal with actions:* under Microsoft.VisualStudio.	A Principal with permissions to do all actions (*) under Microsoft.VisualStudio on management group scope
Permissive Access	Principal with high permissions in service DataBricks on Management Group	A Principal with actions:* under Microsoft.Databricks.	A Principal with permissions to do all actions under Microsoft.Databricks on management group scope.
Permissive Access	Principal with high permissions in service DomainRegistration on Subscription	A Principal with actions:* under Microsoft.DomainRegistration.	A Principal with permissions to do all actions (*) under Microsoft.DomainRegistration on subscription scope.
Permissive Access	Principal with high permissions in service KeyVault on Management Group	A Principal with actions: and/or data actions: under Microsoft.KeyVault.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.KeyVault on management group scope.
Permissive Access	Principal with high permissions in service Authorization on Management Group	A Principal with actions:* under Microsoft.Authorization.	A Principal with permissions to do all actions (*) under Microsoft.Authorization on management group scope.
Permissive Access	Principal with Delete Permission on Subscription	A Principal with permissions to perform all delete actions on subscription scope (*/delete - all actions that end with delete).	An attacker can perform any delete action on any resource on subscription scope
Permissive Access	Principal with high permissions in service Compute on Subscription	A Principal with actions: and/or data actions: under Microsoft.Compute.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Compute on subscription scope.
Permissive Access	Principal with high permissions in service Storage on Subscription	A Principal with actions: and/or data actions: under Microsoft.Storage.	A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Storage on subscription scope.
Permissive Access	Principal with high permissions in service NetApp on Management Group	A Principal with actions:* under Microsoft.NetApp.	A Principal with permissions to do all actions (*) under Microsoft.NetApp on management group scope.
Permissive Access	Principal with high permissions in service DBforPostgreSQL on Subscription	A Principal with actions:* under Microsoft.DBforPostgreSQL.	A Principal with permissions to do all actions (*) under Microsoft.DBforPostgreSQL on subscription scope.
Permissive Access	Principal with Write Permission on Subscription	A Principal with permissions to perform all write actions on subscription scope (*/write - all actions that end with write).	An attacker can perform any write action on any resource on subscription scope.
Permissive Access	Principal with high permissions in service DocumentDB on Subscription	A Principal with actions:* under Microsoft.DocumentDB.	A Principal with permissions to do all actions (*) under Microsoft.DocumentDB on subscription scope.
Permissive Access	Principal with Contributor Permission on Management Group	A Principal with permissions to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries on management group scope.	An attacker with the contributor role could potentially upload malicious data to resources or download sensitive information, such as secrets, directly from existing resources within the Azure environment.
Permissive Access	Principal with high permissions in service ServiceFabric on Management Group	A Principal with actions:* under Microsoft.ServiceFabric.	A Principal with permissions to do all actions (*) under Microsoft.ServiceFabric on management group scope.

Azure Function

Category	Risk Name	Description	Attack Scenario
Public Exposure	Public Unauthenticated Function	A function with HTTP trigger and anonymous auth level. The HTTP trigger lets you invoke a function with an HTTP request, and the anonymous auth level lets you present a request without an API key. OWASP A2:2017 Broken Authentication.	An attacker can invoke the function, and in some cases can escape the function, gain the function app permissions and compromise your environment.

Azure MySQL Flex

Category	Risk Name	Description	Attack Scenario
Public Exposure	Azure DB For MySQL is Publicly Accessible	Azure Database for MySQL haspublic network access setting enabled and a firewall rule that allow access from all IPs.	Anyone on the web can access the DB. Access is usually done using a key, but if the key gets compromised, it could lead to a lot of issues as anyone can reach that DB. It is best to use a virtual network to limit access to only those who need it.
Public Exposure	Azure DB For MySQL is Publicly Accessible from Any Azure Service	Azure Database for MySQL haspublic network access setting enabled and a firewall rule that allow access from any azure service, even services of different azure subscription.	An attacker can create an azure account and azure subscription and any service he will deploy will have access to that DB.

Azure OpenAI

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Azure OpenAI with Microsoft Managed Keys	Customer-Managed Keys (CMK) provide crucial advantage of retaining full control and ownership over your encryption keys, allowing you to enforce stricter access policies and meet regulatory compliance requirements.	An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure OpenAI data at rest such as the training data and fine-tuned models.
Public Exposure	Azure OpenAI Allow Access from All Networks	Azure OpenAI with public access enabled.	"Allowing unrestricted, public access to cloud services could open an application up to external attack. An Attacker can access the resource and access the models using api calls, by exploiting a different vulnerability of the service/models he can gain access to the service/models configurations and maybe even gain access to sensitive information."

Azure Resource Management (ARM)

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Role Definition With List Storage Account Keys Permissions	A role definition with permissions to list storage account keys.	An attacker with access to the role can accsses storage accounts with "allowSharedKeyAccess" set to true.
Identity & Access Management	Principal With Owner Role	Principal is assigned with the 'Owner' rolw that gives full permissions in the subscription.	An attacker with access to the principal can compromise the subscription.
Identity & Access Management	Principal With User Access Administrator Role	Principal assigned with the 'User Access Administrator' role that enables to manage user access to Azure resources.	An attacker with access to the principal can compromise the subscription.
Insufficient Encryption	Storage Account Table CMK Encryption Disabled	Unable to encryptStorage Account Tableswith Customer-managed key.	By default, Azure Storage accounts is encrypted using service-managed keys, using of CMK in Azure Storage gives customers the flexibility to manage and rotate their encryption keys according to their security and compliance requirements, and prevent from attacker to gain access to a sensitive data.
Insufficient Encryption	Azure Storage Account with Microsoft Managed Key	Customer-Managed Keys (CMK) provide crucial advantage of retaining full control and ownership over your encryption keys, allowing you to enforce stricter access policies and meet regulatory compliance requirements.	An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your data.
Insufficient Encryption	Storage Account Queue CMK Encryption Disabled	Unable to encryptStorage Account queues with Customer-managed key.	By default, Azure Storage accounts is encrypted using service-managed keys, using of CMK in Azure Storage gives customers the flexibility to manage and rotate their encryption keys according to their security and compliance requirements, and prevent from attacker to gain access to a sensitive data.

Azure Storage Account

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Storage Account With 'non-secure' Connection	Storage account that allows requests from a non-secure connection.	An attacker can have access to your data through unencrypted communications with the storage account.
Insecure Configurations	Storage Account With Shared Key Access	Storage account with shared key access allowed. It is not a best practice to use shared key authorization for a storage account.	An attacker with access to a storage account key can access your storage account and compromise your data.
Public Exposure	Storage Account With Blob Public Access Allowed	A storage account with blob public access allowed. This setting allows public access to be configured for containers in the account but does not enable public access to your data.	In some cases, an attacker will be able to access your blobs and compromise your data.
Public Exposure	Storage Account With Unrestricted Network Access	Network access to the storage account is not restricted.	In some cases, an attacker would be able to access your storage account and the data stored in it.

Azure Virtual Machine

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	VM is not using managed disks	VM is not using managed disk, unmanaged disk is deprecated and can't be created any more but can still exist until the end of 2025. Managed disk are more secure by default and more resilient
Insecure Configurations	VM Secure Boot is Disabled	VM secure boot is disabled, it is best to enable secure boot as part of the trusted launch feature for best protection against boot level malwares	An attacker might be able to load undetectable rootkit or malicious code to the bootloader to run as part of the boot process of the machine.
Insecure Configurations	VM is not part of zone or availability-set	Azure VM is not part of any availability zone or set, availability zones and sets protects the VM from failures and creates better resiliency, connectivity and availability	An attacker can have easier time causing DoS if availability zones and availability sets are not in used.
Inadequate Logging & Backup	VM Boot Diagnostics is Disabled	VM boot diagnostics is disabled, This can help with understanding and following the events that happened incase of a secure incidents or when VM is compromised	N/A
Insecure Configurations	Linux VMs Should not Use Passwords	Linux VM is allowing authentication using passwords. Keys alone should be used as passwords are more vulnerable, brute force for example	A weak password can be compromised by an attacker which can then can use that password to SSH to the machine.
Insecure Configurations	VM vTPM is Disabled	VM vTPM is disabled, vTPM validates your VM pre-boot and boot integrity. It generates and securely stores encryption keys.	If vTPM is disabled, an attacker might be able to compromise the boot process of the VM.

Azure Virtual Network

Category	Risk Name	Description	Attack Scenario
Public Exposure	Network Security Group With Open RDP Port (3389)	A network security group with RDP port (3389) open to any IP.	An attacker can try to exploit RDP vulnerabilities leaving your environment at risk.

Azure VM Scale Set

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	VMSS is not using managed disks	Virtual machine scale-set (VMSS) is not using managed disk, unmanaged disk is deprecated and can't be created any more but can still exist until the end of 2025. Managed disk are more secure by default and more resilient. VMSS should be utilizing managed disks provided by azure.

Microsoft Entra ID Autorization Policy

Category	Risk Name	Description	Attack Scenario
Inadequate Authentication & Authorization	Entra ID Conditional Access Mfa for All Users is not Configured Properly	The conditional access policy that enforces multifactor authentication for all users is not configured propely.	An attacker can exploit the lack of enforecement of this condtional access policy and perform an identity related attack such as password spray, replay, and phishing.
Inadequate Authentication & Authorization	Entra ID Tenant doesn't Enable Conditional Policy for MFA for All users	The conditional access policy that enforces multifactor authentication for all users is not enabled.	An attacker can exploit the lack of enforecement of this condtional access polic and perform an identity related attack such as password spray, replay, and phishing.
Inadequate Authentication & Authorization	Entra ID Tenant without security defaults	An Entra Id tenant that doesn't enable security defaults. Security Defaults is a free option available with Entra ID which includes several security settings such as requriring all users to register for mfa.	An attacker can exploit the lack of security defaults and perform an identity related attack such as password spray, replay, and phishing.

Google Cloud Platform (GCP) - click to collapse

Google Cloud Platform (GCP)

Click on a service name below to view a table of the risks Panoptica detects in GCP, along with brief descriptions and attack scenarios.

App Engine

Category	Risk Name	Description	Attack Scenario
Permissive Access	App Engine Service With Default Service Account	By default App Engine service run with App Engine default service account, this service account has 'Editor' role in the project.	Attacker with access to App Engine service with default service account can deploy changes to the Cloud project can also run code with read/write access to all resources within that project.
Insecure Configurations	App Engine Service with Insecure Ingress Settings	This risk identifies a Google Cloud App Engine service configured with insecure ingress settings, potentially allowing unauthorized access. Insecure ingress settings can significantly heighten the risk of unauthorized access and potential data breaches. It's recommended to review these settings, and if the open access isn't necessary, promptly refine the ingress rules to enhance the security of your App Engine service.	An attacker can send direct requets to the app from the internet.
Public Exposure	App Engine App With Public Ingress Rule	App Engine app with public ingress rule.	An attacker might use this misconfiguration to access the application running in App Engine.
Unsupported Software	App Engine Service With Legacy Runtime	App Engine service running on legacy runtime.	Legacy runtimes support language versions that are no longer> maintained by open source communities. As communities stop maintaining versions, the app may be exposed to vulnerabilities for which no publicly available fix exists.

BigQuery

Category	Risk Name	Description	Attack Scenario
Permissive Access	BigQuery Dataset With Cross Project Access	A BigQuery dataset with a policy binding of a service account from a different project.	An attacker with access to the project that has access to the dataset can compromise your data.
Permissive Access	BigQuery Table/View With Cross Project Access	A BigQuery table or view with a policy binding of a service account from a different project.	An attacker with access to the outside service account can access this table or view and compromise your data.
Insecure Configurations	BigQuery Dataset Without Customer Managed Encryption Key (CMEK)	A BigQuery dataset without a customer-managed encryption key (CMEK).	CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest.
Insecure Configurations	BigQuery Table/View Without Customer Managed Encryption Key (CMEK)	A BigQuery Table or View without a customer-managed encryption key (CMEK).	CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest.
Public Exposure	Public BigQuery Dataset	A publicly accessible BigQuery dataset.	An attacker can access this dataset and compromise your data.
Public Exposure	Public BigQuery Table/View	A publicly accessible BigQuery table or view.	An attacker can access this table or view and compromise your data.

Bigtable

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Bigtable Instance Allows Access Of Service Account From Another Project	Bigtable instance with a policy binding of a service account from a different project.	An attacker with access from different project can compromise the environment.
Identity & Access Management	Bigtable Table Allows Access Of Service Account From Another Project	Bigtable table with a policy binding of a service account from a different project.	An attacker with access from different project can compromise the environment.
Insecure Configurations	Bigtable Cluster Without Customer Managed Encryption Key (CMEK)	Bigtable cluster configured without CMEK.	CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest.

Cloud Run

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Cloud Run Job Running with Permissive Permissions	A user / users with the roles/run.admin role can invoke or interact with the Cloud Run Job. While this approach can simplify deployment and usage, it also raises security concerns, as it may expose sensitive data or functions to potential misuse or unauthorized access.	Permissive permissions present significant security risks in cloud environments, as they can lead to unauthorized access, data breaches, and potential misuse of resources.
Identity & Access Management	Cloud Run Service Running with Permissive Permissions	A user / users with the roles/run.admin role can invoke or interact with the Cloud Run Service. While this approach can simplify deployment and usage, it also raises security concerns, as it may expose sensitive data or functions to potential misuse or unauthorized access.	Permissive permissions present significant security risks in cloud environments, as they can lead to unauthorized access, data breaches, and potential misuse of resources.
Identity & Access Management	IAM with cloud run service admin permission	A GCP identity with admin permissions to cloud run job.	An attacker with this permission has administrative access to a cloud run job.
Identity & Access Management	IAM with cloud run service admin permission	A GCP identity with admin permissions to cloud run service.	An attacker with this permission has administrative access to a cloud run service.
Identity & Access Management	Unauthenticated Invocations Allowed for Cloud Run Service	Unauthenticated invocations are enabled for this Cloud Run service. It is assigned the "allUsers" principal type with the "Cloud Run Invoker" IAM role. This effectively makes the service accessible to anyone on the internet without requiring authentication, granting anonymous access to it.	This service can be accessed by an attacker without the need for authentication. This could potentially be leveraged to exploit any vulnerabilities, resulting in a Denial of Service (DoS) attack, unauthorized extraction of sensitive data, or remote execution of commands on the underlying host.
Insecure Configurations	Binary Authorization Disabled for Cloud Run Job	Binary Authorization offers deployment control based on policies, ensuring that only trusted and verified container images are allowed for deployment.	An attacker who gains access to the Continuous Integration environment can inject malicious code or tamper with legitimate code during the build and deployment (CI-CD) process. This can introduce vulnerabilities, backdoors, or other security weaknesses into the software, which may go undetected until the compromised code is deployed.
Insecure Configurations	Binary Authorization Disabled for Cloud Run Service	Binary Authorization offers deployment control based on policies, ensuring that only trusted and verified container images are allowed for deployment.	An attacker who gains access to the Continuous Integration environment can inject malicious code or tamper with legitimate code during the build and deployment (CI-CD) process. This can introduce vulnerabilities, backdoors, or other security weaknesses into the software, which may go undetected until the compromised code is deployed.
Permissive Access	Cloud Run Job is Using the Compute Engine Default Service Account	Cloud Run job uses the compute engine default service account. This account is automatically created when a new project is set up By default, this service account has broad IAM permissions and it is automatically associated with every Cloud Run job.	An attacker with access to the default service account token could access each and every Cloud Run job and its associated management API operating within the same GCP project.
Permissive Access	Cloud Run Service is Using the Compute Engine Default Service Account	Cloud Run service uses the compute engine default service account. This account is automatically created when a new project is set up. By default, this service account has broad IAM permissions and is automatically associated with every Cloud Run service.	An attacker with access to the default service account token could access each and every Cloud Run service and its associated management API operating within the same GCP project.
Public Exposure	Cloud Run Service Publicly Accessible	This risk signifies a publicly accessible Cloud Run Service, making it accessible to any Internet user. Publicly accessible services raise the risk of unauthorized access, misuse, and breaches. The necessity of this public service should be verified; if not required, immediate action to restrict this service is advised to minimize potential security risks.	Depending on the application deployed, an attacker can exploit vulnerabilities to gain unauthorized access, manipulate and steal sensitive data, and even execute malicious actions that compromise the entire system.

Compute Engine

Category	Risk Name	Description	Attack Scenario
Credentials Exposure	Compute Engine Instance With Cleartext Chargify Key	Chargify Key Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Jenkins Password	Jenkins Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext MySQL Password	MySQL Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext NewRelic Key	NewRelic Key Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext OAuth Key	OAuth Key Discovered in Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Postgres Password	Postgres Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext RabbitMQ Password	RabbitMQ Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Salesforce Credentials	Salesforce Credentials Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Segment Token	Segment Token Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext SMTP Password	SMTP Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Vero Secret	Vero Secret Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Sensitive Generic Secret	Sensitive Generic Secret Found in Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Sensitive Generic Secret In Metadata	Sensitive Generic Secret Found in Metadata	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Identity & Access Management	IAM principal with set IAM policy permission on compute instances	A GCP Identity with permissions to set an IAM policy for compute instances.	An attacker with the setIamPolicy on a compute instance will be able to modify the IAM policy of the instance, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project instances' policies. This method could range from full access to a specific instance to full administrator access to the project.
Insecure Configurations	Compute Engine Instance With Interactive Serial Console Enabled	VM interactive serial console is enabled and does not support IP-based access restrictions.	Attacker can attempt to connect to the instance's serial console from any IP address.
Insecure Configurations	Compute Engine Instance With IP Forwarding Enabled	VM instance with a configuration that enables IP forwarding.	Attacker can attempt to send and receive packets with differenct source and destination.
Insecure Configurations	Compute Engine Instance With Project Wide SSH Keys	VM instance with a configuration that allows project-wide SSH keys.	Attacker can attempt to connect to an instance using the SSH keys configured for the project.
Insecure Configurations	Unused Compute Engine Disk	Unused disk by any instance is found.	An attacker can access the unused disk, leading to data exposure.
Unsupported Software	Deprecated Compute Engine Image
Unsupported Software	Compute Engine Instance With Deprecated Image	A deprecated image.	An attacker can exploit the deprecated image and create an instance using it.

Dataproc

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	API access to all Google Cloud services in same project is allowed	Dataproc cluster configured to allow API access to all Google Cloud services in the same project.	An attacker with access to compute engine can access google cloud services without scope limitation, leading to potentially exploit various services.
Insecure Configurations	Dataproc Cluster Without Customer Managed Encryption Key (CMEK)	A Dataproc cluser configured without CMEK.	CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest.
Public Exposure	Public Dataproc Cluster	A public Dataproc cluster.	An attacker can access Dataproc instances from the internet.
Unsupported Software	Dataproc Cluster With Unsupported Image Version	A Dataproc cluster with an unsupported image version.	An attacker can exploit known unpatched vulnerabilities in unsupported images.

Function

Category	Risk Name	Description	Attack Scenario
Permissive Access	Compute Engine Instance Default Service Account With Owner Role	Compute Engine default service account with owner permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will have full access to the project.
Permissive Access	Compute Instance Default Service Account With Editor Role	Compute Engine default service account with editor permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project.
Permissive Access	Service Account With Editor Role	Service Account with editor permissions on the project.	An attacker with access to the service account will be able to perform most of the actions in the project.
	Service Account With Owner Role	Service Account with owner permissions on the project.	An attacker with access to the service account will be able to perform any action in the project.
Permissive Access	User With Editor Role	User with editor permissions on the project.	An attacker with access to the user will be able to perform most of the actions in the project.
Permissive Access	User With Owner Role	User with owner permissions on the project.	An attacker with access to the user will be able to perform any action in the project.
Insecure Configurations	Cloud Function With HTTP Only (not HTTPS)	GCP function with HTTP trigger set to require HTTP only (and not HTTPS). OWASP A6:2017 Security Misconfiguration.	An attacker can invoke the function via HTTP, gain the function app permissions and compromise your environment.
Public Exposure	Cloud Function Allows Anonymous Access	The function allows access for anonymous users. OWASP A2:2017 Broken Authentication.	An anonymous attacker can run actions against the function and might damage internal services or expose sensetive data.
Permissive Access	Cloud Function Can Be Invoked By Anonymous Users	The function can be invoked by anonymous users. OWASP A6:2017 Security Misconfiguration.	An anonymous attacker can invoke the function and might damage internal services or expose sensetive data.
Unsupported Software	GCP Function With Deprecated Runtime	GCP function with a deprecated runtime. OWASP A6:2017 Security Misconfiguration.	An attacker can exploit known unpatched vulnerabilities in the gcp function runtime.

GKE (Google Kubernetes Engine)

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	GKE Cluster is Alpha	GKE alpha cluster. OWASP K09:2022 Misconfigured Cluster Components	Alpha clusters are short-lived clusters that run stable Kubernetes releases with all Kubernetes APIs and features enabled. Alpha clusters are limited and do not receive security updates.
Insecure Configurations	GKE Cluster With Application Layer Secrets Encryption Disabled	GKE cluster with application-layer secrets encryption disabled. OWASP K08:2022 Secrets Management Failures	An attacker can gain access to an offline copy of etcd, where secrets are stored.
Insecure Configurations	GKE Cluster With Client Certificate	GKE cluster with client certificate. OWASP K06:2022 Broken Authentication Mechanisms	An attacker can use the base64 certifcate public certificate to authenticate to the cluster endpoint. Certificates do not rotate automatically. and are difficult to revoke.
Insecure Configurations	GKE Cluster With 'Cloud Logging' Option Disabled	GKE cluster with "Cloud Logging" option disabled. OWASP K05:2022 Inadequate Logging and Monitoring	Logging provides audit and diagnostic logs in your account. Collecting logs are critical for clusters as it significantly accelerates the troubleshooting process.
Insecure Configurations	GKE Cluster With 'Control plane authorized networks' Option Disabled	GKE cluster with "Control plane authorized networks" option disabled. OWASP K07:2022 Missing Network Segmentation Controls	An attacker can access the cluster's control plane endpoint through HTTPS.
Insecure Configurations	GKE Cluster With Default Service Account Attached To Node Pool	GKE cluster with a default service account attacked to the node pool. OWASP K09:2022 Misconfigured Cluster Components	By default, nodes are given the compute engine default service account. This account has more permissions than are required to run your Kubernetes Engine cluster, allowing attackers to use these permissions to compromise your environment.
Insecure Configurations	GKE Cluster With 'Legacy authorization' Option Enabled	GKE cluster with "Legacy authorization" option enabled. OWASP K06:2022 Broken Authentication Mechanisms	By default, ABAC is disabled for clusters created using GKE version 1.8 and later as RBAC has significant security advantages over ABAC.
Insecure Configurations	GKE Cluster With Network Policy Disabled	GKE cluster with network policy disabled. OWASP K07:2022 Missing Network Segmentation Controls	An attacker can access any pod in the cluster without network restrictions. Network policy is used to create Pod-level firewall rules. These firewall rules determine which Pods and Services can access one another inside your cluster.
Insecure Configurations	GKE Cluster With Shielded Nodes Disabled	GKE cluster with shielded nodes disabled. OWASP K09:2022 Misconfigured Cluster Components	An attacker can exploit a vulnerability in a Pod to exfiltrate bootstrap credentials and impersonate nodes in a cluster giving the attacker access to cluster secrets.
Insecure Configurations	GKE Cluster Without Automatic Node Upgrade	GKE cluster with no automatic node upgrade enabled. OWASP K09:2022 Misconfigured Cluster Components	Node auto-upgrades help you keep the nodes in your cluster up-to-date with the cluster control plane version when your control plane is updated on your behalf.
Insecure Configurations	GKE Cluster With 'secure boot' Option Disabled	GKE cluster with 'secure boot' option disabled. OWASP K09:2022 Misconfigured Cluster Components	Secure boot helps protect nodes against boot-level and kernel-level malware and rootkits.

KMS (Cloud Key Management)

Category	Risk Name	Description	Attack Scenario
Neglected Resource	KMS Key With Rotation Period Bigger Than 90 Days	A KMS key that has a rotation period bigger than 90 days.	Key rotation reduces the risk of a compromised key being used by an attacker to access your encrypted resources.
Public Exposure	Publicly Accessible KMS Key	A publicly accessible Cloud KMS key.	An attacker can access your KMS key. Depending on the level of access, he might be able to use the key to decrypt data and compromise it.

Memorystore

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Memorystore AUTH is Disabled	Disabling authentication (AUTH) in Memorystore allows unrestricted access to the data store, leaving it exposed to unauthorized users and increasing the risk of data breaches and tampering.	An attacker, aware that authentication (AUTH) is disabled in Memorystore, can gain unauthorized access to the data store, potentially exfiltrating sensitive data, injecting malicious content, or disrupting the service without any authentication barriers.
Insecure Configurations	Memorystore Connection by Direct Peering	Using Direct Peering establishes a direct VPC peering connection between the customer's network and Google's managed project, potentially exposing the customer's network to security risks, as this peering isn't shared with other Google Cloud services and lacks the enhanced access controls and isolation offered by Private Service Access (PSA).	An attacker monitors network traffic in the customer's VPC that uses Direct Peering to connect to Memorystore for Redis. Since Direct Peering lacks the isolation and security features of Private Service Access (PSA), the attacker can potentially eavesdrop on sensitive data transmissions, such as Redis authentication credentials or sensitive cache data, leading to data exfiltration or unauthorized access.
Insecure Configurations	Memorystore Encryption by Transit is Disabled	Disabling encryption in Memorystore's transit data transmission exposes data to potential interception, tampering, and security breaches, posing significant risks to data confidentiality and integrity.	An attacker monitoring the network traffic between a client application and a Memorystore instance with encryption in transit disabled could intercept sensitive user session data, such as login credentials, and potentially launch a man-in-the-middle attack, impersonating the client or the server, leading to data theft or manipulation.
Insecure Configurations	Memorystore Encryption without CMEK	Not having Customer Managed Encryption Keys (CMEK) in Memorystore's encryption setup leaves data encryption solely reliant on default Google-managed keys, potentially exposing sensitive data to unauthorized access and lacking the enhanced control and key management provided by CMEK.	An attacker with sufficient knowledge of Memorystore's encryption configuration without CMEK could potentially compromise the default Google-managed keys, gaining unauthorized access to the encrypted data and bypassing the additional security controls offered by customer-managed encryption keys, leading to data exposure and potential breaches.

Network Firewall

Category	Risk Name	Description	Attack Scenario
Public Exposure	Firewall Rule Permits Connections From Any IP (0.0.0.0/0)	This risk signifies a Google Cloud Platform Firewall Rule configured to allow incoming connections from any IP address, indicated by the range 0.0.0.0/0. This unrestricted access can heighten the risk of unauthorized access and potential data breaches. It's recommended to verify whether such broad access is necessary and, if not, promptly refine the access control to allow connections from specific, trusted IP addresses or ranges.	An attacker might use this misconfiguration to access assets within the GCP environment.

Project

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Compute Engine Instance Default Service Account With Owner Role	Compute Engine default service account with owner permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will have full access to the project.
Identity & Access Management	Compute Instance Default Service Account With Editor Role	Compute Engine default service account with editor permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project.
Identity & Access Management	GKE cronJobs permissions	GKE any cronJobs permission.	An attacker can create, delete, get, list and update any cronJob.
Identity & Access Management	GKE daemonSets permissions	GKE any daemonSets permission.	An attacker can create, delete, get, list and update any daemonSets.
Identity & Access Management	GKE deployments permissions	GKE any deployments permission.	An attacker can create, delete, get, list and update any deployments.
Identity & Access Management	GKE job permissions	GKE any jobs permission.	An attacker can create, delete, get, list and update any job.
Permissive Access	GKE permissions to create any resource	GKE permissions to create any resource.	An attacker can create any resource in the cluster, leading to cluster compromise.
Permissive Access	GKE permissions to create cluster role binding	GKE permissions to create cluster role bindings.	An attacker can create cluster roles binded to a risky role, leading to cluster compromise.
Permissive Access	GKE permissions to create cronjobs	GKE permissions to create cronjobs.	An attacker can create cronjobs containing containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to create daemonsets	GKE permissions to create daemonsets.	An attacker can create daemonsets containing containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to create deployments	GKE permissions to create deployments.	An attacker can create a deployment with malicious components leading to cluster compromise.
Permissive Access	GKE permissions to create ingresses	GKE permissions to create ingresses.	An attacker can create risky ingresses, exposing internal services and leading to cluster compromise.
Permissive Access	GKE permissions to create jobs	GKE permissions to create jobs.	An attacker can create jobs containing malicious code executed within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to create pods	GKE permissions to create pods.	An attacker can create pods containing containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to create replicasets	GKE permissions to create replicasets.	An attacker can create replicasets containing containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to create replication controllers	GKE permissions to create replication controllers.	An attacker can create replication controllers containing containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to create role binding	GKE permissions to create role bindings.	An attacker can create roles binded to a risky role, leading to cluster compromise.
Permissive Access	GKE permissions to create statefulsets	GKE permissions to create statefulsets.	An attacker can create statefulsets containing containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to delete any resource	GKE permissions to delete any resource.	An attacker can delete any resource in the cluster, leading to cluster compromise.
Permissive Access	GKE permissions to get any resource	GKE permissions to get any resource.	An attacker can delete any resource in the cluster, leading to cluster compromise.
Permissive Access	GKE permissions to list any resource	GKE permissions to list any resource.	An attacker can list any resource in the cluster, leading to cluster compromise.
Permissive Access	GKE permissions to update cronjobs	GKE permissions to update cronjobs.	An attacker can update cronjobs to contain containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to update daemonsets	GKE permissions to update daemonsets.	An attacker can update daemonsets to contain containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to update deployments	GKE permissions to update deployments.	An attacker can update a deployment to contain malicious components leading to cluster compromise.
Permissive Access	GKE permissions to update ingresses	GKE permissions to update ingresses.	An attacker can update ingresses to expose internal services, which can lead to cluster compromise.
Permissive Access	GKE permissions to update jobs	GKE permissions to update jobs.	An attacker can update cronjobs to contain containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to update replicasets	GKE permissions to update replicasets.	An attacker can update replicasets to contain containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to update replication controllers	GKE permissions to update replication controllers.	An attacker can update replication controllers containing containers that execute malicious code within a cluster, leading to cluster compromise.
Permissive Access	GKE permissions to update statefulsets	GKE permissions to update statefulsets.	An attacker can update a statefulset to contain malicious components leading to cluster compromise.
Identity & Access Management	GKE pods permissions	GKE any pods permission.	An attacker can create, delete, get, list and update any pod.
Identity & Access Management	GKE replicaSets permissions	GKE any replicasets permission.	An attacker can create, delete, get, list and update any replicasets.
Identity & Access Management	GKE replicationControllers permissions	GKE any replicationControllers permission.	An attacker can create, delete, get, list and update any replicationController.
Identity & Access Management	GKE secrets permissions	GKE any secrets permission.	An attacker can create, delete, get, list and update any secret.
Identity & Access Management	GKE statefulSets permissions	GKE statefulSets permissions.	An attacker can create, delete, get, list and update any statefulSet.
Permissive Access	IAM principal with set IAM policy permission on compute instances	A GCP Identity with permissions to set an IAM policy for compute instances.	An attacker with the setIamPolicy on a compute instance will be able to modify the IAM policy of the instance, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project instances' policies. This method could range from full access to a specific instance to full administrator access to the project.
Permissive Access	IAM principal with set IAM policy permission on service accounts	A GCP Identity with permissions to set an IAM policy for service accounts.	An attacker with the setIamPolicy on a service account will be able to modify the IAM policy of the resource, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project service accounts' policies and give himself access to the strongest ones. This method could range from full access to a specific resource to full administrator access to the project depending on the permissions of the service account.
Permissive Access	IAM principal with set IAM policy permission on storage buckets	A GCP Identity with permissions to set an IAM policy for storage buckets.	An attacker with the setIamPolicy on a storage bucket will be able to modify the IAM policy of the bucket, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project buckets' policies. This method could range from full access to a specific bucket to full storage access to the project.
Permissive Access	IAM with Create cloud function with service account permission	A GCP identity with permissions to create and call a cloud function with an assigned service account.	An attacker with the iam.serviceAccounts.actAs, cloudfunctions.functions.create, cloudfunctions.functions.sourceCodeSet and cloudfunctions.functions.call will be able to create a new cloud function with a specified service account. The function, when invoked, can access the metadata API and return the associated service account's access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Permissive Access	IAM with Create cloud scheduler with service account permission	A GCP identity with permissions to create a cloud scheduler job.	An attacker with the iam.serviceAccounts.actAs and >cloudscheduler.jobs.create permissions will be able to create jobs that send requests to *.googleapis.com endpoints. These requests can be authenticated as a specific service account. To escalate privileges with this method, the attacker needs to create an HTTP request of the action he wants to perform.
Permissive Access	IAM with Create compute instance with service account permission	A GCP identity with permissions to create a new compute instance with a specified service account.	An attacker with the iam.serviceAccounts.actAs and with permissions to create a new instance will be able to create an instance with a specified service account and get its access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Permissive Access	IAM with Create Deployments permission	A GCP Identity with permissions to create a deployment in the deployment manager service.	An attacker with the deploymentmanager.deployments.create permission can gain the Editor role permissions on the project. This permission lets you launch new deployments of resources into GCP as the PROJECT-NUMBER@ cloudservices.gserviceaccount.com service account, which, by default, is granted the Editor role on the project.
Permissive Access	IAM with Create service account key permission	A GCP Identity with permissions to create a service account key.	An attacker with the iam.serviceAccountKeys.create permission can create a user-managed key for a Service Account that will allow him to access GCP as that Service Account. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Permissive Access	IAM with Create service usage API key permission	A GCP identity with permissions to create API keys.	An attacker with the serviceusage.apiKeys.create permission will be able to create an API key, that is unrestricted by default, and use it to authenticate with GCP's APIs. By that, he can gain access to the entire GCP project.
Permissive Access	IAM with Create storage HMAC keys permission	A GCP identity with permission to create HMAC keys.	An attacker with the storage.hmacKeys.create permission will be able to create an hmac key for a specified service account, and use it for authentication. Depending on the service account's permissions, this method could range from no privilege escalation to full storage access.
Permissive Access	IAM with Get service account access token permission	A GCP Identity with permissions to get a service account's access token	An attack with the iam.serviceAccounts.getAccessToken permission will be able to get an access token that belongs to a specified service account and gain its permissions. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Permissive Access	IAM with List service usage API keys permission	A GCP identity with permissions to get an existing API key.	An attacker with the serviceusage.apiKeys.list and apikeys.keys.getKeyString permissions will be able to get all the API keys in the project. If there is an unrestricted key, the attacker will gain full access to the project.
Permissive Access	IAM with Set IAM policy permission on the project	A GCP Identity with permissions to set an IAM policy for the project.	An attacker with the setIamPolicy on a project will be able to modify the IAM policy of the resource, granting himself additional privileges. This method could lead to full administrator access to the project.
Permissive Access	IAM with Sign service account blob permission	A GCP Identity with permission to sign a blob.	An attack with the iam.serviceAccounts.signBlob permission will be able to create a signed blob that requests an access token from a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Permissive Access	IAM with Sign service account JWT permission	A GCP Identity with permission to sign a JWT (JSON web token).	An attack with the iam.serviceAccounts.signJwt permission will be able to sign and request an access token of a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Permissive Access	IAM with Update cloud function with service account permission	A GCP identity with permissions to update an existing cloud function and its assigned service account.	An attacker with the iam.serviceAccounts.actAs, cloudfunctions.functions.update and cloudfunctions.functions.sourceCodeSet permissions will be able to update an existing cloud function and even switch its service account to a function that accesses the metadata API and retrieves the associated service account's access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Permissive Access	IAM with Update IAM Role permission	A GCP Identity with permissions to update an IAM role.	An attacker with the iam.role.updatepermission and a custom role assigned will be able to add permissions to the role, and by that gain more privileges or even full privileges on the project.
Permissive Access	Service Account With Editor Role	Service Account with editor permissions on the project.	An attacker with access to the service account will be able to perform most of the actions in the project.
Permissive Access	Service Account With Owner Role	Service Account with owner permissions on the project.	An attacker with access to the service account will be able to perform any action in the project.
Permissive Access	User With Editor Role	User with editor permissions on the project.	An attacker with access to the user will be able to perform most of the actions in the project.
Permissive Access	User With Owner Role	User with owner permissions on the project.	An attacker with access to the user will be able to perform any action in the project.
Insecure Configurations	Project With Interactive Serial Console Enabled	Project VM interactive serial console is enabled and does not support IP-based access restrictions.	Attacker can attempt to connect to the instance's serial console from any IP address.

Pub/Sub

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Compute Engine Instance Default Service Account With Owner Role	Compute Engine default service account with owner permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will have full access to the project.
Identity & Access Management	Compute Instance Default Service Account With Editor Role	Compute Engine default service account with editor permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project.
Identity & Access Management	Service Account With Editor Role	Service Account with editor permissions on the project.	An attacker with access to the service account will be able to perform most of the actions in the project.
Identity & Access Management	Service Account With Owner Role	Service Account with owner permissions on the project.	An attacker with access to the service account will be able to perform any action in the project.
Identity & Access Management	User With Editor Role	User with editor permissions on the project.	An attacker with access to the user will be able to perform most of the actions in the project.
Identity & Access Management	User With Owner Role	User with owner permissions on the project.	An attacker with access to the user will be able to perform any action in the project.
Insecure Configurations	Pub/Sub Topic Without Customer Managed Encryption Key (CMEK)	Pub/Sub topic without customer-managed encryption key (CMEK).	With no customer-managed encryption key (CMEK), an attacker can manage message encryption and decryption process.

IAM (Identity and Access Management)

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	IAM principal with set IAM policy permission on service accounts	A GCP Identity with permissions to set an IAM policy for service accounts.	An attacker with the setIamPolicy on a service account will be able to modify the IAM policy of the resource, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project service accounts' policies and give himself access to the strongest ones. This method could range from full access to a specific resource to full administrator access to the project depending on the permissions of the service account.
Identity & Access Management	IAM with Create service account key permission	A GCP Identity with permissions to create a service account key.	An attacker with the iam.serviceAccountKeys.create permission can create a user-managed key for a Service Account that will allow him to access GCP as that Service Account. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Identity & Access Management	IAM with Get service account access token permission	A GCP Identity with permissions to get a service account's access token	An attack with the iam.serviceAccounts.getAccessToken permission will be able to get an access token that belongs to a specified service account and gain its permissions. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Identity & Access Management	IAM with Sign service account blob permission	A GCP Identity with permission to sign a blob.	An attack with the iam.serviceAccounts.signBlob permission will be able to create a signed blob that requests an access token from a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Identity & Access Management	IAM with Sign service account JWT permission	A GCP Identity with permission to sign a JWT (JSON web token).	An attack with the iam.serviceAccounts.signJwt permission will be able to sign and request an access token of a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.

Cloud SQL

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Cloud PostgreSQL Instance Without 'point-in-time' Recovery	PostgreSQL instance without point-in-time recovery.	Point-in-time recovery helps you recover an instance to a specific point in time. For example, if an error causes a loss of data, you can recover a database to its state before the error occurred.
Insecure Configurations	Cloud SQL Instance Connection Logs Disabled	SQL instance without connection logs enabled.	The "log_connections" flag causes each attempted connection to the server to be logged, as well as successful completion of both client authentication (if necessary) and authorization. By default this option is set to "off", allowing attackers to login to the instance without leaving a trace.
Insecure Configurations	Cloud SQL Instance Without Automatic Backup	SQL instance without automatic backup configuration.	Backups protect your data from loss or damage.
Insecure Configurations	Cloud SQL Instance Without SSL Encryption	SQL instance without SSL encryption configured.	Unsecured connections are allowed to connect to this instance.
Insecure Configurations	GCP PostgreSQL Instance Flag 'cloudsql.allowpasswordless local_connections' is On	Setting the "cloudsql.allowpasswordless local_connections" to 'on' enables local connections without a password.	An attacker gains access to the local network and connect to a user since there is no need for a password.
Insecure Configurations	GCP PostgreSQL Instance Flag 'cloudsql.iam_authentication' is Off	Turning off 'cloudsql.iam_authentication' in GCP PostgreSQL relies solely on traditional authentication, potentially weakening IAM security integration.	An attacker who gains access to database credentials could potentially impersonate a user without the added security of IAM authentication checks. This could lead to unauthorized data access, manipulation, or even malicious actions within the database, compromising data security.
Insecure Configurations	Gcp Sql Instance Flag 'check_proxy_users' is Off	'check_proxy_users' flag off in GCP SQL risks unauthorized access by proxy users, compromising security.	An attacker who gains access to a proxy user's credentials could potentially impersonate the proxy user without proper authentication checks. This could allow the attacker to perform unauthorized actions, access sensitive data, and potentially exploit the lack of authentication verification to compromise the integrity and security of the database.
Insecure Configurations	GCP SQL Instance Flag 'default_password_lifetime' is set to 0	Setting 'default_password_lifetime' to 0 in GCP SQL risks prolonged use of unchanged passwords, heightening the potential for unauthorized access and security breaches.	An attacker could gain access to a user's password and maintain unauthorized access indefinitely without password expiration. This increases the likelihood of undetected and prolonged data breaches.
Insecure Configurations	Gcp SQL Instance Flag 'disconnect_on_expired_password' is Off	Turning 'disconnect_on_expired_password' off in GCP SQL allows users with expired passwords continued access, risking unauthorized and insecure access.	An attacker who obtains the login credentials of a user with an expired password could continue to access the database. This could lead to unauthorized data manipulation, data theft, or even malicious actions within the database, compromising data security and integrity.
Insecure Configurations	GCP SQL Instance Flag 'local_infile' is On	'local_infile' flag in GCP SQL increases risk of data exposure and unauthorized access via local file loading.	An attacker with access to the database could potentially exploit the feature to load malicious files from their local system into the database.
Insecure Configurations	GCP SQL Instance Flag 'mysqlnative_password proxy_users' is Off	This variable controls whether the mysql_native_password built-in authentication plugin supports proxy users. It has no effect unless the check_proxy_users system variable is enabled.	An attacker who gains access to a proxy user account is not authorized and connects to the account.
Insecure Configurations	GCP SQL Instance Flag 'password_require_current' is Off	A GCP SQL instance "password_require_current" flag is set to "off".	An attacker, taking advantage of the flag being off, changes a password without the need to know the old password, thereby gaining access to the account.
Insecure Configurations	GCP SQL Instance Flag 'skip_show_database' is Off	Turning 'skip_show_database' off in GCP SQL risks exposing database and schema details, facilitating unauthorized enumeration and targeted attacks.	An attacker could potentially use the SHOW DATABASES command to enumerate available databases and gain insights into the database schema. This knowledge could aid them in crafting more effective and targeted attacks.
Insecure Configurations	GCP SQL is Not Using CMK	GCP SQL instance without CMK.	In a scenario where a GCP SQL instance is not using Customer-Managed Keys (CMK), an attacker who gains unauthorized access to Google's managed encryption keys or exploits vulnerabilities in Google's key management infrastructure could potentially decrypt and access sensitive data stored in the SQL database, leading to data breaches and confidentiality breaches.
Insecure Configurations	GCP SQL Without Password Policy	No password policy in GCP SQL increases the risk of weak passwords and unauthorized access, compromising data security.	An attacker could potentially perform brute-force attacks or use common passwords to guess weak passwords associated with the database, granting them unauthorized access to the data and compromising the security and integrity of the system.
Public Exposure	Cloud SQL Instance Allows Network Connection From Any IP (0.0.0.0/0)	SQL instance with an authorized network of 0.0.0.0/0	This prefix will allow any IPv4 client to pass the network firewall and make login attempts to your instance, including clients you did not intend to allow.
Public Exposure	GCP SQL is Not Using Private Ip	GCP SQL instance is Not Using Private Ip.	Without a private IP in GCP SQL, an attacker could potentially intercept sensitive database traffic over the public network, leading to data exposure.

Storage Bucket

Category	Risk Name	Description	Attack Scenario
Data Security	Cloud Storage Bucket Contains Potentially Public Objects	This risk identifies a Google Cloud Storage bucket that contains objects that may be publicly accessible, thereby potentially enabling any internet user to access them. Potentially shared objects in a storage bucket can heighten the risk of unauthorized data access and potential data breaches. It's recommended to review these objects and their access controls, and if public access is not required, promptly update their permissions to secure your data.	An attacker can maybe access some objects in the bucket leading to data exposure.
Data Security	Storage Bucket Publicly Accessible	This risk points to a Google Cloud Storage bucket configured as publicly accessible, potentially making it reachable by any internet user. Publicly accessible storage buckets can significantly increase the risk of unauthorized data access and potential data breaches. It's recommended to verify whether such public access is necessary and, if not, promptly restrict access to strengthen your data security.	An attacker can access this bucket and compromise your data.
Data Security	Storage Bucket Without Encryption	This risk signifies a Google Cloud Storage bucket that lacks encryption, a critical security measure to protect sensitive data from unauthorized access. Unencrypted Storage buckets can raise the risk of data exposure or misuse. It's strongly advised to enable encryption to safeguard your data and comply with security best practices and regulations.	An attacker can access this bucket and compromise your data
Identity & Access Management	IAM principal with set IAM policy permission on storage buckets	A GCP Identity with permissions to set an IAM policy for storage buckets.	An attacker with the setIamPolicy on a storage bucket will be able to modify the IAM policy of the bucket, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project buckets' policies. This method could range from full access to a specific bucket to full storage access to the project.
Identity & Access Management	Service Account With Editor Role	Service Account with editor permissions on the project.	An attacker with access to the service account will be able to perform most of the actions in the project.
Identity & Access Management	Service Account With Owner Role	Service Account with owner permissions on the project.	An attacker with access to the service account will be able to perform any action in the project.
Identity & Access Management	User With Editor Role	User with editor permissions on the project.	An attacker with access to the user will be able to perform most of the actions in the project.
Identity & Access Management	User With Owner Role	User with owner permissions on the project.	An attacker with access to the user will be able to perform any action in the project.

Oracle Cloud Infrastructure (OCI) - click to collapse

Oracle Cloud Infrastructure (OCI)

Click on a service name below to view a table of the risks Panoptica detects in OCI, along with brief descriptions and attack scenarios.

DB System

Category	Risk Name	Description	Attack Scenario
Data Security	Oracle Autonomous Databases Publicly Accessible	Autonomous database with a cidr address of 0.0.0.0/0.	An attacker might be able to access the database from any IP address.
Data Security	Oracle Database Auto Backup Disabled	Database without automatic backup configuration.	It is a best practice to enable continuous backups for your databases.
Data Security	Oracle Database Without Encryption	Unencrypted database.	An attacker can access the data stored in your database.
Insecure Configurations	Autonomous Oracle Database Without mTLS	mTLS is not required for the database.	mTLS helps ensure that traffic is secure and trusted in both directions between a client and server.

Policy

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Administator permissions over tenancy	Administator access over tenancy.	An attacker with administrator permissions can perform any action on any resource in the environment.
Identity & Access Management	Manage cluster-family permission in compartment	Permission to manage cluster-family in compartment.	An attacker with manage cluster-family access has full access to container engine for kubernetes resources in the compartment.
Identity & Access Management	Manage cluster-family permission in tenancy	Permission to manage cluster-family in tenancy.	An attacker with manage cluster-family access has full access to container engine for kubernetes resources in tenancy.
Identity & Access Management	Manage database-family permission in compartment	Permission to manage database-family in compartment.	An attacker with manage database-family access has full access to database resources in the compartment.
Identity & Access Management	Manage database-family permission in tenancy	Permission to manage database-family in tenancy.	An attacker with manage database-family access has full access to database resources in tenancy.
Identity & Access Management	Manage DNS permission in compartment	Permission to manage DNS in compartment.	An attacker with manage DNS access has full access to DNS resources in the compartment.
Identity & Access Management	Manage DNS permission in tenancy	Permission to manage DNS in tenancy.	An attacker with manage DNS access has full access to DNS resources in tenancy.
Identity & Access Management	Manage instance-family permission in compartment	Permission to manage instance-family in compartment.	An attacker with manage instance-family access has full access to instance resources in the compartment.
Identity & Access Management	Manage instance-family permission in tenancy	Permission to manage instance-family in tenancy.	An attacker with manage instance-family access has full access to instance resources in tenancy.
Identity & Access Management	Manage object-family permission in compartment	Permission to manage object-family in compartment.	An attacker with manage object-family access has full access to bucket and object resources in the compartment.
Identity & Access Management	Manage object-family permission in tenancy	Permission to manage object-family in tenancy.	An attacker with manage object-family access has full access to buckets and objects resources in tenancy.
Identity & Access Management	Manage policies permission in tenancy	Permission to manage policies in tenancy.	An attacker with 'manage' permission over policies in the tenancy can exploit this permission and perform privilege escalation by creating a policy with higher permissions and assign its group to be part of it.
Identity & Access Management	Manage users permission in tenancy	Permission to manage users in tenancy.	An attacker with 'manage' users permission can perform any action on users in the environment such as resetting passwords, leading to privilege escalation.
Identity & Access Management	Use all resources permission in tenancy	Permission to use all resources in tenancy.	An attacker with 'use' permission over all resources in the tenancy can exploit this permission and perform privilege escalation.

Storage Bucket

Category	Risk Name	Description	Attack Scenario
Data Security	Object Storage Bucket Publicly Accessible	This risk identifies an Oracle Cloud Storage bucket configured to be publicly accessible, potentially making it reachable by any internet user. Publicly accessible buckets significantly raise the risk of unauthorized data access and potential data breaches. It's recommended to ascertain the necessity of such public access, and if it's not required, promptly restrict access to bolster your data security.	An attacker can access the bucket and objects leading to data exposure.
Data Security	Object Storage Bucket Without Encryption	This risk indicates an Oracle Cloud Storage bucket not configured for encryption, a vital security measure to safeguard sensitive data from unauthorized access. Unencrypted buckets can increase the risk of data exposure or misuse. It's strongly recommended to enable encryption to secure your data and adhere to security best practices and compliance regulations.	An attacker can access this bucket and compromise stored data.

User

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	User Without MFA	This risk highlights an Oracle Cloud user who doesn't have Multi-Factor Authentication (MFA) enabled. MFA offers an added layer of security by requiring more than just a password for user authentication. An absence of MFA exposes the user's account to a heightened risk of unauthorized access. It's strongly advised to enable MFA for all users to strengthen account security within Oracle Cloud.	An attacker can bypass authentication with a password only.

Kubernetes - click to collapse

Kubernetes

Click on a service name below to view a table of the risks Panoptica detects in Kubernetes clusters, along with brief descriptions and attack scenarios.

API Endpoint

Category	Risk Name	Description	Attack Scenario
Public Exposure	Publicly Exposed Asset	Public API endpoint with authentication issues that has a PII in the response.	An attacker can leverage the authentication issue to access the endpoint and obtain the PII returned in the response.

Cluster Role

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Cluster Role With Attach Pods Permissions	OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create CronJobs Permissions	A cluster role that allows to create cronjobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create DaemonSets Permissions	A cluster role that allows to create daemonsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Deployments Permissions	A cluster role that allows to create deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Jobs Permissions	A cluster role that allows to create jobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Mutating Webhook Configuration Permissions	A cluster role that allows create mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role with Create or Wildcard Permissions to the LocalSubjectAccessReview Resource	A Cluster role with Create or Wildcard Permissions to the LocalSubjectAccessReview Resource.	An attacker with access to this cluster role can map users and their associated permissions within a namespace in the cluster.
Identity & Access Management	Cluster Role with Create or Wildcard Permissions to the SubjectAccessReview Resource	A Cluster role with Create or Wildcard Permissions to the SubjectAccessReview Resource.	An attacker with access to this cluster role can map users and their associated permissions within the cluster.
Identity & Access Management	Cluster Role with Create or Wildcard Permissions to the TokenRequest Resource	A Cluster role with Create or Wildcard Permissions to the TokenRequest Resource.	An attacker with access to this cluster role can request tokens for any service account in the cluster. Service account tokens are used to authenticate requests to the Kubernetes API server, and if an attacker has access to those tokens, they can use them to impersonate service accounts and gain access to privileged resources and actions. This could give the attacker the ability to modify or delete any resource in the cluster, potentially leading to a full compromise of the cluster.
Identity & Access Management	Cluster Role With Create ReplicaSets Permissions	A cluster role that allows to create replicasets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Replication Controllers Permissions	A cluster role that allows to create replicationcontrollers in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create RoleBinding Permissions	A cluster role that allows to create a role binding to any role in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker can leverage this permission to create a binding between its identity and a strong role in the cluster.
Identity & Access Management	Cluster Role With Create RoleBinding/ClusterRoleBinding Permissions	A cluster role in Kubernetes with permission to create a cluster role binding. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to that cluster role can escalate his privileges by binding the service account or user to the cluster-admin cluster role or a different cluster role with higher permissions.
Identity & Access Management	Cluster Role With Create StatefulSets Permissions	A cluster role that allows to create statefulsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Validating Webhook Configuration Permissions	A cluster role that allows create validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role With Delete Deployments Permissions	A cluster role that allows to delete deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Delete Mutating Webhook Configuration Permissions	A cluster role that allows delete mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role With Delete Namespaces Permissions	Cluster role with delete namespaces in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	Attacker with delete namespace permission can delete any namespace in the cluster include the running pods in the namespace.
Identity & Access Management	Cluster Role With Delete Validating Webhook Configuration Permissions	A cluster role that allows delete validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role With Delete/DeleteCollection Secrets Permissions	A cluster role that allows to delete or deletecollection secrets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Exec Pods Permissions	OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role with Full Permissions to any Resources on Non-K8s Core or Wildcard API Groups	A cluster role has full permissions for any resource on API groups other than wildcard or the K8s core API.	An attacker with access to this cluster role can perform any action against the API groups defined in this cluster role. Possibly escalate his privileges and move laterally within the cluster.
Identity & Access Management	Cluster Role with Get and Create Permissions to the Nodes/Proxy Resource	A cluster role with Get and Create permissions to the nodes/proxy resource.	An attacker that has access to a principal with the Get, Create permissions on the nodes/proxy resource can communicate with the Node’s Kubelet API directly and possibly escalate it's privileges to a cluster admin.
Identity & Access Management	Cluster Role With Patch Mutating Webhook Configuration Permissions	Cluster role with patch mutating webhook configuration in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role With Patch Validating Webhook Configuration Permissions	Cluster role with patch validating webhook configuration in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role with Permissions to Change Configmaps	A cluster role that allows to update or patch configmaps in the cluster.	An attacker with access to this cluster role can alter configmaps in the cluster.
Identity & Access Management	Cluster Role with Permissions to Change Service Accounts	A cluster role with permissions to change service accounts.	An attacker with access to this cluster role can alter service accounts in the cluster.
Identity & Access Management	Cluster Role with Permissions to Create Configmaps	A cluster role that allows to create configmaps in the cluster.	An attacker with access to this cluster role can create configmaps in the cluster.
Identity & Access Management	Cluster Role with Permissions to Create Nodes	A cluster role with permissions to create nodes.	An attacker with access to this cluster role can create nodes in the cluster.
Identity & Access Management	Cluster Role with Permissions to Create Service Accounts	A cluster role with permissions to create service accounts.	An attacker with access to this cluster role can create service acconts in the cluster.
Identity & Access Management	Cluster Role with Permissions to Delete Configmaps	A cluster role that allows to delete configmaps in the cluster.	An attacker with access to this cluster role can delete configmaps in the cluster.
Identity & Access Management	Cluster Role with Permissions to Delete Nodes	A cluster role with permissions to delete nodes.	An attacker with access to this cluster role can delete nodes in the cluster.
Identity & Access Management	Cluster Role with Permissions to Delete Service Accounts	A cluster role with permissions to delete service accounts.	An attacker with access to this cluster role can delete service accounts in the cluster.
Identity & Access Management	Cluster Role with Permissions to Read Configmaps	A cluster role with permissions to read or list Configmaps.	An attack with access to this cluster role can read or list configmaps in the cluster.
Identity & Access Management	Cluster Role with Permissions to Read Service Accounts	A cluster role with permissions to read service accounts.	An attacker with access to this cluster role can read service accounts in the cluster.
Identity & Access Management	Cluster Role with Permissions to Update Nodes	A cluster role with permissions to update nodes.	An attacker with access to this cluster role can update nodes in the cluster.
Identity & Access Management	Cluster Role With Update CronJobs Permissions	A cluster role that allows to update cronjobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update DaemonSets Permissions	A cluster role that allows to update daemonsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update Deployments Permissions	A cluster role that allows to update deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update Jobs Permissions	A cluster role that allows to update jobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update ReplicaSets Permissions	A cluster role that allows to update replicasets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update Replication Controllers Permissions	A cluster role that allows to update replicationcontrollers in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update StatefulSets Permissions	A cluster role that allows to update statefulsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update\Patch Secrets Permissions	A cluster role that allows to update or patch secrets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With View Secrets Permissions	A cluster role that allows to list and view all secrets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	Once there is a single account in the cluster with the cluster-admin role binding, an attacker with access to that cluster role can steal the admin’s token and escalate his privileges to the highest cluster privileges.
Identity & Access Management	Cluster Role With View Secrets Permissions	A cluster role that allows to get any secret in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker can leverage this permission to obtain a secret value and move lateraly inside the cluster.
Identity & Access Management	Cluster Role With Wildcard Create Permissions	A cluster role that allows to create any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard CronJobs Permission	A cluster role that allows to perform any action on cronjobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard DaemonSets Permissions	A cluster role that allows to perform any action on daemonsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Delete Collection Permissions	A cluster role that allows to deletecollection of any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Delete Permissions	A cluster role that allows to delete any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Deployments Permissions	A cluster role that allows to perform any action on deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Impersonate Permissions	A cluster role that allows to impersonate any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Jobs Permission	A cluster role that allows to perform any action on jobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard List Permissions	A cluster role that allows to list any resource in the Kubernetes cluster, including secrets. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to this cluster role can escalate privileges by listing powerful secrets and using their value. It is possible to obtain a secret token belongs to a service account with cluster-admin privileges.
Identity & Access Management	Cluster Role With Wildcard Mutating Webhook Configurations Permissions	A cluster role that allows any action on mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized
Identity & Access Management	Cluster Role with Wildcard Permissions to any Resources on Non-K8s Core or Wildcard API Groups	A cluster role with wildcard permissions for any resource on API groups other than wildcard or the K8s core API.	An attacker with access to this cluster role can perform any action against the API groups defined in this cluster role. Possibly escalate his privileges and move laterally within the cluster.
Identity & Access Management	Cluster Role With Wildcard Pods Permissions	A cluster role that allows to perform any action on pods in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard ReplicaSets Permission	A cluster role that allows to perform any action on replicasets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Replication Controllers Permission	A cluster role that allows to perform any action on replicationcontrollers in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Secrets Permissions	A cluster role with a wildcard in the verbs section on secrets resource. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to that cluster role can view or edit all secrets in the cluster, and escalate his privileges using different methods to take over the cluster control by getting an admin secret.
Identity & Access Management	Cluster Role With Wildcard StatefulSets Permissions	A cluster role that allows to perform any action on statefulsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Validating Webhook Configurations Permissions	A cluster role that allows any action on validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Verbs Permissions	A cluster role with a wildcard in the verbs section. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to that cluster role can execute any action against the resources defined in that cluster role, and escalate his privileges using different methods to take over the cluster control.
Identity & Access Management	Cluster Role With Wildcard View Permissions	A cluster role that allows to get any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	User With Impersonate Group Permissions	A user with permission to Impersonate a group. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to a service account with permissions to impersonate a privileged group may escalate his privileges to gain higher access permissions in the cluster.

Cluster Role Binding

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Cluster Role Binding Allows Unauthenticated Access	ClusterRoleBinding with 'system:unauthenticated' group allow to users are related to this group to perform the actions in the matched role. OWASP K03:2022 Overly Permissive RBAC Configurations	Attacker can perform action in the cluster without to authenticate.
Identity & Access Management	Cluster role binding of service account to wildcard cluster role	OWASP K03:2022 Overly Permissive RBAC Configurations

Deployment

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Kubernetes Dashboard With 'enable-skip-login'' Enabled	Kubernetes-dashboard was found with an "enable-skip-login" parameter enabled.While this parameter is enabled, Users can access the Kubernetes-dashboard without providing authentication details. OWASP K09:2022 Misconfigured Cluster Components	An attacker with network access to the Kubernetes-dashboard can take advantage of this configuration and get information about the cluster and its workloads.

Pod

Category	Risk Name	Description	Attack Scenario
Credentials Exposure	Container With Mounted Secret	K8s secret is mounted inside a container path. OWASP K01:2022 Insecure Workload Configurations	An attacker might use the secret value to laterally move inside the K8s cluster.
Insecure Configurations	Container Running As Root Group	Container running as root group. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to the container can use different methods to escape the container and have root privileges on the host.
Insecure Configurations	Container Running As Root User	Container running as root user. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to the container can use different methods to escape the container and have root privileges on the host.
Insecure Configurations	Container With '/etc' Path Mounted	A container with a risky hostPath mount - mount to the /etc folder in the host filesystem. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host's sensitive information and secret configuration in the host filesystem.
Insecure Configurations	Container With '/root' Path Mounted	A container with a risky hostPath mount - mount to the host /root folder. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host's sensitive information and other containers running on the same host.
Insecure Configurations	Container With '/var' Path Mounted	A container with a risky hostPath mount - mount to the host /var folder. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host's sensitive information and other containers running on the same host.
Insecure Configurations	Container With '/var/lib/kubelet/pods' Path Mounted	A container with a risky hostPath mount - mount to the host /var/lib folder. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host's sensitive information and other containers running on the same host.
Insecure Configurations	Container With AllowPrivilegeEscalation	Container running with AllowPrivilegeEscalation flag set to true. OWASP K01:2022 Insecure Workload Configurations	The allowPrivilegeEscalation is part of the Pod Security Policy Parameters. The allowPrivilegeEscalation Gates whether or not a user is allowed to set the security context to allowPrivilegeEscalation=true in a container. This defaults to allowed so as not to break setuid binaries. An attacker with access to the container can gain more privileges than the container parent.
Insecure Configurations	Container With Full File System Mounted	A container with mount of root directory. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host and escape the container to gain higher privileges.
Insecure Configurations	Container With Privileged Mode	Container running in privileged mode. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to the container can access all devices on the host.
Insecure Configurations	Container With Risky Path Mounted	A container with a risky hostPath mount - mount to the azure.json file. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host configuration file and use its service principal credentials to escalate his Azure subscription privileges.
Insecure Configurations	Container With CAP_SYS_ADMIN+K60	Container with CAP_SYS_ADMIN capability. OWASP K01:2022 Insecure Workload Configurations	CAP_SYS_ADMIN its capability that allow some sensetive action like mount, without any enabled security application attacker can get access to the host.
Insecure Configurations	Container Without Protection Against Root Privileged	Pod configuration without limition of user permission. No definition of runAsUser and runAsNonRoot values in securityContext. OWASP K01:2022 Insecure Workload Configurations	Attacker with access to the cluser can execute command inside container with root permmisions, also attacker can leverege his permissions to container escapes.
Insecure Configurations	Container Without Read Only Filesystem	Container without read-only file system. Read-only filesystems are a key component to preventing container breakout. OWASP K01:2022 Insecure Workload Configurations	A malicious process or application can write back to the host system.
Insecure Configurations	ContainerÂ Without Resource Limits	A container without resource limits. OWASP K01:2022 Insecure Workload Configurations	An attacker with access to a container without resource limits may cause a denial of service for the hosts it's running on.
Insecure Configurations	Pod With Apparmor Disabled	OWASP K01:2022 Insecure Workload Configurations
Insecure Configurations	Pod With 'docker.sock' Mounted	Container with docker.sock mounted. OWASP K01:2022 Insecure Workload Configurations	Attacker with access to container that has docker.sock mounted can run any container on the node, perform container escape, privilege escalation or lateral movements.
Insecure Configurations	Pod With Full Capabilities	Pod gets all capabilities. OWASP K01:2022 Insecure Workload Configurations	Attacker with access to pod with all capabilities can leverage for container escape.
Insecure Configurations	Pod With Log4j Vulnerable Hotpatch	AWS Hotpatch for Log4j Vulnerablity. This Hotpatch could be leveraged for container escape and privileged escalation OWASP K10:2022 Outdated and Vulnerable Kubernetes Components	An attacker can perform conainer escape and get access to underlying host from every container in your cluster. Also, unprivileged processes can exploit the Hotpatch to escalate privileges and gain root code execution.
Insecure Configurations	Pod With '/proc' hostPath Mounted	A pod with a risky hostPath mount - mount to the host /proc directory. OWASP K01:2022<a href=""https://github.com/OWASP/www-project-kubernetes-top-ten/blob/main/2022/en/src/K01-insecure-workload-configurations.md""Insecure> Workload Configurations	Mounting the '/proc' host path could allow an attacker to modify kernel variables, access sensitive data and even container escape.
Insecure Configurations	Pod With 'containerd.sock' Mounted	A pod with a risky hostPath mount - mount to the host /var/run/containerd/containerd.sock socket. OWASP K01:2022<a href=""https://github.com/OWASP/www-project-kubernetes-top-ten/blob/main/2022/en/src/K01-insecure-workload-configurations.md""Insecure> Workload Configurations	An attacker with access to a worker node's 'containerd.sock' socket can interact with the containerd daemon. This would allow him to list and terminate running containers, resulting in a denial of service (DoS).
Insecure Configurations	Pod With '/dev' hostPath Mounted	A pod with a risky hostPath mount - mount to the host /dev directory. OWASP K01:2022<a href=""https://github.com/OWASP/www-project-kubernetes-top-ten/blob/main/2022/en/src/K01-insecure-workload-configurations.md""Insecure> Workload Configurations	Mounting the '/dev' host path could allow an attacker to access to host's devices and even to breakout of the container.
Insecure Configurations	Pod With '/sys' hostPath Mounted	A pod with a risky hostPath mount - mount to the host /sys directory. OWASP K01:2022<a href=""https://github.com/OWASP/www-project-kubernetes-top-ten/blob/main/2022/en/src/K01-insecure-workload-configurations.md""Insecure> Workload Configurations	Mounting the '/sys' host path could allow an attacker to modify kernel variables, access sensitive data and even container escape.

Role

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Cluster Role With View Secrets Permissions In Namespace	A role that allows to get secrets in the namespace. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker can leverage this permission to obtain a secret value and move laterally inside the cluster.
Identity & Access Management	Role With Admin Permissions	A role with a wildcard in the verbs section. OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to that role can execute any action against the resources defined in that role, and escalate his privileges using different methods in the namespace.

Role Binding

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Role Binding Allows Anonymous Access	RoleBinding with 'system:anonymous' user allow to unauthenticated users to perform the actions in the role.	Attacker can perform action in the specific namespace without to authenticate.
Identity & Access Management	Role Binding Allows Unauthenticated Access	RoleBinding with 'system:unauthenticated' group allow to users are related to this group to perform the actions in the matched role. OWASP K03:2022 Overly Permissive RBAC Configurations	Attacker can perform action in the specific namespace without to authenticate.
Identity & Access Management	Role Binding To Default Service Account	OWASP K03:2022 Overly Permissive RBAC Configurations

Source Code Management (SCM) - click to collapse

Source Code Management (SCM)

Click on a service name below to view a table of the risks Panoptica detects in your source code, along with brief descriptions and attack scenarios.

GitHub Organization

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Two-Factor Authentication Should Be Enforced For The Organization	The two-factor authentication requirement is not enabled at the organization level. Regardless of whether users are managed externally by SSO, it is highly recommended to enable this option to reduce the risk of a deliberate or accidental user creation without MFA.	If an attacker gets the valid credentials for one of the organizationâ€™s users they can authenticate to your GitHub organization.
Insecure Configurations	Default Workflow Token Permission Should Be Read Only	The default GitHub Action workflow token permission is set to read-write. When creating workflow tokens, it is highly recommended to follow the Principle of Least Privilege and force workflow authors to specify explicitly which permissions they need.	In case of token compromise (due to a vulnerability or malicious third-party GitHub actions), an attacker can use this token to sabotage various assets in your CI/CD pipeline, such as packages, pull-requests, deployments, and more.
Insecure Configurations	Organization Webhooks Should Be Configured With A Secret	Webhooks are not configured with a shared secret to validate the origin and content of the request. This could allow your webhook to be triggered by any bad actor with the URL.	Not using a webhook secret makes the service receiving the webhook unable to determine the authenticity of the request.This allows attackers to masquerade as your organization, potentially creating an unstable or insecure state in other systems.
Insecure Configurations	Organization Should Have Fewer Than Three Owners	Organization owners are highly privileged and could create great damage if they are compromised. It is recommended to limit the number of Organizational Admins to the minimum needed (recommended maximum 3 owners).	1. An organization has a permissive attitude and provides an owner role to all developers.2. One of the developers has decided to collaborate with an evil ransomware gang, and uses his high privileges to add a malicious external collaborator3. The malicious collaborator, being an owner, has a wide range of destructive operations he can do (e.g. remove security settings)
Insecure Configurations	Workflows Should Not Be Allowed To Approve Pull Requests	The default GitHub Actions configuration allows for workflows to approve pull requests. This could allow users to bypass code-review restrictions.	Attackers can exploit this misconfiguration to bypass code-review restrictions by creating a workflow that approves their own pull request and then merging the pull request without anyone noticing, introducing malicious code that would go straight ahead to production.
Insecure Configurations	Organization Should Use Single-Sign-On	It is recommended to enable access to an organization via SAML single sign-on (SSO) by authenticating through an identity provider (IdP). This allows for central account control and for timely access revocations.	Not using an SSO solution makes it more difficult to track a potentially compromised user's actions accross different systems, prevents the organization from defining a common password policy, and makes it challenging to audit different aspects of the user's behavior.
Insecure Configurations	Runner Group Should Be Limited to Private Repositories	Workflows from public repositories are allowed to run on GitHub Hosted Runners. When using GitHub Hosted Runners, it is recommended to allow only workflows from private repositories to run on these runners. to avoid being vulnerable to malicious actors using workflows from public repositories to break into your private network. In case of inadequate security measures implemented on the hosted runner, malicious actors could fork your repository and then create a pwn-request (a pull-request from a forked repository to the base repository with malicious intentions) that create a workflow that exploits these vulnerabilities and move laterally inside your network.	Hosted runners are usually part of the organization's private network and can be easily misconfigured.If the hosted runner is insecurely configured, any GitHub user could:1. Create a workflow that runs on the public hosted runner2. Exploit the misconfigurations to execute code inside the private network
Insecure Configurations	Only Admins Should Be Able To Create Public Repositories	The organization should be configured to prevent non-admin members creating public repositories. Creating a public repository may expose sensitive organization code, which, once exposed, may be copied, cached or stored by external parties. Therefore, it is highly recommended to restrict the option to create public repositories to admins only and reduce the risk of unintentional code exposure. NOTE: You should also verify that repositories owners can't change existing repositories visibility to be public. If allowed, a malicious user could create a private repo and change it to public. See: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization for further information	A member of the organization could inadvertently or maliciously make public an internal repository exposing confidential data.
Insecure Configurations	Runner Group Should Be Limited to Selected Repositories	Not limiting the runner group to selected repositories allows any user in the organization to execute workflows on the group's runners. In case of inadequate security measures implemented on the hosted runner, malicious insider could create a repository with a workflow that exploits the runner's vulnerabilities to move laterally inside your network.	Hosted runners are usually part of the organization's private network and can be easily misconfigured.If the hosted runner is insecurely configured, any user in the organization could:1. Create a workflow that runs on the hosted runner2. Exploit the runner misconfigurations/known CVE's to execute code inside the private network
Insecure Configurations	Organization Admins Should Have Activity In The Last 6 Months	A member with organizational admin permissions did not perform any action in the last 6 months. Admin users are extremely powerful and common compliance standards demand keeping the number of admins to a minimum. Consider revoking this memberâ€™s admin credentials by downgrading to regular user or removing the user completely.	Stale admins are most likely not managed and monitored, increasing the possibility of being compromised.
Insecure Configurations	GitHub Actions Should Be Limited To Verified or Explicitly Trusted Actions	It is recommended to only use GitHub Actions by Marketplace verified creators or explicitly trusted actions. By not restricting which actions are permitted, developers may use actions that were not audited and may be malicious, thus exposing your pipeline to supply chain attacks.	This misconfiguration could lead to the following attack:1. Attacker creates a repository with a tempting but malicious custom GitHub Action2. An innocent developer / DevOps engineer uses this malicious action3. The malicious action has access to the developer repository and could steal its secrets or modify its content
Insecure Configurations	Organization Webhooks Should Be Configured To Use SSL	Webhooks that are not configured with SSL enabled could expose your software to man in the middle attacks (MITM).	If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request.In the case of GitHub Enterprise Server instances, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain.
Insecure Configurations	Organization Members Should Have Activity In The Last 6 Months	A member did not perform any action in the last 6 months. Stale members can pose a potential risk if they are compromised. Consider removing the user's access completely.	Stale members are most likely not managed and monitored, increasing the possibility of being compromised.
Insecure Configurations	GitHub Actions Should Be Restricted To Selected Repositories	By not limiting GitHub Actions to specific repositories, every user in the organization is able to run arbitrary workflows. This could enable malicious activity such as accessing organization secrets, crypto-mining, etc.	This misconfiguration could lead to the following attack:1. Prerequisite: the attacker is part of your GitHub organization2. Attacker creates new repository in the organization3. Attacker creates a workflow file that reads all organization secrets and exfiltrate them4. Attacker trigger the workflow5. Attacker receives all organization secrets and uses them maliciously
Insecure Configurations	Default Member Permissions Should Be Restricted	Default repository permissions configuration is not set in the organization, thus every new repository will be accessible by default to all users. It is strongly recommended to remove the default permissions and assign them on demand.	Organization members can see the content of freshly created repositories, even if they should be restricted.

GitHub Repository

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Default Branch Should Restrict Who Can Dismiss Reviews	Any user with write access to the repository can dismiss pull-request reviews. Pull-request review contains essential information on the work that needs to be done and helps keep track of the changes. Dismissing it might cause a loss of this information and should be restricted to a limited number of users.	Allowing the dismissal of reviews can promote poor and vulnerable code, as important comments may be forgotten and ignored during the review process.
Insecure Configurations	Default Branch Should Limit Code Review to Code-Owners	It is recommended to require code review only from designated individuals specified in CODEOWNERS file. Turning this option on enforces that only the allowed owners can approve a code change. This option is found in the branch protection setting of the repository.	A pull request may be approved by any contributor with write access. Specifying specific code owners can ensure review is only done by individuals with the correct expertise required for the review of the changed files, potentially preventing bugs and security risks.
Insecure Configurations	GitHub Advanced Security â€“ Dependency Review Should Be Enabled For A Repository	Enable GitHub Advanced Security dependency review to avoid introducing new vulnerabilities and detect newly discovered vulnerabilities in existing packages.	A contributor may add vulnerable third-party dependencies to the repository, introducing vulnerabilities to your application that will only be detected after merge.
Insecure Configurations	Forking Should Not Be Allowed for This Repository	Forking a repository can lead to loss of control and potential exposure of the source code. If you do not need forking, it is recommended to turn it off in the repository configuration. If needed, forking should be turned on by admins deliberately when opting to create a fork.	Forked repositories cause more code and secret sprawl in the organization as forks are independent copies of the repository and need to be tracked separately, making it more difficult to keep track of sensitive assets and contain potential incidents.
Insecure Configurations	Default Branch Should Be Protected	Branch protection is not enabled for this repositoryâ€™s default branch. Protecting branches ensures new code changes must go through a controlled merge process and allows enforcement of code review as well as other security tests. This issue is raised if the default branch protection is turned off.	Any contributor with write access may push potentially dangerous code to this repository, making it easier to compromise and difficult to audit.
Insecure Configurations	OSSF Scorecard Score Should Be Above 7	Scorecard is an open-source tool from the OSSF that helps to asses the security posture of repositories. A low scorecard score means your repository may be at risk.	A low Scorecard score can indicate that the repository is more vulnerable to attack than others, making it a prime attack target.
Insecure Configurations	Repository Webhooks Should Be Configured To Use SSL	Webhooks that are not configured with SSL enabled could expose your sofware to man in the middle attacks (MITM).	If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request.In the case of GitHub Enterprise Server instances, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain.
Insecure Configurations	Default Branch Should Require All Commits To Be Signed	Require all commits to be signed and verified	A commit containing malicious code may be crafted by a malicious actor that has acquired write access to the repository to initiate a supply chain attack. Commit signing provides another layer of defense that can prevent this type of compromise.
Insecure Configurations	Repository Webhooks Should Be Configured With A Secret	Webhooks are not configured with a shared secret to validate the origin and content of the request. This could allow your webhook to be triggered by any bad actor with the URL.	Not using a webhook secret makes the service receiving the webhook unable to determine the authenticity of the request.This allows attackers to masquerade as your repository, potentially creating an unstable or insecure state in other systems.
Insecure Configurations	Default Branch Should Require All Conversations To Be Resolved Before Merge	Require all Pull Request conversations to be resolved before merging. Check this to avoid bypassing/missing a Pull Reuqest comment.	Allowing the merging of code without resolving all conversations can promote poor and vulnerable code, as important comments may be forgotten or deliberately ignored when the code is merged.
Insecure Configurations	Default Branch Deletion Protection Should Be Enabled	The history of the default branch is not protected against deletion for this repository.	Rewriting project history can make it difficult to trace back when bugs or security issues were introduced, making them more difficult to remediate.
Insecure Configurations	Default Workflow Token Permission Should Be Set To Read Only	The default GitHub Action workflow token permission is set to read-write. When creating workflow tokens, it is highly recommended to follow the Principle of Least Privilege and force workflow authors to specify explicitly which permissions they need.	In case of token compromise (due to a vulnerability or malicious third-party GitHub actions), an attacker can use this token to sabotage various assets in your CI/CD pipeline, such as packages, pull-requests, deployments, and more.
Insecure Configurations	Default Branch Should Require All Checks To Pass Before Merge	Branch protection is enabled. However, the checks which validate the quality and security of the code are not required to pass before submitting new changes. The default check ensures code is up-to-date in order to prevent faulty merges and unexpected behaviors, as well as other custom checks that test security and quality. It is advised to turn this control on to ensure any existing or future check will be required to pass.	Not defining a set of required status checks can make it easy for contributors to introduce buggy or insecure code as manual review, whether mandated or optional, is the only line of defense.
Insecure Configurations	Default Branch Should Restrict Who Can Push To It	By default, commits can be pushed directly to protected branches without going through a Pull Request. Restrict who can push commits to protected branches so that commits can be added only via merges, which require Pull Request.	An attacker with write credentials may introduce vulnerabilities to your code without your knowledge. Alternatively, contributors may commit unsafe code that is buggy or easy to exploit that could have been caught using a review process.
Insecure Configurations	Default Branch Should Require Code Review	In order to comply with separation of duties principle and enforce secure code practices, a code review should be mandatory using the source-code-management system's built-in enforcement. This option is found in the branch protection setting of the repository.	Users can merge code without being reviewed, which can lead to insecure code reaching the main branch and production.
Insecure Configurations	Repository Workflows Should Not Be Allowed To Approve Pull Requests	The default GitHub Actions configuration allows for workflows to approve pull requests. This could allow users to bypass code-review restrictions.	Attackers can exploit this misconfiguration to bypass code-review restrictions by creating a workflow that approves their own pull request and then merging the pull request without anyone noticing, introducing malicious code that would go straight ahead to production.
Insecure Configurations	Default Branch Should Require New Code Changes After Approval To Be Re-Approved	This security control prevents merging code that was approved but later on changed. Turning it on ensures any new changes must be reviewed again. This setting is part of the branch protection and code-review settings, and hardens the review process. If turned off - a developer can change the code after approval, and push code that is different from the one that was previously allowed. This option is found in the branch protection setting for the repository.	Buggy or insecure code may be committed after approval and will reach the main branch without review. Alternatively, an attacker can attempt a just-in-time attack to introduce dangerous code just before merge.
Insecure Configurations	Default Branch Should Require Linear History	Prevent merge commits from being pushed to protected branches.	Having a non-linear history makes it harder to reverse changes, making recovery from bugs and security risks slower and more difficult.
Insecure Configurations	Default Branch Should Require Code Review By At Least Two Reviewers	In order to comply with separation of duties principle and enforce secure code practices, a code review should be mandatory using the source-code-management built-in enforcement. This option is found in the branch protection setting of the repository.	Users can merge code without being reviewed, which can lead to insecure code reaching the main branch and production.Requiring code review by at least two reviewers further decreases the risk of an insider threat (as merging code requires compromising at least 2 identities with write permissions), and decreases the likelihood of human error in the review process.
Insecure Configurations	Vulnerability Alerts Should Be Enabled	Enable GitHub Dependabot to regularly scan for open source vulnerabilities.	An open source vulnerability may be affecting your code without your knowledge, making it vulnerable to exploitation.
Insecure Configurations	Default Branch Should Not Allow Force Pushes	The history of the default branch is not protected against changes for this repository. Protecting branch history ensures every change that was made to code can be retained and later examined. This issue is raised if the default branch history can be modified using force push.	Rewriting project history can make it difficult to trace back when bugs or security issues were introduced, making them more difficult to remediate.
Insecure Configurations	Repository Should Have Fewer Than Three Admins	Repository admins are highly privileged and could create great damage if they are compromised. It is recommeneded to limit the number of Repository Admins to the minimum required (recommended maximum 3 admins).	A compromised user with admin permissions can initiate a supply chain attack in a plethora of ways.Having many admin users increases the overall risk of user compromise, and makes it more likely to lose track of unused admin permissions given to users in the past.
Insecure Configurations	Default Branch Should Require Branches To Be Up To Date Before Merge	Status checks are required, but branches that are not up to date can be merged. This can result in previously remediated issues being merged in over fixes.	Required status checks may be failing on the latest version after passing on an earlier version of the code, making it easy to commit buggy or otherwise insecure code.
Insecure Configurations	Repository Should Be Updated At Least Quarterly	A project which is not actively maintained may not be patched against security issues within its code and dependencies, and is therefore at higher risk of including known vulnerabilities.	As new vulnerabilities are found over time, unmaintained repositories are more likely to point to dependencies that have known vulnerabilities, exposing these repositories to 1-day attacks.

GitLab Organization

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Stale Admin Detected	A collaborator with global admin permissions didn't do any action in the last 6 months. Admin users are extremely powerful and common compliance standards demand keeping the number of admins at minimum. Consider revoking this collaborator admin credentials (downgrade to regular user), or remove the user completely.	Stale admins are most likely not managed and monitored, increasing the possibility of being compromised.
Insecure Configurations	Two Factor Authentication Is Disabled For an External Collaborator	An external collaborator's two factor authentication is disabled at the source code management system. Turn it on in the collaborator setting, or globally in the account, to prevent any access without MFA.	Collaborators without two-factor authentication are prime targets for phising and social engineering attacks, as compromise only requires acquiring the collaborator's password.This is doubly important for external collaborators, as these are identities that aren't likely managed by you or your organization and may be easier to compromise.
Insecure Configurations	Two-Factor Authentication Is Not Enforced For The Group	The two-factor authentication requirement is not enabled at the group level. Regardless of whether users are managed externally by SSO, it is highly recommended to enable this option, to reduce the risk of a deliberate or accidental user creation without MFA.	If an attacker gets the valid credentials for one of the organizationâ€™s users they can authenticate to your GitHub organization.
Insecure Configurations	Collaborators Can Fork Repositories To External Namespaces	The ability to fork project to external namespaces is turned on. Forking repositories poses security issues due to the loss of control over the code. It is recommended to disable this feature if it is not explicitly needed, in order to proactively prevent code leakage.	Forking to external namespaces could result in loss of control over proprietary information and potentially expose the organization to security risks, such as data leaks.
Insecure Configurations	Group Does Not Enforce Branch Protection by Default	You do not have a default full branch protection for a specific group, which means any new repository will be created without it. In fully protected level, developers cannot push new commits, and no one can force push or delete the branch. Protecting branches ensures new code changes must go through a controlled merge process and it allows enforcement of code review and other security tests.	A developer creates a repository without any branch protection rulesAttacker that get access to the repository can modify its main branch without any restrictions
Insecure Configurations	Two Factor Authentication Is Disabled For a Collaborator	A collaborator's two factor authentication is disabled at the source code management system. Turn it on in the collaborator setting, or globally in the account, to prevent any access without MFA.	Collaborators without two-factor authentication are prime targets for phising and social engineering attacks, as compromise only requires acquiring the collaborator's password.
Insecure Configurations	Webhook Configured Without SSL	Webhooks that are not configured with SSL enabled could expose your software to man in the middle attacks (MITM).	If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request.In the case of GitLab Self-Managed, it may be sufficient only to control the DNS configuration of the network where the instance is deployed.

GitLab Repository

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Repository Allows Committer Approvals Policy	The repository allows merge request contributors (that aren't the merge request author), to approve the merge request. To ensure merge request review is done objectively, it is recommended to toggle this option off.	Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production.
Insecure Configurations	Repository Allows Review Requester To Approve Their Own Request	A pull request owner can approve their own request. To comply with separation of duties and enforce secure code practices, the repository should prohibit pull request owners from approving their own changes.	Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production.
Insecure Configurations	Project Doesn't Require Code Review By At Least Two Reviewers For Default Branch	In order to comply with separation of duties principle and enforce secure code practices, a code review should be mandatory using the source-code-management built-in enforcement	Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production.
Insecure Configurations	Project Doesn't Require All Conversations To Be Resolved Before Merge	Require all merge request conversations to be resolved before merging. Check this to avoid bypassing/missing a Pull Reuqest comment.	Allowing the merging of code without resolving all conversations can promote poor and vulnerable code, as important comments may be forgotten or deliberately ignored when the code is merged.
Insecure Configurations	Merge Request Authors Nay Override the Approvers List	The repository allows all merge request authors to freely edit the list of required approvers. To enforce code review only by authorized personnel, the option to override the list of valid approvers for the merge request must be toggled off.	Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production.
Insecure Configurations	Project Not Maintained	The project was not active in the last 3 months. A project which is not active might not be patched against security issues within its code and dependencies, and is therefore at higher risk of including unpatched vulnerabilities.	As new vulnerabilities are found over time, unmaintained repositories are more likely to point to dependencies that have known vulnerabilities, exposing these repositories to 1-day attacks.
Insecure Configurations	Unsigned Commits Are Allowed	Require all commits to be signed and verified	A commit containing malicious code may be crafted by a malicious actor that has acquired write access to the repository to initiate a supply chain attack. Commit signing provides another layer of defense that can prevent this type of compromise.
Insecure Configurations	Webhook Configured Without SSL Verification	Webhooks that are not configured with SSL verification enabled could expose your sofware to man in the middle attacks (MITM).	If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request.In the case of GitLab Self-Managed, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain.
Insecure Configurations	Project Doesnâ€™t Require All Pipelines to Succeed	Checks that validate the quality and security of the code are not required to pass before submitting new changes. It is advised to turn this flag on to ensure any existing or future check will be required to pass.	Not defining a set of required status checks can make it easy for contributors to introduce buggy or insecure code as manual review, whether mandated or optional, is the only line of defense.
Insecure Configurations	Default Branch Is Not Protected	Branch protection is not enabled for this repositoryâ€™s default branch. Protecting branches ensures new code changes must go through a controlled merge process and allows enforcement of code review as well as other security tests. This issue is raised if the default branch protection is turned off.	Any contributor with write access may push potentially dangerous code to this repository, making it easier to compromise and difficult to audit.
Insecure Configurations	Project Has Too Many Owners	Projects' owners are highly privileged and could create great damage if being compromised, it's recommeneded to limit them to the minimum required (recommended maximum 3 admins).	A compromised user with owner permissions can initiate a supply chain attack in a plethora of ways.Having many admin users increases the overall risk of user compromise, and makes it more likely to lose track of unused admin permissions given to users in the past.
Insecure Configurations	Default Branch Allows Force Pushes	The history of the default branch is not protected against changes for this repository. Protecting branch history ensures every change that was made to code can be retained and later examined. This issue is raised if the default branch history can be modified using force push.	Rewriting project history can make it difficult to trace back when bugs or security issues were introduced, making them more difficult to remediate.
Insecure Configurations	Code Review Is Not Limited to Code-Owners Only in Default Branch	It is recommended to require code review only from designated individuals specified in CODEOWNERS file. Turning this option on enforces that only the allowed owners can approve a code change. This option is found in the branch protection setting of the project.	A pull request may be approved by any contributor with write access. Specifying specific code owners can ensure review is only done by individuals with the correct expertise required for the review of the changed files, potentially preventing bugs and security risks.
Insecure Configurations	Project Doesn't Require Code Review For Default Branch	In order to comply with separation of duties principle and enforce secure code practices, a code review should be mandatory using the source-code-management built-in enforcement. An even safer option is to require 2 separate reviewers, which is enforced in the Legitify policy "Project Doesn't Require Code Review By At Least Two Reviewers".	Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production.