September 8, 2025

9 Min Read

Despite all the innovation in cloud computing, one persistent issue lurks in the shadows to undermine security hygiene - poor secrets management. Here, we explain compromised secrets’ impacts and causes and offer concrete risk-mitigation recommendations.

Secrets management: A cloud security challenge 

Secrets are credentials used by both human and non-human identities to access systems, applications and data. In modern cloud environments, these include API keys, tokens, access keys and sometimes even usernames and passwords. These secrets are supposed to be protected, but many teams, rushing to deploy new infrastructure and applications, unintentionally leave them exposed by placing them in automation scripts, configurations and even code repositories for convenience.
 

^{(Source: “Tenable Cloud Security Risk Report 2025,” June 2025)}

The “Tenable Cloud Security Risk Report 2025” noted that a large percentage of organizations expose secrets through misconfigurations and mistakes, specifically:

• 54% expose one or more secrets in Amazon Web Services (AWS) Elastic Container Service (ECS) task definitions
• 52% expose one or more secrets in Google Cloud Platform (GCP) Cloud Run environment variables
• 31% expose one or more secrets in Microsoft Azure Logic App workflow configurations
• 26% expose one or more secrets in AWS Elastic Compute Cloud (EC2) user data scripts
• 9% expose one or more secrets in infrastructure-as-code (IaC)

This Tenable report primarily looked at cloud resource misconfigurations that expose secrets, but secrets are also being exposed in many other ways, including logs, public storage, and public Git repositories. While secrets exposed in Git repositories are not a new phenomenon, Verizon’s “2025 Data Breach Investigations Report” (DBIR) noted that cloud infrastructure secrets account for 15% of all secrets exposed in this way, making it the third-largest category of exposed secrets. Exposed and compromised secrets are a significant security concern, and these findings show that secrets are being mismanaged across all major cloud platforms and beyond. Unfortunately, these exposures are causing real-world impact.

The impact of compromised secrets

Compromised secrets can provide attackers with direct access to your environment. If a compromised secret has sufficient privileges, an attacker can use it to move laterally, escalate their privileges and gain access to critical assets. Therefore, targeting cloud credentials is a common initial or early step in many cloud breaches. According to the 2025 DBIR, secrets associated with cloud infrastructure represent a significant share of exposed credentials. 

Let’s look at a few relevant statistics from the 2025 DBIR:

• Credential abuse is the leading initial access vector of breaches, at 22%.
• System intrusion is the leading breach type, at 53%.
• 30% of devices compromised by information stealer (infostealer) malware are enterprise-licensed devices.
• Secrets represent 25% of the data compromised in system intrusion breaches.

Patterns Over Time in Breaches

^{(Source: Verizon’s “2025 Data Breach Investigations Report 2025,” April 2025 – n for 2025 dataset=12,195)}

Once an attacker gains access to a cloud environment, their subsequent actions are driven by their motivation and objective. The majority of breaches are financially motivated – 85%, according to the 2025 DBIR – and ransomware deployment is the most common objective. Recent attacks carried out by these two groups bear this out:

• Codefinger (2025): This ransomware crew, identified by Halcyon, uses compromised AWS keys to encrypt a victim’s S3 bucket data using AWS server-side encryption with customer provided keys (SSE-C). They encrypt the data using a key that is only available to the attacker, then mark the files for deletion to start the countdown for their ransom demand.
• Storm-0501 (2024): This threat actor, identified by Microsoft, infiltrates hybrid-cloud environments. They begin by attacking on-premises environments, compromising credentials and moving laterally to the cloud, where they exfiltrate data or deploy ransomware.

These attacks highlight a worrying trend. Threat actors are pivoting to the cloud, focusing on exposed or compromised secrets and leveraging cloud-native features in their attacks. Protecting secrets must therefore be a critical component of every cloud security program.

Common causes of exposed secrets

Despite the well-known risks, secret exposure persists for several reasons, including the sheer volume of secrets created in dynamic cloud environments, a lack of visibility into who owns or has access to which secrets, and inconsistent use of cloud-native secrets managers. A lack of education around proper secrets usage and secure storage is also to blame, and this doesn’t only apply to cloud resources. (For example, Infostealer malware is designed to steal secrets from victims’ workstations). Users with long-term credentials to cloud environments who store them in the browser, text files, or anywhere else other than a password manager are another common cause of exposure.

It is common for the teams implementing secrets to do so without consulting the identity and access management (IAM) or security teams, which are responsible for the governance and security of these credentials. This contributes to the problems listed above, leading to a dispersion of secrets, a variety of methods for managing them and a lack of consistent security controls to protect them. Understanding where secrets are stored, how they are stored, how they are used and by whom is of vital importance. 

Best practices to protect secrets and mitigate the impact of abuse 

• Involve IAM and security
  • Development, operations, and DevOps teams should involve the IAM and security teams when designing a solution to ensure secrets are properly stored and used, and that the appropriate controls are implemented.
