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 émises par client par votre équipe de compte Cert-IX. 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 pas conservé en tant que document stocké.
Un identifiant d'avis / de CVE	Recherche son détail ou son renseignement d'exploitation.

DepCheck extrait des coordonnées (quels paquets, quelles versions) d'un manifeste — 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é

C'est le point qui compte pour une posture souveraine :

• Les données d'avis de sécurité sont servies en premier depuis le miroir d'avis souverain Cert-IX (osv-advisories) hébergé à l'intérieur du cluster Cert-IX, enrichi du renseignement d'exploitation CISA KEV et EPSS provenant des propres index du cluster. Lors d'une correspondance dans le miroir — le cas courant — votre consultation ne quitte jamais l'infrastructure Cert-IX.
• Repli en direct : si le miroir n'a pas de réponse (un avis très récent, ou un paquet que le miroir n'a pas encore indexé), DepCheck se replie sur l'API publique osv.dev pour l'exactitude. suggest_safe_version utilise en outre deps.dev pour énumérer les versions d'un paquet. Dans ces cas de repli, la coordonnée de paquet (ecosystem, name et version) est envoyée à ce service public pour résoudre la réponse.
• Ce qui n'est jamais envoyé à un tiers : votre manifeste en tant que document, votre code source, votre clé d'API ou votre identité. Seule la coordonnée minimale nécessaire pour répondre à une consultation est transmise, et uniquement en cas d'absence dans le miroir.

Zéro appel externe souhaité ?

Exécutez DepCheck localement via stdio contre le miroir souverain (ou un instantané hors ligne). Dans cette configuration, les consultations sont résolues contre le miroir sans trafic de repli public — adapté aux environnements isolés (air-gapped) ou à haute assurance. 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 et se trouve sur un réseau Docker dédié à un seul service — les autres services de la plateforme ne peuvent pas l'atteindre directement, et lui ne peut pas les atteindre.
• 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 souverain d'abord » maintient par défaut l'activité de vérification des dépendances à l'intérieur de l'infrastructure UE/Cert-IX, avec un repli public limité à la coordonnée minimale nécessaire à l'exactitude.

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, contactez votre équipe de compte Cert-IX au sujet d'un déploiement dédié ou entièrement hors ligne.

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.