JFrog Artifactory : sécuriser sa chaîne de dépendances logicielle

En 2021, l’attaque SolarWinds a montré qu’une compromission de la chaîne de build pouvait toucher des milliers d’organisations. Depuis, la sécurisation de la supply chain logicielle est passée du statut de bonne pratique à celui d’exigence. JFrog Artifactory est l’un des outils centraux de cette démarche.

Pourquoi la chaîne de dépendances est une surface d’attaque

Votre application dépend de dizaines de bibliothèques tierces, qui dépendent elles-mêmes d’autres bibliothèques. Un projet Node.js typique embarque plusieurs centaines de packages transitifs. Chacun est un vecteur potentiel :

CVE dans une dépendance — une vulnérabilité connue non patchée
Dependency confusion — un package malveillant publié sur un registre public avec le même nom qu’un package interne
Typosquatting — reqeusts à la place de requests
Package hijacking — prise de contrôle d’un package légitime par un acteur malveillant

Artifactory ne résout pas tout, mais il élimine la plupart de ces risques en devenant le seul point de passage entre Internet et vos builds.

Artifactory comme proxy universel

La première ligne de défense : faire transiter toutes vos dépendances par Artifactory, sans exception.

# Maven — settings.xml
<mirror>
  <id>artifactory-central</id>
  <mirrorOf>*</mirrorOf>
  <url>https://artifactory.example.com/artifactory/maven-virtual/</url>
</mirror>

# npm — .npmrc
registry=https://artifactory.example.com/artifactory/api/npm/npm-virtual/

# pip — pip.conf
[global]
index-url = https://artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple/

# Docker — daemon.json
{
  "registry-mirrors": ["https://artifactory.example.com/docker-hub"]
}

Avec cette configuration, vos builds ne touchent jamais directement npmjs.com, PyPI ou Docker Hub. Tout passe par Artifactory — ce qui signifie que tout peut être audité, scanné et bloqué si nécessaire.

Xray : le scanner de sécurité intégré

JFrog Xray scanne les artefacts stockés dans Artifactory en temps réel. Il s’appuie sur plusieurs bases de données de vulnérabilités (CVE, NVD, VulnDB) et analyse les dépendances transitives — pas seulement les dépendances directes.

Politique Xray : "Bloquer les critiques"
Condition   : CVE avec CVSS ≥ 9.0
Action      : Bloquer le téléchargement + notifier le canal #security-alerts

Quand un développeur tente d’utiliser log4j-2.14.1 (Log4Shell, CVSS 10.0), Xray bloque le téléchargement depuis Artifactory avant même que le package n’entre dans le build.

Politique de curation : approuver avant d’utiliser

La fonctionnalité Curation permet d’implémenter un processus d’approbation pour les nouvelles dépendances :

Règles automatiques de curation :
- Âge minimum du package : 7 jours (éviter les packages très récents non validés)
- Score de réputation minimum : 70/100 (basé sur JFrog Security Research)
- Zéro CVE critique ou haute
- Pas de licence incompatible (GPL dans un projet propriétaire)

Un package qui ne satisfait pas ces critères est mis en quarantaine automatiquement. Un responsable sécurité peut l’approuver manuellement avec une justification.

Défense contre la Dependency Confusion

La Dependency Confusion est une attaque qui exploite la priorité des registres publics sur les registres privés dans certaines configurations. La solution Artifactory :

Dépôt Virtual "maven-virtual" :
  Ordre de résolution :
  1. maven-local (dépôt interne — priorité absolue)
  2. maven-central-remote (proxy Maven Central)

Règle : si un package existe en local, il ne peut pas être écrasé par un package public

Avec cette configuration, com.monentreprise:mon-module sera toujours résolu depuis le dépôt interne, même si quelqu’un publie un package avec le même nom sur Maven Central.

SBOM : inventorier ce que vous livrez

Le SBOM (Software Bill of Materials) est devenu une exigence réglementaire dans certains secteurs (défense, énergie, santé). Artifactory génère des SBOM au format SPDX ou CycloneDX à partir des Build Info :

# Générer un SBOM pour un build spécifique
jfrog rt build-scan myapp 42 --format=spdx

Le résultat liste toutes les dépendances directes et transitives utilisées dans le build, avec leur version, leur licence et leur statut de vulnérabilité au moment du build. C’est la traçabilité complète de ce qui entre dans votre logiciel.

Intégration dans le pipeline : scanner au bon moment

# GitLab CI avec JFrog CLI
build-and-scan:
  stage: build
  script:
    # Build et push de l'image
    - docker build -t $REGISTRY/myapp:$CI_COMMIT_SHA .
    - jfrog rt docker-push $REGISTRY/myapp:$CI_COMMIT_SHA docker-local
      --build-name=$CI_PROJECT_NAME --build-number=$CI_PIPELINE_IID
    # Publication des Build Info
    - jfrog rt build-publish $CI_PROJECT_NAME $CI_PIPELINE_IID
    # Scan Xray — bloque si vulnérabilité critique détectée
    - jfrog rt build-scan $CI_PROJECT_NAME $CI_PIPELINE_IID --fail=true

--fail=true arrête le pipeline si Xray détecte une vulnérabilité correspondant aux politiques de sécurité configurées. L’image ne peut pas être promue vers la production.

La promotion comme validation finale

# Promouvoir de staging vers production uniquement si le scan est propre
jfrog rt build-promote $CI_PROJECT_NAME $CI_PIPELINE_IID \
  --source-repo=docker-staging \
  --target-repo=docker-prod \
  --status=Released \
  --comment="Scan Xray : aucune CVE critique. Approuvé par $APPROVER"

La promotion est la dernière barrière avant production. L’image n’est pas re-buildée — elle est copiée avec sa traçabilité complète. Si elle a passé Xray en staging, elle est garantie identique en production.

Notre formation Artifactory couvre l’ensemble de cette démarche, du proxy universel au scanning Xray, sur des environnements de lab réels.