• Avoid using long-term credentials
  • Long-term credentials, such as passwords and keys, should be avoided wherever possible. These are typically associated with user and service accounts stored locally in the cloud provider. Instead, use federation (e.g. SAML 2.0) with temporary credentials.
• Implement lifecycle policies
  • Lifecycle policies should be established to regularly rotate secrets, such as keys, passwords, and certificates.
• Use secrets managers
  • Most cloud service providers offer mature, native secrets management tools that work seamlessly within their cloud (e.g., AWS Secrets Manager, GCP Secrets Manager, Azure Key Vault). Many third-party secrets management solutions also work well in cloud environments. Choose which to adopt and do so consistently and extensively.
  • End users with access to secrets should store them in a password manager approved by their organization.
• Avoid secrets in cloud resource configuration
  • Secrets should not be hardcoded in places like bootstrap scripts, environment variables, and tags. Instead, inject secrets from a secrets manager at runtime.
• Identify public exposure
  • Identify all public cloud storage and workloads, understand the specific access requirements, and restrict all access that is not explicitly required. Assess public and non-public resources to identify issues such as vulnerabilities, misconfigurations, malware, excessive permissions, and toxic combinations of findings that warrant prioritization. Continually monitor for changes to reduce accidental exposure of secrets and other sensitive information.
• Inventory and classify sensitive data
  • Identify where sensitive data, including secrets, reside across your cloud footprint. Understand the access requirements for this data, then implement controls to protect it.
• Audit and monitor access
  • Regularly review secret access logs and alert on suspicious events such as anomalous access patterns and token reuse.
• Create an Incident Response (IR) playbook
  • Establish an IR playbook to create alerts from secrets scanning tools, monitor for anomalous access and external disclosure, identify compromised secrets, then rotate, disable, or delete them.
• Scan infrastructure-as-code (IaC)
  • For cloud environments being built via IaC, assess the IaC in the code repository and within the pipeline to identify cloud resource misconfigurations and exposed secrets, ideally before they reach production.
• Scan application code
  • Application code should also be scanned in the code repository and in the pipeline to identify exposed secrets.
• Secure your cloud identities and entitlements
  • Cloud Infrastructure and Entitlement Management (CIEM) is the process of understanding which human and non-human identities have what type of access to which cloud services and resources, including other secrets. It identifies the net effective permissions of each identity and then compares that to permissions usage to identify overprivileged identities. The privileges granted to an attacker by a compromised secret can either help or hinder them. Using a CIEM, such as Tenable CIEM, to ensure identities only have the necessary permissions can help reduce the blast radius of a compromised or exposed secret.
• Implement a cloud-native application protection platform (CNAPP)
  • A CNAPP, such as Tenable Cloud Security, replaces a patchwork of siloed cloud security products with a single cloud security solution for your multi-cloud environment. CNAPP solutions enable organizations to monitor the health of their cloud footprint on an ongoing basis.

What’s next?

Secrets management will likely evolve in the coming years as the usage of agentic artificial intelligence (AI) increases. AI agents will provision and deprovision resources rapidly and autonomously, and will have a clearly defined scope and context for the task at hand. We at Tenable envision several positive changes coming as a result of this:

• An API for agents to dynamically generate just-in-time secrets with lifetimes measured in seconds or minutes
• Secrets generated by identity providers or brokers, based on federated identity tokens
• Secrets managers with an embedded policy engine for fine-grained, dynamic authorization
• Agent-to-agent trust negotiation such that one agent can delegate a task to another and the associated secret is properly scoped and time-bound
• Continuous scanning to identify leaked secrets then automatically revoking and reissuing them
• Secrets replacement with an identity proof (e.g. federated identity token) and a cryptographic attestation (e.g. mutual Transport Layer Security, or TLS)

Yet, we expect that secrets will continue to be an issue due to factors including: 

• Legacy systems: Older apps will still rely on configuration files and static passwords for years to come.
• Human factors: Developers will still make mistakes such as hardcoding keys in code, pasting them in Slack, uploading them to GitHub, etc.
• Third-party ecosystems: APIs, SaaS tools, and IoT devices often only support static keys.
• Cost and complexity: Not every company can afford to re-architect for ephemeral, secretless patterns.

Conclusion

Secrets are essential to running modern cloud environments - but when they’re mismanaged or misconfigured, they become one of the easiest ways for attackers to access an environment or move laterally within it. As our research and breach data show, these exposures are alarmingly common and attackers are using them to great effect - often without the need for complex attacks.

Tenable Cloud Security equips your organization with the visibility, automation, and context necessary to reduce your cloud exposure. From detecting exposed secrets to prioritizing the most impactful misconfigurations, vulnerabilities, and toxic combinations, we help your teams reduce risk — without slowing down innovation.
 

^{(Source: Tenable Cloud Security: Dashboard widgets showing exposed secrets and toxic combinations of findings)}

Learn more:

• Download the Tenable Cloud Security Risk Report 2025
• Read about the Tenable Identity-first cloud security product
• Take a self-guided tour of Tenable Cloud Security or request a demonstration