secrets management

31 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Secure key storage mechanisms to use

Where available, secure storage mechanisms provided by operating systems, frameworks, or cloud service providers should be used: Hardware Security Modules (HSM) or virtual HSMs; Key vaults such as Amazon KMS or Azure Key Vault; External secrets management services such as Conjur or HashiCorp Vault; Secure storage APIs like the ProtectedData class in .NET framework.

Basic key storage rules for environments without secure storage

When secure storage mechanisms are not available, follow these basic rules: Do not hard-code keys into application source code; Do not check keys into version control systems; Protect configuration files containing keys with restrictive permissions; Avoid storing keys in environment variables, as these can be accidentally exposed through functions like phpinfo() or through /proc/self/environ file.

Separation of encryption keys and encrypted data

Encryption keys should be stored in a separate location from encrypted data whenever possible. For example, if data is stored in a database, keys should be stored in the filesystem. This prevents attackers who gain access to one location (through directory traversal or SQL injection) from accessing both keys and data. Storing keys and data on separate systems provides even greater isolation.

Encrypting keys with Data Encryption Key and Key Encryption Key

Encryption keys should be stored in encrypted form using two separate keys: the Data Encryption Key (DEK) encrypts the data, and the Key Encryption Key (KEK) encrypts the DEK. The KEK must be stored separately from the DEK. The encrypted DEK can be stored with the data but is only usable if an attacker obtains both the DEK and KEK. The KEK should be at least as strong as the DEK. Envelope encryption provides further details on managing DEKs and KEKs.

Secrets detection tools for IaC repositories

Open-source tools for detecting secrets exposed in Infrastructure as Code include truffleHog, git-secrets, and GitGuardian. These tools identify vulnerable management of secrets in code repositories and text files.

Secrets leak through npm publish tarball: .npmignore vs .gitignore precedence

When publishing an npm package, the npm CLI creates a tarball from the project directory. If both .gitignore and .npmignore files exist, only files listed in .npmignore are excluded—everything else in .npmignore is published to the registry. If only .gitignore exists, it is used as the ignore pattern. Developers may update .gitignore but forget to update .npmignore, causing sensitive files to be excluded from source control but still included in the published package. This is a common source of secret leaks.

files property in package.json takes precedence over ignore files for npm publish

The 'files' property in package.json works as an allowlist and specifies the array of files to be included in the published package. When both 'files' property and an ignore file are used, the 'files' property takes precedence. This allows developers to explicitly include files and relies on the ignore file as a secondary denylist control.

Use npm publish --dry-run to preview tarball contents before publishing

To avoid accidentally publishing secrets or unwanted files, run 'npm publish --dry-run' first. This command creates and displays the tarball that will be published without actually publishing it to the registry, allowing developers to review the contents before committing to publication.

Enforce exact lockfile versions in CI: npm ci vs yarn install --frozen-lockfile

When there is an inconsistency between package.json and the lockfile, npm and Yarn compensate by installing versions from package.json, defeating the lockfile's purpose. In production and CI environments, use 'npm ci' (npm clean install) or 'yarn install --frozen-lockfile' to abort installation if any inconsistency exists. This ensures exact dependency versions recorded in the lockfile are used.

Disable npm lifecycle scripts by default with ignore-scripts=true in .npmrc

Add 'ignore-scripts=true' to the .npmrc project file or global npm configuration to disable execution of lifecycle scripts (postinstall, preinstall, etc.) from third-party packages by default. This minimizes the attack surface for malicious scripts that can run arbitrary commands during package installation.

npm package lifecycle scripts: --ignore-scripts flag during install

Append the '--ignore-scripts' suffix when installing packages to prevent execution of any scripts declared in package.json lifecycle hooks (postinstall, preinstall, preuninstall, postuninstall, prepare, etc.). For example: 'npm install my-package --ignore-scripts'.

Use @lavamoat/allow-scripts plugin to create allowlist for trusted lifecycle scripts

If packages require legitimate lifecycle scripts, use the @lavamoat/allow-scripts plugin to create an allowlist of packages authorized to run lifecycle scripts. Configure it in package.json under 'lavamoat.allowScripts' with package names as keys set to true. For example: {"lavamoat": {"allowScripts": {"sharp": true}}}. This enables selective enforcement when ignore-scripts=true is set globally.

npm outdated command shows dependency freshness and available updates

Run 'npm outdated' to view which packages are out of date relative to semver ranges in package.json and the latest available versions. Dependencies shown in yellow are within the semver range specified in package.json; dependencies in red have newer versions available outside the specified range. The output includes the current installed version, wanted version (highest matching semver), and latest version for each dependency.

npm doctor command diagnoses npm installation health and environment

Run 'npm doctor' to assess the health of your npm installation and environment. It performs the following checks: verifies the official npm registry is reachable and displays the configured registry, checks Git availability, reviews installed npm and Node.js versions, runs permission checks on local and global node_modules folders and package cache folder, and validates the local npm module cache for checksum correctness.

Verdaccio: lightweight private npm registry with caching and authentication

