{"id":2181,"date":"2026-03-18T08:48:29","date_gmt":"2026-03-18T08:48:29","guid":{"rendered":"https:\/\/www.almtoolbox.com\/fr\/blog\/?p=2181"},"modified":"2026-03-19T09:14:22","modified_gmt":"2026-03-19T09:14:22","slug":"jfrog-curation-self-managed","status":"publish","type":"post","link":"https:\/\/www.almtoolbox.com\/fr\/blog\/jfrog-curation-self-managed\/","title":{"rendered":"JFrog Curation pour les environnements ferm\u00e9s : comment bloquer les paquets malveillants avant qu’ils n’int\u00e8grent le code"},"content":{"rendered":"\n

Les entreprises modernes construisent presque tous leurs produits sur la base de code open source et de d\u00e9pendances tierces. Cela acc\u00e9l\u00e8re le d\u00e9veloppement, mais introduit \u00e9galement une dimension de risque : paquets malveillants (malwares), versions pr\u00e9sentant des failles de s\u00e9curit\u00e9 critiques, probl\u00e8mes de licences, ou encore des d\u00e9pendances immatures et non maintenues.<\/p>\n\n\n\n

\"jfrog<\/figure>\n\n\n\n
\n
<\/figure>\n<\/div>\n\n\n\n

Dans la plupart des cas, les outils de s\u00e9curit\u00e9 traditionnels n’analysent le composant qu’apr\u00e8s<\/span> son int\u00e9gration dans le repository, le build ou le pipeline.<\/p>\n\n\n\n

C’est pr\u00e9cis\u00e9ment l\u00e0 qu’intervient JFrog Curation<\/strong> : au lieu de d\u00e9couvrir a posteriori qu’un composant dangereux a d\u00e9j\u00e0 p\u00e9n\u00e9tr\u00e9 l’entreprise,
JFrog Curation agit au moment de la demande et du t\u00e9l\u00e9chargement du paquet, et bloque les composants probl\u00e9matiques avant m\u00eame qu’ils ne fassent partie du code, du build ou de l’application.<\/p>\n\n\n\n

Qu’est-ce que JFrog Curation Package et que propose-t-il ?<\/h2>\n\n\n\n

JFrog Curation<\/strong> est une couche de gouvernance (governance) et d’application de politiques pour la consommation de paquets open source et de d\u00e9pendances tierces. On peut le consid\u00e9rer comme une “porte d’entr\u00e9e” pour les paquets externes : au lieu de laisser chaque d\u00e9pendance s’int\u00e9grer automatiquement \u00e0 l’environnement, l’entreprise d\u00e9finit des r\u00e8gles qui d\u00e9terminent quels paquets peuvent \u00eatre t\u00e9l\u00e9charg\u00e9s, lesquels doivent \u00eatre bloqu\u00e9s, et lesquels n\u00e9cessitent une v\u00e9rification suppl\u00e9mentaire.<\/p>\n\n\n\n

La solution permet, entre autres :<\/strong><\/p>\n\n\n\n

    \n
  1. De bloquer les paquets identifi\u00e9s comme malveillants.<\/li>\n\n\n\n
  2. De bloquer les versions pr\u00e9sentant des failles de s\u00e9curit\u00e9 en fonction de leur criticit\u00e9 ou de la politique de l’entreprise.<\/li>\n\n\n\n
  3. D’appliquer les politiques de licences.<\/li>\n\n\n\n
  4. De limiter l’utilisation de paquets obsol\u00e8tes, immatures ou non maintenus.<\/li>\n\n\n\n
  5. De mettre en place des listes d’autorisation (allowlist) et des listes de blocage (blocklist) selon les besoins de l’entreprise.<\/li>\n\n\n\n
  6. De g\u00e9n\u00e9rer une piste d’audit (audit trail) structur\u00e9e pour chaque d\u00e9cision de blocage ou d’approbation.<\/li>\n<\/ol>\n\n\n\n

    La valeur ajout\u00e9e pour l’entreprise est claire : moins de d\u00e9pendance aux d\u00e9cisions manuelles, moins de risques d’introduire des composants dangereux et un meilleur contr\u00f4le sur la cha\u00eene d’approvisionnement logicielle (software supply chain).<\/p>\n\n\n\n

    Comment JFrog Curation fonctionne-t-il dans un environnement auto-h\u00e9berg\u00e9 (Self-Hosted \/ Self-Managed) ?<\/h2>\n\n\n\n

    Dans les environnements sur site (on-premises) ou auto-h\u00e9berg\u00e9s g\u00e9r\u00e9s de mani\u00e8re autonome, JFrog Curation s’int\u00e8gre \u00e0 la plateforme JFrog, et plus particuli\u00e8rement \u00e0 Artifactory et Xray.<\/p>\n\n\n\n

    Le mod\u00e8le est relativement simple :<\/strong><\/p>\n\n\n\n

      \n
    1. Les d\u00e9veloppeurs t\u00e9l\u00e9chargent des paquets via Artifactory (lors des builds, etc.).<\/li>\n\n\n\n
    2. JFrog Curation v\u00e9rifie la requ\u00eate par rapport aux politiques de l’entreprise.<\/li>\n\n\n\n
    3. Si le paquet respecte les conditions (policies), son t\u00e9l\u00e9chargement est autoris\u00e9.<\/li>\n\n\n\n
    4. Si le paquet enfreint la politique, l’acc\u00e8s est bloqu\u00e9 avant que le composant n’int\u00e8gre l’environnement.<\/li>\n<\/ol>\n\n\n\n

      En d’autres termes, au lieu de se contenter d’une analyse post-t\u00e9l\u00e9chargement, l’entreprise b\u00e9n\u00e9ficie d’un m\u00e9canisme de pr\u00e9vention (prevention<\/strong>) d\u00e8s la phase d’entr\u00e9e.<\/p>\n\n\n\n

      Il s’agit d’un changement fondamental : moins de “nettoyage a posteriori”, plus de pr\u00e9vention en amont.<\/p>\n\n\n\n

      Que se passe-t-il concr\u00e8tement lors d’une requ\u00eate de paquet ?<\/h3>\n\n\n\n

      Lorsqu’un d\u00e9veloppeur, un pipeline ou un build demande une d\u00e9pendance via un repository d’entreprise, le syst\u00e8me v\u00e9rifie si le paquet :<\/p>\n\n\n\n