Release JavaScript GCP KMS Storage v1.0.0

[stas-schaller]

Release of @keeper-security/secrets-manager-gcp v1.0.0

Google Cloud Key Management Service integration for secure storage of Keeper Secrets Manager configuration.

Dependencies:

• @keeper-security/secrets-manager-core v17.3.0
• @google-cloud/kms v4.5.0

Closes https://keeper.atlassian.net/browse/KSM-704

To address the issue, the workflow YAML should be updated to specify a permissions block at the job or workflow root, stating the minimal necessary privileges. Since this workflow simply checks out code and runs tests — and does not perform write operations to the repository or PRs — the safest default is to set contents: read. This should be added as a new block immediately after the name: directive and before the on: directive (workflow root), or alternatively inside the test job. For clarity and to avoid unexpected privilege inheritance, the recommended location is at the workflow root; this will apply minimal permissions to all jobs.

No new methods or imports are needed to implement this; simply add the following YAML block in the right place:

permissions:
  contents: read

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​types/​fast-crc32c@​2.0.2
	npm/​@​typescript-eslint/​parser@​8.47.0
	npm/​typescript-eslint@​8.47.0
	npm/​fast-crc32c@​2.0.0
	npm/​@​babel/​preset-env@​7.28.5
	npm/​@​babel/​core@​7.28.5
	npm/​@​typescript-eslint/​eslint-plugin@​8.47.0
	npm/​@​types/​node@​22.19.1
	npm/​rimraf@​6.1.2
	npm/​@​google-cloud/​kms@​5.2.1
	npm/​pino-pretty@​13.1.2
	npm/​ts-jest@​29.4.5
	npm/​eslint@​9.39.1
	npm/​axios@​1.13.2
	npm/​pino@​10.1.0

View full report

In general, the fix is to explicitly set permissions for the GITHUB_TOKEN at either the workflow level or per job, restricting them to the minimum required (typically contents: read for workflows that only need to fetch code). Since this workflow only checks out code and runs local build/publish tooling, and does not interact with GitHub resources in a write-capacity, contents: read is sufficient. No existing functionality relies on broader permissions.

The best, least-invasive fix here is to add a top-level permissions block just under name: (or under on:), so it applies to both generate-sbom and publish-npm without duplicating configuration. Specifically, in .github/workflows/publish.npm.storage.gcp.kms.yml, after line 1 (name: Publish GCP Storage to NPM), insert:

permissions:
  contents: read

This documents the workflow’s requirement and ensures that even if the repo/org default changes or the workflow is copied elsewhere, the GITHUB_TOKEN used by both jobs will be limited to read-only access to repository contents. No new imports, tools, or additional methods are needed.

In general, the fix is to define an explicit permissions: block that restricts the GITHUB_TOKEN to the minimal scopes required. Since this workflow only checks out code and runs commands, it only needs read access to repository contents. We can apply this at the root level so it covers all jobs, unless a job requires additional scopes (none are apparent here).

The best minimal fix without changing existing behavior is to add a workflow‑level permissions: block right after the name: (or after on:) that sets contents: read. This will apply to both generate-sbom and publish-npm, and does not interfere with publishing to NPM because that uses an explicit NPM_TOKEN, not GITHUB_TOKEN. Concretely, edit .github/workflows/publish.npm.storage.gcp.kms.yml to insert:

permissions:
  contents: read

near the top, leaving all jobs and steps unchanged.