Sicherheitsunterstützung für SDKs und Tools

Diese Seite behandelt die Software, die Sie selbst herunterladen und ausführen: die SDKs, die CLI, den Terraform/OpenTofu-Provider und den MCP-Server. Sie erklärt, wie lange diese Sicherheitskorrekturen erhalten, wie Sie eine Schwachstelle melden, wo Sicherheitshinweise veröffentlicht werden und was zu jeder Version gehört, damit Sie prüfen können, was Sie installieren. KeenAuth gestaltet diese Prozesse so, dass sie die Anforderungen des EU Cyber Resilience Act (CRA) für Produkte mit digitalen Elementen erfüllen.

Es wurde noch kein Paket in einem öffentlichen Register veröffentlicht. Alles auf dieser Seite, das an eine Version gebunden ist (SBOM, Signaturen, Provenienz), gilt ab der ersten Version jedes Pakets.

Unterstützungszeitraum

• Die Produktlinie als Ganzes erhält mindestens 5 Jahre lang Sicherheitsunterstützung, gerechnet ab ihrer allgemeinen Verfügbarkeit.
• Sicherheitskorrekturen werden in der neuesten Hauptversion jedes Pakets veröffentlicht, und das Upgrade darauf ist kostenlos.
• Die vorherige Hauptversion erhält 12 Monate lang Sicherheitskorrekturen, nachdem die nächste Hauptversion allgemein verfügbar geworden ist.
• Jedes veröffentlichte Sicherheitsupdate bleibt mindestens 10 Jahre lang verfügbar, oder für den Rest des Unterstützungszeitraums, falls dieser länger ist.

Die vollständige Richtlinie, einschließlich Warnungen zum Lebensende und zur Laufzeitunterstützung, finden Sie auf der Seite Richtlinie zu Versionierung und Veralterung.

Eine Schwachstelle melden

Senden Sie eine E-Mail an security@keenauth.com. Dieser Kanal steht immer offen und hängt nicht von einer Bug-Bounty-Kampagne ab.

• Verschlüsseln Sie sensible Details mit unserem OpenPGP-Schlüssel, der unter https://trust.keenauth.com/pgp-key.txt veröffentlicht ist. Sein Fingerabdruck lautet 0336 4D65 3B6C AA93 98A6 BE84 5C82 4CF9 48AB 83D6.
• Unsere Kontaktdaten sind außerdem unter https://trust.keenauth.com/.well-known/security.txt (RFC 9116) veröffentlicht.
• Geben Sie den Paketnamen und die Version, eine Beschreibung und die Auswirkungen, eine Schritt-für-Schritt-Reproduktion und, falls Sie genannt werden möchten, Ihren Namen oder Ihr Pseudonym an.
• Melden Sie Schwachstellen nicht über Support-Tickets oder öffentliche Issues.

Eine unsichere Standardeinstellung in einem SDK fällt in den Geltungsbereich. Reaktionszeiten, Testregeln, Safe Harbor und koordinierte Offenlegung sind in unserer Richtlinie zur Offenlegung von Schwachstellen beschrieben.

Sicherheitshinweise

Wenn wir eine Schwachstelle beheben, veröffentlichen wir einen Sicherheitshinweis unter https://trust.keenauth.com/advisories. Jeder Hinweis hat eine Kennung der Form ASA-YYYY-NNNN und nennt:

• eine Beschreibung, die Auswirkungen und die Maßnahme, die Sie ergreifen sollten;
• bei einem SDK oder Tool den Paketnamen, den betroffenen Versionsbereich und die korrigierte Version;
• einen CVSS-v4.0-Vektor und das Datum der Korrektur;
• Danksagungen an die Personen, die das Problem gemeldet haben.

Schwachstellen in den SDKs, der CLI, dem MCP-Server und dem Provider erhalten zusätzlich CVE-Kennungen über GitHub-Sicherheitshinweise.

Um benachrichtigt zu werden, abonnieren Sie den Atom-Feed https://trust.keenauth.com/advisories.atom in einem beliebigen Feed-Reader.

Wird eine Schwachstelle in einem dieser Produkte aktiv ausgenutzt oder beeinträchtigt ein schwerwiegender Vorfall dessen Sicherheit, melden wir dies den Behörden, wie es der CRA vorschreibt, und informieren die Nutzer über einen Hinweis.

SBOM und VEX

Verfügbar mit der ersten Version jedes Pakets:

• SBOM. Jede Version wird mit einer Software-Stückliste im CycloneDX-JSON-Format geliefert, die die Komponenten auflistet, die das Paket enthält.
• VEX. Wenn eine bekannte Schwachstelle in einer aufgeführten Komponente das Paket nicht betrifft, geben wir dies in einem OpenVEX-Dokument an. Ein VEX-Dokument wird nur erstellt, wenn eine solche Aussage vorliegt; eine Version ohne Aussage hat keine VEX-Datei.

Eine Version verifizieren

Verfügbar mit der ersten Version. Die JavaScript/TypeScript-Pakete auf npm und das Python-Paket auf PyPI werden von einem Release-Workflow aus den öffentlichen SDK-Repositories erstellt und veröffentlicht, der vertrauenswürdiges Publizieren ohne langlebige Registry-Token verwendet.

• npm: Pakete werden mit Provenienz veröffentlicht. Prüfen Sie die Registry-Signaturen und Provenienz-Attestierungen der Pakete in Ihrem Projekt mit:

  npm audit signatures
  

• PyPI: Versionen werden mit Attestierungen veröffentlicht, die auf der Projektseite angezeigt werden.

• Sigstore-Bundles: Jede Paketdatei und ihre SBOM werden mit Sigstore Keyless Signing signiert, und die Paketdateien enthalten eine SLSA-Provenienz-Attestierung. Diese Dateien sind an den Lauf des Release-Workflows im öffentlichen SDK-Repository angehängt und werden dort 90 Tage lang aufbewahrt. Verifizieren Sie eine heruntergeladene Datei mit:

  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
  

  Der Befehl muss melden, dass die Signatur verifiziert wurde. Verwenden Sie das Repository und den Tag der Version, die Sie heruntergeladen haben.

Der MCP-Server ist ein npm-Paket und folgt den oben beschriebenen npm-Schritten. Die Schritte zur Signierung und Verifizierung für das Go-SDK, die CLI und den Provider werden hier mit deren erster Version veröffentlicht.