Support de sécurité pour les SDK et outils

Cette page couvre les logiciels que vous téléchargez et exécutez vous-même : les SDK, la CLI, le fournisseur Terraform/OpenTofu et le serveur MCP. Elle explique pendant combien de temps ils reçoivent les correctifs de sécurité, comment signaler une vulnérabilité, où les avis de sécurité sont publiés et ce qui accompagne chaque version afin que vous puissiez vérifier ce que vous installez. KeenAuth conçoit ces processus pour répondre aux exigences du Cyber Resilience Act (CRA) de l'UE applicables aux produits comportant des éléments numériques.

Aucun paquet n'a encore été publié dans un registre public. Tout ce qui est lié à une version sur cette page (SBOM, signatures, provenance) s'applique à partir de la première version de chaque paquet.

Période de support

• La gamme de produits dans son ensemble bénéficie d'un support de sécurité pendant au moins 5 ans, à compter de sa disponibilité générale.
• Les correctifs de sécurité sont publiés dans la dernière version majeure de chaque paquet, et la mise à niveau vers celle-ci est gratuite.
• La version majeure précédente reçoit des correctifs de sécurité pendant 12 mois après la disponibilité générale de la version majeure suivante.
• Chaque mise à jour de sécurité publiée reste disponible pendant au moins 10 ans, ou pendant le reste de la période de support si celle-ci est plus longue.

La politique complète, y compris les avertissements de fin de vie et le support des environnements d'exécution, figure sur la page politique de versionnage et de dépréciation.

Signaler une vulnérabilité

Envoyez un e-mail à security@keenauth.com. Ce canal est toujours ouvert et ne dépend pas d'une campagne de programme de primes aux bogues.

• Chiffrez les informations sensibles avec notre clé OpenPGP, publiée à l'adresse https://trust.keenauth.com/pgp-key.txt. Son empreinte est 0336 4D65 3B6C AA93 98A6 BE84 5C82 4CF9 48AB 83D6.
• Nos coordonnées sont également publiées dans https://trust.keenauth.com/.well-known/security.txt (RFC 9116).
• Indiquez le nom et la version du paquet, une description et l'impact, la reproduction pas à pas et, si vous souhaitez être crédité, votre nom ou pseudonyme.
• Ne signalez pas les vulnérabilités par des tickets de support ou des tickets publics.

Une valeur par défaut non sécurisée dans un SDK entre dans le périmètre. Les délais de réponse, les règles de test, la protection des chercheurs (safe harbor) et la divulgation coordonnée sont décrits dans notre politique de divulgation des vulnérabilités.

Avis de sécurité

Lorsque nous corrigeons une vulnérabilité, nous publions un avis de sécurité à l'adresse https://trust.keenauth.com/advisories. Chaque avis possède un identifiant de la forme ASA-YYYY-NNNN et précise :

• une description, l'impact et l'action que vous devez entreprendre ;
• pour un SDK ou un outil, le nom du paquet, la plage de versions concernées et la version corrigée ;
• un vecteur CVSS v4.0 et la date de la correction ;
• les crédits attribués aux personnes ayant signalé le problème.

Les vulnérabilités affectant les SDK, la CLI, le serveur MCP et le fournisseur reçoivent également des identifiants CVE via les avis de sécurité GitHub.

Pour être informé, suivez le flux Atom https://trust.keenauth.com/advisories.atom dans n'importe quel lecteur de flux.

Si une vulnérabilité affectant l'un de ces produits fait l'objet d'une exploitation active, ou si un incident grave compromet sa sécurité, nous le signalons aux autorités comme l'exige le CRA et informons les utilisateurs au moyen d'un avis.

SBOM et VEX

Disponibles avec la première version de chaque paquet :

• SBOM. Chaque version est accompagnée d'une nomenclature logicielle (software bill of materials) au format CycloneDX JSON, qui liste les composants contenus dans le paquet.
• VEX. Lorsqu'une vulnérabilité connue dans un composant listé n'affecte pas le paquet, nous le précisons dans un document OpenVEX. Un document VEX n'est produit que lorsqu'une telle déclaration existe ; une version sans déclaration n'a pas de fichier VEX.

Vérifier une version

Disponible avec la première version. Les paquets JavaScript/TypeScript sur npm et le paquet Python sur PyPI sont construits et publiés à partir des dépôts publics des SDK par un workflow de publication qui utilise la publication de confiance (trusted publishing), sans jetons de registre de longue durée.

• npm : les paquets sont publiés avec leur provenance. Vérifiez les signatures du registre et les attestations de provenance des paquets de votre projet avec :

  npm audit signatures
  

• PyPI : les versions sont publiées avec des attestations, affichées sur la page du projet.

• Bundles Sigstore : chaque fichier de paquet et son SBOM sont signés avec la signature sans clé Sigstore (keyless), et les fichiers de paquet comportent une attestation de provenance SLSA. Ces fichiers sont joints à l'exécution du workflow de publication dans le dépôt public du SDK et y sont conservés pendant 90 jours. Vérifiez un fichier téléchargé avec :

  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
  

  La commande doit indiquer que la signature a été vérifiée. Utilisez le dépôt et l'étiquette (tag) de la version que vous avez téléchargée.

Le serveur MCP est un paquet npm et suit les étapes npm ci-dessus. Les étapes de signature et de vérification pour le SDK Go, la CLI et le fournisseur seront publiées ici avec leur première version.