Sécurité et traitement des données

SecCheck est un outil de sécurité : il est donc tenu aux standards d'un outil de sécurité. Cette page énonce clairement comment il vous authentifie, ce qu'il enregistre, et ce qui sort — ou non — du périmètre de Cert-IX.

Authentification et habilitations

• Chaque requête vers https://mcp.cert-ix.com/seccheck doit porter une clé API valide sous forme Authorization: Bearer <key>. Les requêtes sans clé reçoivent un 401 ; le backend ne voit jamais de trafic non authentifié.
• Les clés sont gratuites et en libre-service : demandez-en une sur cert-ix.com/tools/seccheck-mcp, confirmez votre adresse e-mail, et la clé vous parvient par e-mail. Une clé en libre-service relève de l'édition Community, est valable 90 jours et peut être renouvelée depuis l'e-mail de rappel envoyé avant son expiration. Traitez une clé comme un mot de passe : conservez-la dans la configuration de votre client MCP ou dans un coffre à secrets, jamais dans le contrôle de version, et faites-la tourner en cas de fuite possible.
• Tout le trafic passe par TLS. N'envoyez pas de clés en HTTP simple.

Votre édition voyage avec votre clé, et c'est la partie qu'il faut comprendre :

Les habilitations sont résolues à la bordure, à chaque requête

La bordure Cert-IX authentifie votre clé puis positionne vos habilitations sur la requête relayée — systématiquement, à chaque requête, même vides. Un appelant ne peut donc pas déclarer son propre niveau en envoyant lui-même des informations d'habilitation : tout ce que vous envoyez est écrasé avant que le backend ne le voie.

Le serveur refuse de démarrer en mode hébergé si un fichier de licence global au processus est configuré, car une seule variable d'environnement promouvrait sinon tous les appelants d'un coup. Les habilitations viennent de votre clé, une requête à la fois, ou pas du tout.

Si un outil renvoie une erreur de restriction inattendue, appelez license_status — il indique exactement ce que votre identifiant débloque.

Limites de débit et protection contre les abus

Le point de terminaison hébergé applique des limites à la bordure (nginx hôte), avant tout traitement :

