Vulnerabilities

Insertion of Sensitive Information into Log File

Property
Language	generic
Severity
CWE	CWE-532: Insertion of Sensitive Information into Log File
OWASP	A09:2021 - Security Logging and Monitoring Failures
Confidence Level	Low
Impact Level	Low
Likelihood Level	Low

Description

Sensitive parameters like passwords, secrets, or tokens are not marked with the @secure() decorator in your Bicep files. This means their values could be exposed in logs or visible in management tools.

Impact

If sensitive values are not properly secured, they may be accidentally logged or displayed in Azure Portal, CLI, or PowerShell outputs. This can lead to credential leaks, allowing attackers to access protected resources or compromise your cloud environment.

Insertion of Sensitive Information into Log File

Property
Language
Severity
CWE	CWE-532: Insertion of Sensitive Information into Log File
OWASP	A09:2021 - Security Logging and Monitoring Failures
Confidence Level	Medium
Impact Level	Medium
Likelihood Level	Low

Description

Sensitive information like API keys, secrets, credentials, tokens, or passwords is being written to log files through logger statements. Logging such data exposes confidential details that should remain private.

Impact

If log files containing secrets are accessed by unauthorized users or attackers, they can compromise accounts, gain unauthorized system access, or further exploit the application. This can lead to data breaches, service disruption, and loss of trust in the organization.

Instance with unencrypted block device.

Property
Language
Severity
Service	ec2
Provider	AWS
Vulnerability Type	omission

Description

EC2 instances are configured with block devices (such as EBS volumes) that do not have encryption enabled. This means data stored on these devices is written in plaintext at rest.

Impact

If an attacker gains access to the underlying storage, unencrypted data can be read or copied without restriction, exposing sensitive information and potentially violating compliance requirements.

Instances in a subnet should not receive a public IP address by default.

Property
Language
Severity
Service	ec2
Provider	AWS
Vulnerability Type	misconfiguration

Description

The subnet configuration assigns public IP addresses to instances by default, making them accessible from the public internet. This exposes internal resources unnecessarily by not restricting network access.

Impact

Instances with public IPs are directly reachable from the internet, increasing the risk of unauthorized access, external attacks, and potential data breaches. This can compromise the security of the application’s infrastructure and sensitive data.

Instances should have Shielded VM integrity monitoring enabled

Property
Language
Severity
Service	compute
Provider	Google
Vulnerability Type	omission

Description

VM instances are deployed without Shielded VM integrity monitoring enabled, preventing detection of unauthorized or unexpected changes to the VM’s boot process or system files.

Impact

Without integrity monitoring, malicious modifications to the VM’s boot state or firmware may go unnoticed, increasing the risk of persistent threats and undetected compromise that could lead to data breaches or system control loss.

Instances should have Shielded VM secure boot enabled

Property
Language
Severity
Service	compute
Provider	Google
Vulnerability Type	omission

Description

The configuration does not enable Shielded VM secure boot for Google Compute Engine instances, allowing the system to boot without verifying the digital signatures of boot components. This weakens protection against running unauthorized or tampered boot-level code.

Impact

Without secure boot, attackers could compromise the boot process by injecting malicious code or rootkits, potentially gaining persistent unauthorized access or control over the VM. This increases the risk of undetected system compromise, data breaches, and further exploitation within the cloud environment.

Instances should have Shielded VM VTPM enabled

Property
Language
Severity
Service	compute
Provider	Google
Vulnerability Type	omission

Description

The configuration does not enable Shielded VM’s virtual TPM (vTPM) on Google Compute instances. Without vTPM, VMs lack key hardware-backed security features that help protect against boot-level and system state tampering.

Impact

Without vTPM enabled, attackers may more easily modify or compromise the VM’s boot process or system state, potentially leading to privilege escalation, persistence of malicious code, or bypassing security controls. This increases the risk of unauthorized access and data breaches.

Instances should not have IP forwarding enabled

Property
Language
Severity
Service	compute
Provider	Google
Vulnerability Type	misconfiguration

Description

Enabling IP forwarding on Google Compute instances allows the VM to send and receive network packets that are not specifically addressed to or from its own IP address, which bypasses standard network isolation controls.

Impact

If exploited, attackers could use the instance to route or proxy unauthorized network traffic, potentially enabling lateral movement within the network, data exfiltration, or the compromise of other internal resources.

Instances should not have public IP addresses

Property
Language
Severity
Provider	Google
Vulnerability Type	misconfiguration

Description

The configuration assigns a public IP address to a Google Compute instance, making it directly accessible from the internet. This exposes the instance to unsolicited network traffic and potential external attacks.

Impact

If exploited, attackers can directly connect to the exposed instance, increasing the risk of unauthorized access, data breaches, and service disruption. This exposure can be leveraged to compromise sensitive workloads or pivot further into the cloud environment.

Instances should not override the project setting for OS Login

Property
Language
Severity
Service	compute
Provider	Google
Vulnerability Type	misconfiguration

Description

Instance-level overrides disabling OS Login allow SSH access to persist even after an IAM user’s access is revoked, bypassing centralized access management. This misconfiguration prevents automatic removal of associated SSH keys.

Impact

If exploited, former IAM users may retain unauthorized SSH access to compute instances, increasing the risk of unauthorized activities, data breaches, and non-compliance with access control policies.

< Previous Next >