DevSecOps Blueprint: from Vulnerability Management and Security-by-Design to Pipeline Integrity

DOWNLOAD

DevSecOps Blueprint: from Vulnerability Management and Security-by-Design to Pipeline Integrity

DOWNLOAD

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.

Download the white paper
Secrets Management Maturity Model cover image

v-text here

Assessment

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

[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

{{maturityResults.level}}

v-html here

{{maturityResults.cta}}
Print questionnaire and results

Level 0 - Uninitiated

High exposure risk

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

High exposure risk

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.

Moderate exposure risk

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.

Low exposure risk

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.

Limited exposure risk

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.

Kubernetes logo

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.