Verdaccio is a simple, lightweight, zero-config-required private npm registry installed via 'npm install --global verdaccio'. It supports npm registry format including private packages, scopes, package access control, and authenticated users. It can hook remote registries to route dependencies to different registries and cache tarballs locally to reduce bandwidth. Authentication uses htpasswd by default but also supports GitLab, Bitbucket, and LDAP. It scales using different storage providers and includes official Docker images.

npm registry: set default or per-command registry with npm set registry and --registry

Switch to a different npm registry by running 'npm set registry <registry-url>' to set a default registry, or use the '--registry <registry-url>' argument with npm install or publish commands to use a specific registry for that single command.

Generate SBOM (Software Bill of Materials) with @cyclonedx/cyclonedx-npm

Generate an SBOM for supply chain transparency and traceability: run 'npm install @cyclonedx/cyclonedx-npm' then 'npx @cyclonedx/cyclonedx-npm --validate > sbom.json'. Use the '--omit dev' flag to exclude dev dependencies from the SBOM if needed. This produces a CycloneDX formatted JSON file documenting all dependencies and their origins.

Sign npm package artifacts using Sigstore for supply chain integrity

Use Sigstore (sigstore package) to cryptographically sign npm package tarballs and verify their integrity. Sign artifacts created via 'npm pack' using 'sigstore.sign(payload)' which returns a bundle, then save the bundle as a .sigstore.json file. Consumers can verify the signature using 'sigstore.verify(payload, bundle)' before installation to confirm authenticity and integrity.

npm token lifecycle management: create, list, revoke tokens

Manage npm authentication tokens through the npm registry website or CLI. Create tokens using 'npm token create' with optional flags like '--read-only' and '--cidr=<ip-range>' to restrict permissions and IP ranges. List all tokens with 'npm token list'. Revoke compromised or unnecessary tokens with 'npm token revoke <token-id>' or by specifying the token value interactively.

Trusted publishing with OIDC: short-lived workflow-specific credentials for npm

Trusted publishing using OpenID Connect (OIDC) replaces long-lived npm tokens with short-lived, workflow-specific credentials automatically generated during CI/CD processes. This eliminates risks of token compromise, accidental exposure in logs, or manual rotation requirements. Each publish uses cryptographically-signed tokens specific to the workflow that cannot be extracted or reused. Trusted publishing currently supports GitHub Actions and GitLab CI/CD Pipelines. The npm CLI automatically detects OIDC environments and uses them for authentication before falling back to traditional tokens.

Npm trusted publishing generates automatic provenance attestations

When publishing via trusted publishing (OIDC), npm automatically generates provenance attestations that provide cryptographic proof of package authenticity. This allows users to verify that packages come from legitimate sources and have not been tampered with.

npm info command fetches package metadata and contributor information

Run 'npm info <package-name>' to fetch detailed metadata about a package including contributors, version history, and latest releases. Use this command to verify a package is legitimate before installation by checking the source repository and contributor list.

Mobile API key and token rotation

Regularly update and rotate any used API keys or tokens in mobile applications.

Mobile credential storage prohibition on device

Do not store user passwords on the device; use device-specific tokens that can be revoked instead. Do not hardcode credentials in the mobile app.

Mobile credential encryption in transmission

Encrypt credentials in transmission in mobile applications.

Mobile platform-specific secure storage for credentials

Use platform-specific secure storage mechanisms for credentials: Keychain for iOS or Keystore for Android.

Prevent npm token secrets from leaking in Docker images

Do not embed secret tokens in ENV directives or pass them as build arguments that appear in docker history. Use Docker BuildKit secrets feature instead: add '--mount=type=secret,mode=0644,id=npmrc,target=/usr/src/app/.npmrc' to RUN directives and build with 'docker build . -t image-name --secret id=npmrc,src=.npmrc'. Secrets are mounted but never copied into image layers, preventing exposure in build history. If using older Docker versions without BuildKit, enable it with 'DOCKER_BUILDKIT=1 docker build'.

Secure coding basics: Avoiding hardcoded secrets

Hardcoded secrets such as passwords and encryption keys should be avoided in code and should be stored in secure storage.

OWASP Secrets and Key Management Cheat Sheets

Two OWASP cheat sheets are available for secrets and key management: 1. **Secrets Management Cheat Sheet** - covers secrets storage and rotation 2. **Key Management Cheat Sheet** - covers key generation, storage, and rotation These resources are part of the OWASP series.

Protect tokens from being logged in middleware and server logs

OWASP recommends implementing measures to protect against logging tokens in middlewares and server logs, as this could expose sensitive credentials.

OWASP ASVS Cheat Sheet References

The OWASP ASVS index references three key cheat sheets as guidance: 1. **Key Management Cheat Sheet** - Referenced under V11 Cryptography sections (V11.1, V11.3, V11.7) and V13.3 Secret Management for managing cryptographic keys. 2. **Secrets Management Cheat Sheet** - Referenced under V11.7 In-Use Data Cryptography for managing secrets in applications. 3. **Cryptographic Storage Cheat Sheet** - Referenced under V11 Cryptography sections (V11.1, V11.2, V11.3, V11.5) and V13.3 Secret Management for cryptographic implementation and data protection. These resources collectively provide guidance across key management, secrets handling, and cryptographic storage as part of the ASVS security verification standards.

Give your agent this brain