3 cybersecurity stories from 2024 that show what we need to do in 2025

A few months ago at HashiConf, we discussed our vision for what the building blocks of Security Lifecycle Management (SLM) look like, and that vision closely aligns with what NIST is saying in its 2.0 update from 2024. Three stories from 2024 give a clear sense of how security breaches are happening in today’s IT environments, and they align with three of the five parts of the NIST framework: protect, identify, and detect.

These breach stories are emblematic of the current threat landscape organizations across the world are seeing, and they represent some of the most common vulnerabilities researchers are finding. As we enter a new year, it’s our mission to help businesses, governments, and other organizations understand how to protect their systems by learning from the breaches in past years.

»Protecting secrets: Hard-coded credentials in an AI service

There are a ton of modern open source tools that have exciting capabilities, but don’t always have the clarity of a risk profile for all the different ways that hackers can gain entry to your customer and company data with them.

In one instance, whitehat hackers from Wiz Research identified vulnerabilities at one company that went through several tools, including:

• Istio (service mesh)
• Loki (log aggregator)
• Kubernetes and Helm (orchestration)
• ArgoCD (continuous delivery)

There are more details on this breach here, but take a look specifically at the log leaks (logs are a common place where credentials are leaked):

You can see that someone at the company hard coded a secret directly in this configuration. Not only is this insecure, it’s hard to rotate it out if this has been done on a large number of configurations, because hard-coded secrets aren’t connected to any overarching system that can rotate keys across multiple configurations at scale.

The report has other instances of hard-coded secrets in areas like Helm and the Docker registry. The hackers could also list secrets because they gained Kubernetes cluster admin access.

Credit goes to the vendor for quickly addressing these issues. This is not a unique case. Stolen credentials are the #1 way threat actors are initially breaching IT systems, according to the Verizon Data Breach Investigations Report.

»Secrets management

This is where a secrets manager like HashiCorp Vault becomes so critical to the security strategies of so many companies once they adopt it. As long as you start putting environment variables in these credential fields instead of hard-coded secrets, and then you connect those variables into Vault, you can then let Vault automatically rotate all your secrets.

Not only does this eliminate the friction of manual rotation, which gets in the way of good cybersecurity practices, it also means that if a hacker gains access to view this field, they won’t see the secret in plaintext.

It’s the easiest way to get security best practices spread throughout your organization. And it doesn’t rely on a culture change initiative and hope that engineers will read large documents and adopt the practices. It uses technology to nudge developers and require certain behaviors, which is always more effective.

»Identifying access: The dangers of access tooling sprawl

Another incident from 2024 was when attackers gained access to Snowflake databases. The attack was successful because those Snowflake customers had employees and contractors who were not using the single sign-on (SSO) or hardware-based multi-factor authentication (MFA) workflows that were typical in those organizations. So while some of these customers did have good security tools and processes internally, the contractors might just have a static username and password to access systems, with no expiration. It’s no surprise that those external entities didn’t bother to rotate their secrets. The company didn’t give the external parties the same security requirements practiced internally.

This is certainly a process problem, but it's also a technology problem. You need a secure remote access system that’s set up to implement a standardized modern security process that can be propagated to internal and external parties alike. And then you also need to have a secure, standard offboarding process that’s the same for internal and external parties as well.

You can’t have one-off access processes outside of your security tooling platforms that don’t follow your SLM requirements. Because if you do, you end up with long-lived credentials that lead to long-lived breaches. And this goes back to the importance of Vault secrets management, because some of the active credentials found in this attack were over three years old.

»Modern infrastructure access systems

The organizations vulnerable to this type of attack either have a dangerous sprawl of multiple access tools with no centrality, or they have a central solution but don’t have an easy way to onboard internal and external users of all types. They are typically using VPNs, bastion hosts, jumpboxes, traditional PAM, and other platforms based on these solutions. These solutions are struggling to keep up with the ephemeral nature of cloud and hybrid infrastructure access patterns.

Organizations should consider upgrading their access solution to a modern remote infrastructure access platform that is proxy-based (the user is never directly on the network) and identity-first. This is becoming the preferred option for security teams that are modernizing for the cloud.

HashiCorp Boundary (and its cloud service HCP Boundary) is an example of this type of platform, and it solves most of the usability and onboarding issues that led to the Snowflake breach. Granular role-based permissions and push-button access workflows are set up in advance by platform teams and then pushed out to any internal or external party with a quick onboarding pattern and built-in session recording.

»Detecting secrets: Exposed plaintext credentials when cloning repos

While this last story isn’t one specific event, we’ve seen that it’s a common story: A team is using GitHub Actions to build software artifacts, and they will often clone a version of a GitHub repository into their Actions. If there are plaintext secrets in that source code, then those secrets get exposed in a temporary directory for the build artifact. Now the secret could be exposed in a tool like Artifactory as well as your source code on GitHub.

The takeaway is that you can’t just fix a secret sprawl problem by only reviewing/scanning your source code in your VCS. You have to think about CI/CD systems, build artifacts, wikis, documentation, ticketing systems, and even the company chat.

»Secret scanning

The best tool to help catch these mistakes is a secret scanner. The proven HashiCorp Vault product line includes a secret detection solution: HCP Vault Radar. Vault Radar detects and evaluates the risk level for secrets across:

• Git-based version control
• AWS Parameter Store
• Server file directory structures
• Confluence
• HashiCorp Vault
• Amazon S3
• HCP Terraform and Terraform Enterprise
• JIRA
• Docker images
• Slack

When using a secret scanner like Vault Radar, it’s also important for the solution to have features and intelligence that help teams avoid alert-fatigue, which is another common way that exposed secrets get lost in the shuffle of day-to-day work.

And if a secret scanner has prevention features in addition to detection capabilities, even better. HCP Vault Radar can stop a secret from being exposed before it’s committed to version control with Git pre-receive hooks.

»Takeaways

Based on the breaches we’ve seen in 2024 and previous years, HashiCorp saw three big takeaways that have fed back into our product development:

1. Make it as easy as possible to follow security best practices. Bake it into your standard platform workflows.
2. Tools need to facilitate departments working together to make workflows for secure app development. Security can’t shoulder the burden alone, but developers shouldn’t need to become security experts.
3. You can’t secure what you don’t know about. Tools need to provide visibility with audit trails for secrets usage and system access.

We know that many companies need to do better at these things. After HashiCorp surveyed about 150 of our enterprise customers about their security practices last year, we found that the average organization actively manages policy and access for about ⅓ of their secrets, leaving ⅔ unmanaged.

If you want to know what the road toward better Security Lifecycle Management looks like, visit our SLM resources page and see if we’d make a good partner for your security and platform teams.