Sécurité et traitement des données

📄 Vous préférez hors ligne ? Téléchargez ce guide au format PDF.

DepCheck est un outil de sécurité, il est donc tenu aux normes d'un outil de sécurité. Cette page indique clairement comment il vous authentifie, ce qu'il fait des données que vous lui envoyez, et ce qui sort — ou ne sort pas — du périmètre Cert-IX.

Authentification

• Chaque requête vers https://mcp.cert-ix.com/depcheck doit porter une clé d'API valide sous la 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/depcheck-mcp, confirmez votre adresse e-mail, et la clé vous parvient par e-mail. Une clé 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 source, et effectuez sa rotation si elle a pu fuiter.
• Tout le trafic passe par TLS. N'envoyez pas de clés ni de manifestes en HTTP non chiffré.

Limites de débit et protection contre les abus

L'endpoint hébergé applique des limites à la périphérie (host nginx), avant tout traitement :

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

Le dépassement d'une limite renvoie 429 Too Many Requests — patientez et réessayez. Ces plafonds sont largement au-dessus de l'usage normal d'un agent (quelques vérifications par édition) ; ils existent pour arrêter les afflux massifs, pas pour freiner le travail réel.

Les échecs d'authentification répétés sont traités comme des abus : une IP qui produit de nombreux 401 en peu de temps est temporairement bloquée (fail2ban). Un détenteur de clé valide n'atteint jamais ce seuil, car une clé correcte ne renvoie jamais de 401.

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

Les outils de DepCheck sont des consultations en lecture seule. Voici exactement à quoi sert chaque type d'entrée :

Vous envoyez	Ce que DepCheck en fait
Une coordonnée de paquet (ecosystem, name, version)	La recherche par rapport aux données d'avis de sécurité et renvoie les avis correspondants.
Un corps de manifeste (manifest_content)	Le parse en mémoire pour extraire les paires nom/version de paquet, puis les recherche. Il sert à produire votre résultat et n'est ni stocké ni journalisé par DepCheck.
Un identifiant d'avis / de CVE	Recherche son détail ou son renseignement d'exploitation.

Le manifeste lui-même parvient bien au serveur Cert-IX — le scan_dependencies hébergé reçoit son texte dans la requête — mais il ne va pas plus loin : DepCheck en extrait des coordonnées (quels paquets, quelles versions) et recherche celles-ci. Il n'a pas besoin de votre code source, ne le veut pas et ne l'analyse pas, et le serveur hébergé n'a aucun accès à votre système de fichiers (c'est pourquoi il prend un texte de manifeste, pas un chemin).

Quelles données opérationnelles sont conservées

Pour faire fonctionner le service, DepCheck ne conserve que des compteurs agrégés — total des requêtes, erreurs, nombre en cours de traitement, et décomptes d'appels par outil / par client à des fins de capacité et de supervision. Ces compteurs enregistrent le fait qu'un client a appelé un outil, pas les noms de paquets, les versions ni le contenu du manifeste dans l'appel. Ils sont exposés sur un endpoint /metrics interne et protégé par jeton, qui n'est jamais joignable depuis l'internet public.

Résidence des données — où résident les données d'avis de sécurité

DepCheck fonctionne d'abord sur le miroir, pas uniquement sur le miroir. Il répond depuis l'infrastructure Cert-IX quand il le peut, et reste exact quand il ne le peut pas :

• Le miroir d'abord. Les consultations d'avis sont servies en premier depuis la copie des données d'avis OSV propre à Cert-IX, enrichie du renseignement d'exploitation CISA KEV et EPSS provenant des propres index de Cert-IX. Lorsque le miroir peut répondre, la consultation est résolue sur l'infrastructure Cert-IX.
• Repli sur osv.dev. Lorsque le miroir ne peut pas répondre avec certitude — l'écosystème du paquet n'est pas couvert, le miroir dépasse sa limite d'ancienneté, un avis ne peut pas être rapproché avec certitude, ou le miroir renvoie une erreur — DepCheck interroge à la place l'API publique osv.dev, plutôt que de déclarer « sain » à partir de données auxquelles il ne peut pas se fier. get_advisory fait de même pour un identifiant d'avis absent du miroir.
• Listes de versions depuis deps.dev. suggest_safe_version lit la liste des versions d'un paquet via l'API publique deps.dev à chaque appel (les réponses sont mises en cache en mémoire pendant une heure), puis vérifie les versions candidates comme ci-dessus.
• Ce que reçoivent ces services. osv.dev et deps.dev sont exploités par Google, aux États-Unis. Ils reçoivent une coordonnée de paquet — écosystème, nom et, pour osv.dev, version — ou, pour get_advisory, l'identifiant de l'avis. Votre fichier manifeste, votre code source, votre clé d'API et votre identité ne sont pas transmis.
• Noms de paquets privés. Si un manifeste ou un appel à check_package nomme des paquets privés ou internes, ces noms peuvent parvenir à osv.dev par le chemin de repli. Tenez les noms de paquets confidentiels à l'écart des appels à DepCheck.

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.

Pas de mode sans trafic sortant aujourd'hui

Aucune configuration de DepCheck ne garantit l'absence totale d'appels externes. Une instance stdio locale interroge directement osv.dev, sauf si elle a accès à un miroir Cert-IX, et suggest_safe_version lit toujours les listes de versions sur deps.dev. Voir Démarrage → Option 2.

Posture réseau (hébergé)

• L'endpoint est placé derrière host nginx, qui constitue l'unique point d'entrée et assure l'authentification, la limitation de débit et la terminaison TLS.
• Le conteneur DepCheck est publié uniquement sur le loopback de l'hôte : il n'est joignable depuis l'internet qu'à travers ce nginx.
• L'endpoint MCP (/depcheck) est le seul chemin exposé publiquement. Les chemins opérationnels (/metrics, santé) sont internes uniquement.

Notes de conformité

• DepCheck traite des coordonnées de paquets et des identifiants d'avis de sécurité — des métadonnées techniques, pas des données personnelles. Un manifeste que vous soumettez est parsé de manière transitoire pour en extraire ces coordonnées et n'est pas conservé en tant que document stocké.
• Les clés d'API identifient un client/une organisation, utilisées pour le contrôle d'accès et la comptabilisation agrégée du débit — pas pour du profilage.
• La conception « miroir d'abord » maintient les consultations sur l'infrastructure Cert-IX chaque fois que le miroir peut répondre. Elle ne garantit pas que chaque consultation y reste : les consultations de repli et les listes de versions de suggest_safe_version partent vers osv.dev et deps.dev, avec les seules coordonnées de paquet.

Si vous avez besoin d'un avenant de traitement des données pour une charge de travail réglementée, ou d'engagements de résidence allant au-delà de ce que décrit cette page, contactez votre équipe de compte Cert-IX.

Liste de contrôle des bonnes pratiques

• ✅ Stockez la clé d'API dans la configuration secrète de votre client MCP, pas dans le dépôt.
• ✅ Effectuez la rotation de la clé lors des changements de personnel ou en cas de suspicion d'exposition.
• ✅ Analysez les lockfiles pour connaître la vérité installée, pas seulement les manifestes avec des plages de versions.
• ✅ Réanalysez périodiquement — « propre aujourd'hui » n'est pas « propre pour toujours ».
• ✅ Corrigez d'abord les résultats marqués exploited (voir Référence des outils → get_cve_intel).
• ✅ Gardez DepCheck comme une couche parmi d'autres — associez-le à la revue, au SAST et au moindre privilège.