Maturity models may be a controversial topic, but used properly we believe they can help leaders understand their capabilities and develop a roadmap for improvement. Hardcoded secrets are an important and common security problem, so we developed a maturity model to help teams improve their secrets management capability.
Although this post focuses specifically on managing secrets, this is just one part of an overall security strategy. As your organization becomes more effective at handling secrets, you will notice impacts in other areas. For example, integrating automated security controls into development workflows will also improve your ability to detect misconfigurations and will provide opportunities to manage supply chain tampering. Scanning repositories for secrets will improve your ability to detect code leakage and to understand how developers interact with your development and production systems. Many aspects of security are interrelated, and improvements focused on one area will often lead to improvements in others.
Our secrets management maturity model progresses through 5 levels of maturity, which suggest how you can develop your own capabilities. The lower levels focus on getting visibility into the extent of your use of hardcoded secrets, and successive levels of maturity increasingly leverage automation, process integrations, and feedback loops to establish robust controls that effectively govern risk. The following table summarizes these levels, and the remainder of this post explains them each in more detail.
| Less mature | ||
| Level 1 | Awareness | Establish policies, train developers, limited enforcement |
| Level 2 | Basic Detection | Automate scanning of repositories and historical versions |
| Level 3 | Advanced Detection | Expand scanning to entire SDLC, external repos, more patterns |
| Level 4 | Enforcement & Alternatives | Establish proactive controls to prevent secrets exposure |
| Level 5 | Risk Reduction | Establish governance over architectural & cultural risk factors |
| More mature | ||
Enhancing Your Secrets Management Maturity
As you build a plan to improve your maturity, remember that sustainable improvements often come from incremental changes. Consider which level your current practices align with, the capabilities of the next higher level, and which changes might be easiest to implement and operationalize. Take it one step at a time, and provide plenty of time for changes to gain adoption before introducing more changes. Above all, identify metrics that illustrate the value of the desired change so that your team can easily recognize the progress they are making.
Level 1: Awareness
Most organizations will start by focusing on awareness. Modern applications are increasingly leveraging APIs, microservice architectures, and the cloud. This makes applications easier to develop and maintain, by reducing the coupling between different components, but also expands the attack surface. Components and services need to securely authenticate with each other and establish authorization mechanisms.
It’s far too common for developers to hardcode secrets such as credentials and keys into source code while concepts are proven, with the intention to implement “proper” security in a later sprint. Unfortunately, that “proper” security may never be fully implemented or developers may not update all instances of hardcoded secrets. Even if all instances are updated, the secrets are still stored in the version history and artifacts for posterity where they may be discovered by attackers.
Level 1 organizations recognize that they may have hardcoded secrets, or they want to establish a process to ensure that they are protected from this risk. They have established policies that ban hardcoded secrets, and they are training developers in the proper use of secrets. They do not have any enforcement mechanisms beyond the honor system and occasional audits (often manual).
Level 2: Basic Detection
Starting to enforce secrets policies is typically how organizations move toward level 2.
Secrets are present in a variety of forms, such as API keys, passwords, authentication tokens, and more. They can be used throughout the development and deployment process, encoded into source code and configuration files, emitted into logs, shared in environment variables and persistent volumes.
The source code repository is one common place to find secrets, and is a great place to start. Rather than implementing ad hoc searches for secrets, level 2 organizations will leverage tools that can scan their code repositories in depth, including the full history of the repository. Identified secrets will be reported so that security and development teams can take remedial actions such as training developers to utilize more secure methods, improve the insecure code, and invalidate any exposed secrets.
Secrets will be identified through multiple means, such as common patterns leveraged by service providers, entropy analysis of strings, and usage in locations where credentials are expected. Most common formats, providers, and APIs will be included.
This level specifically focuses on the organization’s central code repositories from which the automated build, test, and deploy processes are run.
Level 3: Advanced Detection
Level 3 expands upon the secrets detection established in level 2, in depth, breadth, and fidelity.
The scanning is performed more widely across the SDLC, adding build logs, artifacts, containers, and so forth to ensure secrets are not exposed outside of the repositories.
In addition to the central code repositories, the scan expands to external and public repositories. These might include repositories branched from the central repository, as well as repositories associated with users that committed to the central repository and public repositories that include code similar to that in the central repository.
The types of secrets identified will also expand, including additional formats or providers used by the application, or user-defined secret formats and APIs.
Level 3 organizations have good visibility into their use of secrets throughout the application lifecycle, with secrets scanning embedded into automated processes. They are also starting to prioritize findings according to risk factors such as the type of secret and where it is actually used.
Level 4: Enforcement & Alternatives
Once they can consistently detect the insecure use of secrets, organizations move into level 4 by establishing controls that proactively protect against the problem.
Hardcoding secrets into code is often a matter of convenience – it is a straightforward solution to the need for an application to authenticate with appropriate access rights. An alternative approach which level 4 users adopt, is use of a secret management tool such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager.
These tools provide secure storage and management of secrets, including sophisticated lifecycle controls such as automated key rotation. Instead of hardcoding a secret into the application source code, developers instruct the application to retrieve the secret at runtime from the secure key management server or service.
Simply providing a secure alternative is not sufficient to prevent the use of hardcoded secrets, so level 4 organizations also embed automated secret scanning into their development workflows. All code changes are scanned when they are committed to the repository, and commits or pull requests that include secrets are flagged. With the right tools, these organizations even have the option of proactively protecting the main branch by blocking any commit that would introduce a hardcoded secret. The same approach can be applied at other stages of the pipeline, such as breaking container builds when secrets are present, or refusing to execute an insecure container in the runtime environment.
Level 5: Risk Reduction
Level 5 organizations – those that have established automated detection and prevention controls for insecure secrets practices – can now focus on reducing risk through enhanced governance.
While it is important to securely manage secrets, it is also important to remember that secrets themselves do not cause breaches. Exposed secrets represent an opportunity, which becomes a breach only when paired with an attacker who can exploit it. The goal of secrets management is to prevent that opportunity from arising.
The lower levels of this maturity model introduce controls that protect secrets from exposure. Assuming that attackers do not have direct access to secrets, there are still a few ways for secrets to be exposed:
- Compromised developer accounts can enable attackers to assume credentials that provide access to secrets
- Malicious insiders could share or abuse the secrets to which they have access
- Proprietary source code could become publicly exposed and enable attackers to access secrets
Level 5 organizations reduce these risks of exposure through architectural and cultural changes such as:
- Hardening authentication to reduce the risk of account compromise.
- Leveraging approaches such as privilege audits within code, configurations, and roles to minimize the impact of leaked credentials, and enforcing the principles of least privilege and zero trust to minimize the ability of attackers to move laterally once they gain access to the environment.
- Establishing controls to detect and prevent source code leakage which can provide attackers with information they can use to exploit applications and infrastructure.
Want to learn more?
Want to learn more about how Cycode provides visibility, security, and integrity across all phases of the SDLC? Schedule a demo today!
Originally published: January 14, 2022