Portée	Limite
Par clé API	20 requêtes/seconde (courte rafale jusqu'à 40), 20 connexions simultanées
Par IP source	40 requêtes/seconde (rafale 80), 40 connexions simultanées

Les limites par IP s'appliquent avant l'authentification : les flots non authentifiés sont donc bornés eux aussi.

Dépasser une limite renvoie 429 Too Many Requests avec un en-tête Retry-After. Respectez-le et appliquez un retrait exponentiel ; un client correct doit rester confortablement sous 10 requêtes/seconde par clé. Ces plafonds dépassent largement l'usage normal d'un agent — quelques recherches et un ou deux chargements par tâche — et existent pour arrêter les flots, pas pour freiner le travail réel.

Les échecs d'authentification répétés sont traités comme un abus : une IP qui produit de nombreux 401 en peu de temps est temporairement bloquée (fail2ban). Un détenteur de clé valide ne rencontre jamais cela, puisqu'une clé correcte ne produit jamais de 401.

Ce que vous envoyez, et ce qu'il en advient

Les outils de SecCheck sont des consultations en lecture seule sur un corpus figé. Voici exactement à quoi sert chaque type d'entrée :

Vous envoyez	Ce que SecCheck en fait
Une requête de recherche et des filtres	Les note face au catalogue en mémoire et renvoie les résumés de playbooks correspondants.
Un identifiant de skill	Renvoie le SKILL.md de ce playbook.
Un identifiant de skill + un chemin de ressource	Renvoie ce fichier embarqué, résolu strictement à l'intérieur du répertoire propre au skill.

Vous n'envoyez jamais à SecCheck votre code, vos journaux, vos constats ni quoi que ce soit sur votre environnement — les outils prennent une chaîne de recherche et des identifiants, rien d'autre. Le serveur hébergé n'a aucun accès à votre système de fichiers ni aucune capacité à atteindre vos systèmes.

Quelles données opérationnelles sont conservées

Deux enregistrements existent, tous deux délibérément étroits :

• Comptage d'usage — des nombres d'appels agrégés par outil et par client, pour la capacité et la supervision. Une jauge vivante, pas un registre de facturation.
• Un enregistrement d'audit par appel d'outil, contenant le nom de l'outil, les noms des arguments seulement, votre libellé client, votre niveau, et si l'appel a échoué.

Les requêtes de recherche ne sont jamais journalisées

L'enregistrement d'audit note que vous avez appelé search_skills avec un argument query — pas ce que disait la requête. Une requête de recherche est une saisie utilisateur qui peut décrire un incident en cours ; enregistrer la clé sans la valeur est ce qui fait du journal une preuve de revue d'accès plutôt qu'un vidage de débogage de votre posture de sécurité.

Les deux ne sont exposés que sur un point de terminaison /metrics interne, protégé par jeton, jamais joignable depuis l'internet public, et qui échoue en mode fermé — sans jeton configuré, il refuse purement et simplement de répondre.

Résidence des données — où vit le contenu

Pour SecCheck, la réponse est simple :

• L'intégralité du corpus de 857 playbooks est embarquée dans le serveur SecCheck et servie depuis la mémoire. Recherche, chargement et lecture de ressources sont tous traités par le serveur qui a reçu la requête.
• SecCheck n'effectue aucun appel sortant vers des services tiers au moment de la requête. Il n'y a pas d'API amont, pas de consultation de repli, pas de télémétrie vers un fournisseur externe — le même serveur répond même avec le réseau entièrement coupé. Votre requête est traitée sur l'infrastructure Cert-IX et n'est transmise nulle part ailleurs.
• Votre client MCP, et le modèle d'IA qui le sous-tend, voient aussi tout ce que votre agent envoie et reçoit. Ce côté-là relève de votre client et de votre fournisseur de modèle, pas de Cert-IX.

Vous voulez un déploiement entièrement hors ligne ?

Exécutez SecCheck localement via stdio — le binaire embarque le corpus et n'a besoin d'aucun réseau, ce qui convient aux environnements isolés et à forte exigence d'assurance. Voir Prise en main → Option 2. Le binaire local n'est pas encore en téléchargement public : contactez votre équipe de compte Cert-IX.

Posture réseau (hébergé)

• Le point de terminaison est en façade derrière nginx hôte, unique point d'entrée, qui assure l'authentification, la limitation de débit, la résolution des habilitations et la terminaison TLS.
• Le conteneur SecCheck n'est publié que sur la boucle locale de l'hôte : il n'est joignable depuis l'internet qu'à travers ce nginx.
• Le serveur Go refuse une écoute non locale sauf dérogation explicite, car la couche applicative n'a aucune authentification propre — l'authentification est le rôle de la bordure, et une écoute sur toutes les interfaces publierait un serveur MCP non authentifié.
• /seccheck est le seul chemin exposé publiquement pour ce serveur. Les chemins opérationnels (/metrics) sont internes uniquement.

Intégrité du contenu

Un corpus vide ou partiel serait la version « faux verdict propre » de ce produit : search_skills renverrait « aucun résultat » et un modèle le lirait comme « ce travail de sécurité n'existe pas ». Le serveur refuse donc de démarrer en mode hébergé avec un catalogue vide, et son contrôle de santé se déclare non sain plutôt que d'en servir un — une image sans corpus ne peut pas passer le déploiement.

Obligations de licence et d'attribution

Les playbooks sont du contenu tiers redistribué sous des licences permissives (Apache-2.0 et MIT), tous les droits des auteurs d'origine étant conservés.

• get_attribution renvoie la source amont, l'auteur, l'identifiant de licence, la page d'accueil et le texte complet de la licence pour chaque bibliothèque.
• Si vous redistribuez du contenu de playbook — en interne à grande échelle, dans un produit, ou dans un livrable client — reproduisez ces notices. L'accès via SecCheck ne change pas les termes de licence sous-jacents.

Notes de conformité

• SecCheck traite des requêtes de recherche et des identifiants de documents — des données techniques, pas des données personnelles. Les valeurs des requêtes ne sont pas conservées.
• Les clés API identifient un client/une organisation, pour le contrôle d'accès, la résolution des habilitations et la comptabilisation agrégée du débit — pas pour du profilage.
• La conception à corpus embarqué traite chaque requête sur l'infrastructure Cert-IX : SecCheck lui-même n'a aucune voie de consultation tierce dont il faudrait se désinscrire.

Si vous avez besoin d'un avenant de traitement des données ou d'une garantie de résidence pour une charge de travail réglementée, parlez à votre équipe de compte Cert-IX d'un déploiement dédié ou entièrement hors ligne.

Usage acceptable

La bibliothèque comprend du matériel offensif — exploitation, attaques sur les identifiants, post-exploitation, méthodologie d'attaque web. Elle est publiée pour un travail de sécurité autorisé : des systèmes qui vous appartiennent, des missions pour lesquelles vous disposez d'une autorisation écrite, des CTF, des environnements de formation et de la recherche défensive.

L'utiliser pour attaquer des systèmes que vous n'êtes pas autorisé à tester constitue un détournement du service et relève de votre responsabilité. Cert-IX peut révoquer une clé utilisée de la sorte.

Liste de bonnes pratiques

• ✅ Stockez la clé API dans la configuration sécurisée de votre client MCP, pas dans le dépôt.
• ✅ Faites tourner la clé lors des changements d'effectifs ou en cas de suspicion d'exposition.
• ✅ Faites en sorte que l'agent signale clairement un NO MATCH plutôt que d'improviser une procédure (voir Flux de travail des agents).
• ✅ Lisez un playbook avant d'exécuter ses commandes — c'est un guide tiers écrit pour la pile de quelqu'un d'autre.
• ✅ Si le playbook comporte une section de vérification ou de validation, exécutez-la avant de déclarer le travail terminé.
• ✅ Reproduisez les notices d'attribution si vous redistribuez du contenu.
• ✅ Gardez SecCheck comme une couche parmi d'autres — associez-le à la revue, aux tests et à vos contrôles existants.