Fuite de code source chez Anthropic : ce que vos pipelines CI/CD doivent absolument vérifier

Fin mars 2026, Anthropic a involontairement exposé le code source de son outil Claude Code via un package npm publié avec une source map non obfusquée. En quelques heures, le code avait été archivé sur GitHub et forké plus de 41 500 fois. Un incident qui aurait pu arriver à n'importe quelle équipe de développement — y compris la vôtre.

Source : The Register

Ce qui s'est passé : une source map de trop

Le problème est d'une simplicité déconcertante. Le package npm de Claude Code embarquait un fichier .map (source map) faisant référence au code TypeScript original non obfusqué. Les source maps sont des fichiers de débogage qui établissent la correspondance entre le code minifié/bundlé livré en production et le code source d'origine. Elles sont indispensables en développement, mais elles n'ont aucune place dans un artefact publié publiquement.

Le chercheur en sécurité Chaofan Shou a détecté l'exposition et l'a rendue publique. La réaction de la communauté a été immédiate : archivage, forks massifs, dissémination irréversible. Une fois un secret exposé sur internet, il est impossible de le rappeler.

Ce type d'erreur n'est pas une négligence grossière : c'est un angle mort classique des pipelines de build automatisés, où personne ne vérifie précisément ce que contient l'artefact final avant publication.

Checklist opératoire : sécurisez votre pipeline CI/CD

Voici les contrôles concrets à intégrer dans vos pipelines, que vous publiiez un package npm, un bundle JavaScript ou une image Docker.

1. Détecter et retirer les source maps avant publication

La première ligne de défense est de s'assurer que vos source maps ne partent jamais en production publique.

Dans votre configuration de build (webpack, esbuild, Vite) :

// webpack.config.js — désactiver les source maps en production
module.exports = {
  devtool: process.env.NODE_ENV === 'production' ? false : 'source-map',
};

Audit automatisé dans votre pipeline CI :

# Vérifier l'absence de fichiers .map dans le répertoire de sortie
if find ./dist -name "*.map" | grep -q .; then
  echo "[ERREUR] Des source maps ont été détectées dans dist/ — publication bloquée."
  exit 1
fi

Ajoutez ce contrôle comme étape bloquante avant toute étape de déploiement ou de publication.

2. Inspecter le contenu du package avant npm publish

L'une des erreurs les plus courantes est de ne jamais regarder ce que npm publish va réellement envoyer. La commande npm pack génère localement l'archive .tgz sans la publier, ce qui permet un audit complet.

# Générer l'archive sans publier
npm pack --dry-run

# Ou inspecter le contenu de l'archive générée
npm pack
tar -tzf nom-du-package-*.tgz | sort

Intégrez cette étape dans votre CI pour déclencher une alerte si des fichiers inattendus (.map, .env, fichiers de config internes) apparaissent dans la liste.

Vérifiez également votre fichier .npmignore ou le champ files dans package.json :

{
  "files": [
    "dist/",
    "README.md"
  ]
}

Une liste blanche explicite via files est plus sûre qu'une liste noire via .npmignore.

3. Signer vos artefacts et générer un SBOM

La signature cryptographique de vos artefacts permet à vos utilisateurs de vérifier l'intégrité et l'authenticité de ce qu'ils téléchargent.

Avec Sigstore/cosign pour un package ou une image :

# Signer une image Docker
cosign sign --key cosign.key votre-registry/votre-image:tag

# Vérifier la signature
cosign verify --key cosign.pub votre-registry/votre-image:tag

En parallèle, générez un SBOM (Software Bill of Materials) pour chaque release. C'est une liste exhaustive de toutes les dépendances embarquées, qui facilite la détection rapide lors de futures vulnérabilités.

# Générer un SBOM au format CycloneDX avec Syft
syft packages dir:./dist -o cyclonedx-json > sbom.json

Publiez ce SBOM avec votre release. En cas d'incident de sécurité, vos utilisateurs pourront immédiatement évaluer leur exposition.

4. Scanner les dépendances avec Snyk ou Dependabot

Une supply chain sécurisée ne concerne pas uniquement ce que vous publiez, mais aussi ce que vous embarquez.

Dependabot (natif GitHub) surveille automatiquement vos package.json et ouvre des pull requests pour les mises à jour de sécurité.

Snyk offre un scan plus approfondi, y compris dans le code lui-même :

# Installation et scan
npm install -g snyk
snyk auth
snyk test
snyk monitor

Intégrez ces scans dans votre pipeline CI de façon à bloquer le merge si une vulnérabilité critique est détectée.

5. Isoler les expérimentations IA en environnements éphémères

L'incident Anthropic soulève une question supplémentaire : les outils d'IA (Claude Code, GitHub Copilot, Cursor...) utilisés en développement peuvent accéder à votre code source et à vos configurations. Quelques bonnes pratiques :

• Ne jamais donner accès à des secrets réels (clés API, credentials de base de données) dans les environnements utilisés avec des assistants IA.
• Utiliser des environnements éphémères (conteneurs Docker jetables, environnements de sandbox) pour les expérimentations, détruits après usage.
• Auditer les permissions accordées aux extensions et plugins IA dans vos IDE.
• Traiter les outputs générés par l'IA comme du code non vérifié : revue de code systématique avant merge.

# Exemple de job CI éphémère avec GitHub Actions
jobs:
  ai-experiment:
    runs-on: ubuntu-latest
    container:
      image: node:22-alpine
    env:
      # Utiliser des secrets de test, jamais de production
      API_KEY: ${{ secrets.TEST_API_KEY }}
    steps:
      - uses: actions/checkout@v4
      - name: Run experiment
        run: npm run experiment
      # L'environnement est détruit automatiquement après le job

Conclusion : l'automatisation sans vérification est une dette de sécurité

L'incident Anthropic est un rappel que même les équipes les plus expérimentées peuvent laisser passer des fichiers sensibles dans un artefact de production. La vitesse de déploiement moderne, combinée à des pipelines CI/CD complexes, crée des angles morts que seule une vérification systématique et automatisée peut combler.

Les cinq points de cette checklist — retrait des source maps, inspection du package avant publication, signature et SBOM, scan des dépendances, isolation des environnements IA — ne sont pas des mesures extraordinaires. Ce sont des pratiques de base que chaque équipe de développement PHP/Symfony ou JavaScript devrait avoir intégrées dans son workflow.

Commencez par l'étape la plus simple : lancez npm pack --dry-run sur votre prochain package et examinez attentivement la liste des fichiers inclus. Vous pourriez avoir une surprise.