Secrets Management Maturity Model
How to strike the right balance between flexibility and security for your teams.
As the saying goes, "Encryption is Easy, Key Management is Hard". The advent of DevOps, cloud-native, and hyper-connected systems have all made the problem more acute than ever.
To help you in growing your secrets management maturity, we built a framework around four key attack surfaces:
- Developer environments
- Source code repositories
- CI/CD pipelines & artifacts
- Runtime environments
Read the white paper, and assess your maturity with the model.
v-text here
v-html here
v-html here
When it Comes to Secrets Management and Secrets Detection, How Mature is Your Organization?
v-html-here
This is a diagnostic tool designed to help security teams assess their security posture regarding secrets management.
Please set aside 5 minutes to complete the survey and review your results. Your results page will provide ratings for both Secrets Management and Secrets Detection areas.
v-html here
[v-html here] This section corresponds to the daily activities of the developer and how they manage to get access to and share the secrets they need to test their programs and scripts.
v-html here
{{currentTopicProgress.currentPage}} out of {{currentTopicProgress.totalPages}} completed
v-html here
v-html here
OVERALL SCORE
v-html here
{{maturityResults.cta}}Print questionnaire and resultsLevel 0 - Uninitiated
Secrets management
Secrets detection
Developer environments
Secrets are shared in clear text through private channels and stored unencrypted in local config files.
No detection in place
Source Control (Source code & Infra-as-Code)
Secrets can be found anywhere in files. They are checked unencrypted into private repositories.
No detection in place
CI/CD pipelines & software artifacts
- Secrets are embedded in final artifacts such as container images.
- VCS and 3rd-party (e.g. code quality tools) access tokens are hardcoded in build scripts.
No detection in place
Runtime environments
- Secrets are embedded in deployment scripts.
- Sensitive variables are printed in server logs.
No detection in place
Secrets management
Secrets detection
Developer environments
Secrets are unencrypted in config files but can be encrypted before sharing with other devs.
No detection in place
Source Control (Source code & Infra-as-Code)
- Secrets are grouped in config files and accessed using environment variables.
- IaC secrets are stored externally – by the cloud services provider (e.g. AWS, GCP).
- Source code and IaC templates are manually and periodically scanned for secrets.
- High-severity incidents are remediated with limited help from developers.
CI/CD pipelines & software artifacts
- Final artifacts do not contain any secrets.
- Pipeline secrets are stored in the build system.
- Sensitive variables are redacted from build logs.
Build outputs (e.g. Docker images) are scanned for secrets manually before a release.
Runtime environments
- Secrets are grouped in a common config file.
- Sensitive variables are redacted from logs.
- Secrets are not scoped by environment.
Secrets are rotated manually in case of exposure or compromise.
Secrets management
Secrets detection
Developer environments
- Secrets are stored in a vault and shared through a secret manager.
- Developer environment secrets are correctly scoped.
Scanning is triggered manually at times by developers on their local workstations.
Source Control (Source code & Infra-as-Code)
Secrets are encrypted and checked into repositories (master key is stored externally).
- Critical repositories are continuously scanned at the pull/merge requests stage.
- Devs contribute to remediation but it is still not a well established and documented process.
CI/CD pipelines & software artifacts
- Secrets are stored in the build process.
- Secrets are scoped; permissions abide by the principle of least privilege.
Build outputs (e.g. Docker images) are scanned for secrets manually before a release.
Runtime environments
Secrets (or master decryption key) are stored in a vault and dynamically loaded with a secrets manager with minimal access controls.
Secrets are rotated manually in case of exposure or compromise.
Secrets management
Secrets detection
Developer environments
- Secrets are stored in a vault and shared exclusively through a secret manager.
- Secrets rotation policy is well defined.
- Scanning before pushing code (pre-commit / pre-push) is adopted by security champions.
- Developers are systematically involved in the remediation process.
Source Control (Source code & Infra-as-Code)
- Secrets are no longer embedded in the current source code revision.
- Secrets rotation policy is well defined.
- All repositories are continuously scanned for hardcoded credentials.
- Collaboration on incident remediation is mandatory for all developers historical incidents are being triaged.
CI/CD pipelines & software artifacts
- Pipeline secrets are stored in a vault and loaded using a secret manager.
- Secrets are scoped; permissions follow the principle of least privilege.
Informative scanning is enforced for all branches (feature, hotfix, etc.) in CI pipelines.
Runtime environments
- Secrets are stored in a vault and dynamically loaded from a secrets manager.
- Secrets are scoped and access is monitored/logged.
Secrets are scheduled for regular rotation.
Secrets management
Secrets detection
Developer environments
- Secrets are stored in a vault with access controls and logging.
- Dynamic secrets with limited scope are used for development when possible.
- Scanning before pushing code (pre-commit / pre-push) is adopted by all developers.
- Developers are systematically involved in the remediation process.
Source Control (Source code & Infra-as-Code)
No presence of valid hardcoded secrets in past or current revisions of source code.
- All repositories are continuously monitored and blocking scans (pre-receive) are setup.
- Remediation workflows are automated and fixing is handled by developers.
CI/CD pipelines & software artifacts
- Pipeline secrets are short-lived, scoped, and stored in an external vault.
- If possible, build secrets are replaced by OpenID Connect (OIDC) tokens for auth.
- All repositories are continuously monitored and blocking scans (pre-receive) are setup.
- Remediation workflows are automated and fixing is handled by developers.
Runtime environments
- Secrets are stored in a vault and loaded dynamically from a secrets manager.
- Restrictive access controls and logging are enforced.
No detection in placeAutomated and scheduled secrets rotation.
Level 0
Secrets are hard-coded in manifest.
Level 1
Secrets are stored in a Kubernetes Secrets Object.
Level 2
Secrets are loaded from external vault.
Level 3
Secrets are loaded directly into the pods. Â Pods share the same credentials.
Level 4
Secrets are ephemeral and each pod has its own set of secrets.
GitGuardian leads the way in Non-Human Identity security, offering end-to-end solutions from secrets detection in code, productivity tools and environments to strong remediation, observability and proactive prevention of leaks.
.svg)
