Do you know where your secrets are? If not, I can tell you: you are not alone.
Hundreds of CISOs, CSOs, and security leaders, whether from small or large companies, don’t know either. No matter the organization’s size, the certifications, tools, people, and processes: secrets are not visible in 99% of cases.
It might sound ridiculous at first: keeping secrets is an obvious first thought when thinking about security in the development lifecycle. Whether in the cloud or on-premise, you know that your secrets are safely stored behind hard gates that few people can access. It is not just a matter of common sense since it’s also an essential compliance requirement for security audits and certifications.
Developers working in your organization are well-aware that secrets should be handled with special care. They have put in place specific tools and procedures to correctly create, communicate, and rotate human or machine credentials.
Still, do you know where your secrets are?
Secrets sprawl everywhere in your systems, and faster than most realize. Secrets are copied and pasted into configuration files, scripts, source code, or private messages without much thought. Think about it: a developer hard-codes an API key to test a program quickly and accidentally commits and pushes their work on a remote repository. Are you confident that the incident can be detected in a timely manner?
Insufficient audit and remediation capabilities are some of the reasons why secrets management is hard. They are also the least addressed by security frameworks. Yet these grey areas—where unseen vulnerabilities remain hidden for a long time—are blatant holes in your defense layers.
Recognizing this gap, we developed a self-assessment tool to evaluate the size of this unknown. To take stock of your real security posture regarding secrets in your organization, take five minutes to answer the eight questions (it’s completely anonymous).
So, how much do you not know about your secrets?
Secrets Management Maturity Model
Sound secrets management is a crucial defensive tactic that requires some thought to build a comprehensive security posture. We built a framework (you can find the white paper here) to help security leaders make sense of their actual posture and adopt more mature enterprise secrets management practices in three phases:
- Assessing secrets leakage risks
- Establishing modern secrets management workflows
- Creating a roadmap to improvement in fragile areas
The fundamental point addressed by this model is that secrets management goes well beyond how the organization stores and distributes secrets. It is a program that not needs to align people, tools, and processes, but also to account for human error. Errors are not evitable! Their consequences are. That’s why detection and remediation tools and policies, along with secrets storage and distribution, form the pillars of our maturity model.
The secrets management maturity model considers four attack surfaces of the DevOps lifecycle:
- Developer environments
- Source code repositories
- CI/CD pipelines & artifacts
- Runtime environments
We then built a maturity ramp-up over five levels, going from 0 (Uninitiated) to 4 (Expert). Going 0 to 1 is mostly about assessing the risks posed by insecure software development practices, and starting auditing digital assets for hardcoded credentials. At the intermediate level (level 2), secrets scanning is more systematic, and secrets are cautiously shared across the DevOps lifecycle. Levels 3 (Advanced) and 4 (Expert) are focused on risk mitigation with clearer policies, better controls, and increased shared responsibility for remediating incidents.
Another core consideration for this framework is that making it hard to use secrets in a DevOps context will inevitably lead to the bypassing of the protective layers in place. As with everything else in security, the answers lay between protection and flexibility. This is why the use of a vault/secrets manager starts at the intermediate level only. The idea is that the use of a secrets manager should not be seen as a stand-alone solution but as an additional layer of defense. To be effective, it requires other processes, like continuous scanning of pull requests, to be mature enough.
Here are some questions that this model should raise in order to help you evaluate your maturity: how frequently are your production secrets rotated? How easy is it to rotate secrets? How are secrets distributed at the development, integration, and production phase? What measures are put in place to prevent the unsafe dissemination of credentials on local machines? Do CI/CD pipelines’ credentials adhere to the least privileges principle? What are the procedures in place for when (not if) secrets are leaked?
Reviewing your secrets management posture should be top of mind in 2023. First, everyone working with source code has to handle secrets, if not daily, at least once in a while. Secrets are no longer the prerogative of security or DevOps engineers. They are required by more and more people, from ML engineers, data scientists, product, ops, and even more. Second, if you don’t find where your secrets are, hackers will.
Hackers will find your secrets
The risks posed to organizations failing to adopt mature secrets management practices cannot be overstated. Development environments, source code repositories and CI/CD pipelines have become favorite targets for hackers, for whom secrets are a gateway to lateral movement and compromise.
Recent examples highlight the fragility of secrets management even in the most technologically mature organizations.
In September 2022, an attacker got access to Uber’s internal network, where he found hardcoded admin credentials on a network drive. The secrets were used for logging in to Uber’s privileged access management platform, where many more plaintext credentials were stored throughout files and scripts. The attacker was then able to take over admin accounts in AWS, GCP, Google Drive, Slack, SentinelOne, HackerOne, and more.
In August of the same year, the password manager LastPass fell victim of an attacker who gained access toits development environment by stealing the credentials of a software developer and impersonating that individual. Later in December, the firm disclosed that someone used that information to steal source code and customer data.
In fact, in 2022, source code leaks have proven to be a true minefield for organizations: NVIDIA, Samsung, Microsoft, Dropbox, Okta, and Slack, among others, have been victims of source code leaks. In May, we were warning about the important volume of credentials that could be harvested by analyzing these codebases. Armed with these, attackers can gain leverage and pivot into hundreds of dependent systems in what is known as supply chain attacks.
Finally, even more recently, in January 2023, the continuous integration provider CircleCI was also breached, leading to the compromise of hundreds of customer environment variables, tokens, and keys. The company urged its customers to immediately change their passwords, SSH keys, or any other secrets stored on or managed by the platform. Still, victims need to find out where these secrets are and how they are being used to press the emergency button!
This was a strong case for having an emergency plan ready to go.
The lesson from all these incidents is that attackers have realized that compromising machine or human identities gives a higher return on investment. They are all warning signs of the urgency to deal with hardcoded credentials and to dust off secrets management in general.
Final word
We have a saying in cybersecurity: “encryption is easy, but key management is hard.” This still holds true today, although it isn’t just about encryption keys anymore. Our hyper-connected services world relies on hundreds of types of keys, or secrets, to function properly. These could be as many potential attack vectors if mismanaged.
Knowing where your secrets are, not just in theory but in practice, and how they are used along the software development chain is crucial for security. To help you, we created a maturity model specifically about secrets distribution, leak detection, remediation process, and rotation habits.
The first step is always to get a clear audit of the organization’s security posture regarding secrets: where and how are they used? Where do they leak? How to prepare for the worst? This alone could prove to be a lifesaver in an emergency situation. Find out where you stand with the questionnaire and learn where to go from there with the white paper.
In the wake of recent attacks on development environments and business tools, companies that want to defend themselves effectively must ensure that the grey areas of their development cycle are cleared as soon as possible.
