Security support for SDKs and tools

This page covers the software you download and run yourself: the SDKs, the CLI, the Terraform/OpenTofu provider and the MCP server. It explains how long they receive security fixes, how to report a vulnerability, where security advisories are published and what comes with each release so that you can check what you install. KeenAuth designs these processes to meet the requirements of the EU Cyber Resilience Act (CRA) for products with digital elements.

No package has been published to a public registry yet. Everything on this page that is tied to a release (SBOM, signatures, provenance) starts with the first release of each package.

Support period

• The product line as a whole receives security support for at least 5 years, counted from its general availability.
• Security fixes are released in the latest major version of each package, and upgrading to it is free of charge.
• The previous major version receives security fixes for 12 months after the next major version becomes generally available.
• Every published security update stays available for at least 10 years, or for the rest of the support period if that is longer.

The full policy, including end-of-life warnings and runtime support, is on the versioning and deprecation policy page.

Report a vulnerability

Email security@keenauth.com. This channel is always open and does not depend on a bug bounty campaign.

• Encrypt sensitive details with our OpenPGP key, published at https://trust.keenauth.com/pgp-key.txt. Its fingerprint is 0336 4D65 3B6C AA93 98A6 BE84 5C82 4CF9 48AB 83D6.
• Our contact details are also published in https://trust.keenauth.com/.well-known/security.txt (RFC 9116).
• Include the package name and version, a description and impact, step-by-step reproduction and, if you would like to be credited, your name or handle.
• Do not report vulnerabilities through support tickets or public issues.

An insecure default in an SDK is in scope. Response times, testing rules, safe harbor and coordinated disclosure are set out in our vulnerability disclosure policy.

Security advisories

When we fix a vulnerability, we publish a security advisory at https://trust.keenauth.com/advisories. Each advisory has an identifier of the form ASA-YYYY-NNNN and states:

• a description, the impact and the action you should take;
• for an SDK or tool, the package name, the affected version range and the fixed version;
• a CVSS v4.0 vector and the date of the fix;
• credits for the people who reported the issue.

Vulnerabilities in the SDKs, the CLI, the MCP server and the provider also receive CVE identifiers through GitHub security advisories.

To be notified, follow the Atom feed https://trust.keenauth.com/advisories.atom in any feed reader.

If a vulnerability in one of these products is actively exploited, or a severe incident affects its security, we report it to the authorities as the CRA requires and inform users through an advisory.

SBOM and VEX

Available with the first release of each package:

• SBOM. Every release comes with a software bill of materials in CycloneDX JSON format, listing the components the package contains.
• VEX. When a known vulnerability in a listed component does not affect the package, we state this in an OpenVEX document. A VEX document is produced only when there is such a statement; a release without one has no VEX file.

Verify a release

Available with the first release. The JavaScript/TypeScript packages on npm and the Python package on PyPI are built and published from the public SDK repositories by a release workflow that uses trusted publishing, without long-lived registry tokens.

• npm: packages are published with provenance. Check the registry signatures and provenance attestations of the packages in your project with:

  npm audit signatures
  

• PyPI: releases are published with attestations, shown on the project page.

• Sigstore bundles: every package file and its SBOM are signed with Sigstore keyless signing, and the package files carry a SLSA provenance attestation. These files are attached to the release workflow run in the public SDK repository and kept there for 90 days. Verify a downloaded file with:

  cosign verify-blob <file> --bundle <file>.sigstore.json \
    --certificate-identity "https://github.com/<owner>/<repo>/.github/workflows/release.yml@refs/tags/<tag>" \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com
  

  The command must report that the signature was verified. Use the repository and tag of the release you downloaded.

The MCP server is an npm package and follows the npm steps above. Signing and verification steps for the Go SDK, the CLI and the provider will be published here with their first release.