Project Glasswing : quand les géants tech jouent aux pompiers du code

Imaginez un monde où votre modèle d'IA préféré plante parce qu'un paquet npm obscur, utilisé par une dépendance de dépendance, s'est fait pirater. Bienvenue dans la réalité de 2024. Project Glasswing, porté par Anthropic et une brochette de mastodontes (AWS, Google, Microsoft, NVIDIA...), prétend résoudre ce problème en sécurisant la supply chain logicielle. Spoiler : c'est plus compliqué qu'un npm audit fix.

Les fondements : pourquoi tout ça ?

Le problème des dépendances transitives (ou comment se faire avoir sans le savoir)

Votre projet Python moyen dépend de 80 paquets. Ces paquets dépendent eux-mêmes de 400 autres paquets. Et ces 400 paquets ? Environ 2000 dépendances transitives, selon une étude de Synopsys. Le pire ? 90% des vulnérabilités viennent de ces dépendances indirectes que personne ne surveille.

Exemple concret : en 2021, le paquet ua-parser-js (utilisé par des millions de projets) s'est fait injecter du code malveillant. Résultat : des backdoors dans des applications bancaires, des dashboards cloud, et même des outils de santé. Le tout sans que les devs aient touché une ligne de leur code.

Project Glasswing attaque ce problème à la racine : comment vérifier que le code que vous utilisez est bien celui que vous pensez utiliser ?

La solution proposée : un triptyque cryptographique

1. Des artefacts signés : Chaque version d'un paquet critique est signée par son mainteneur, avec une clé vérifiable.
2. Un registre immuable : Les métadonnées (hashes, signatures) sont stockées dans un registre distribué type blockchain (mais sans les tokens et le hype).
3. Des builds reproductibles : Deux builds du même code doivent produire exactement le même binaire. Sinon, c'est louche.

En théorie, ça ressemble à ce que fait Sigstore depuis des années. Sauf que Glasswing vise spécifiquement les dépendances critiques pour l'IA : compilateurs, bibliothèques maths, frameworks ML.

L'implémentation : Rust, WASM et des compromis douloureux

Le choix de Rust (parce que C++ c'est trop dangereux)

Le cœur de Glasswing est écrit en Rust. Pourquoi ? Parce que :

• Pas de garbage collector → Moins de surprises en prod.
• Gestion mémoire stricte → Moins de vulnérabilités type buffer overflow.
• Compilation vers WASM → Exécutable dans des environnements sandboxés (navigateur, enclaves cloud).

Exemple de code pour vérifier une signature (simplifié) :

use ring::signature;
use std::fs;

fn verify_signature(public_key: &[u8], message: &[u8], signature: &[u8]) -> bool {
    let key = signature::UnparsedPublicKey::new(&signature::RSA_PKCS1_2048_8192_SHA256, public_key);
    key.verify(message, signature).is_ok()
}

fn main() {
    let public_key = fs::read("maintainer.pub").expect("Failed to read key");
    let package_hash = fs::read("package.sha256").expect("Failed to read hash");
    let signature = fs::read("package.sig").expect("Failed to read signature");

    if verify_signature(&public_key, &package_hash, &signature) {
        println!("Package verified!");
    } else {
        eprintln!("INTRUSION DETECTED. ABORT.");
    }
}

L'intégration avec les outils existants

Glasswing ne réinvente pas la roue. Il s'intègre à :

• npm/yarn/pip via des plugins de vérification.
• Docker pour vérifier les images de base.
• CI/CD (GitHub Actions, GitLab CI) avec des steps dédiés.

Exemple de workflow GitHub Actions :

name: Verify Dependencies
on: [push, pull_request]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: glasswing-io/verify-action@v1
        with:
          token: {{ secrets.GLASSWING_TOKEN }}
          fail-on: "critical,vulnerable"

Le casse-tête des builds reproductibles

En théorie, deux builds du même code devraient produire le même binaire. En pratique, même la date de compilation peut changer le hash final. Glasswing impose :

• Des conteneurs de build standardisés (mêmes versions de compilateurs, mêmes flags).
• Des timestamps fixes.
• Une validation croisée entre plusieurs environnements.

Résultat : Un paquet validé par Glasswing a 99,9% de chances d'être identique à celui utilisé par Anthropic ou Google. Les 0,1% restants ? Bonne chance pour les déboguer.

Benchmarks : ça coûte cher, mais est-ce que ça marche ?

Performance vs. Sécurité : le trade-off habituel

Métrique	Sans Glasswing	Avec Glasswing	Overhead
Temps d'install (npm)	4.2s	8.7s	+107%
Taille des métadonnées	12KB	45KB	+275%
Latence vérification	N/A	300ms	N/A

Source : Tests internes Anthropic (2024)

Oui, c'est plus lent. Mais comme le dit un ingé chez Google : "Si votre pipeline CI met 2 minutes de plus mais évite un SolarWinds 2.0, c'est un bon deal."

Détection des intrusions : efficace, mais pas magique

Glasswing a été testé sur des scénarios réels :

1. Dependency confusion (un paquet malveillant usurpe le nom d'un paquet interne) → Détecté en 120ms.
2. Typosquatting (lodashs au lieu de lodash) → Bloqué à l'install.
3. Compromission d'un mainteneur (clé privée volée) → Détecté après 3h (le temps que les registres se synchronisent).

Comparaison avec les outils existants :

Outil	Détection Dependency Confusion	Typosquatting	Compromission Mainteneur	Builds Reproductibles
npm audit	❌ No	✅ Yes	❌ No	❌ No
Sigstore	✅ Yes	✅ Yes	⚠️ Partiel	❌ No
Project Glasswing	✅ Yes	✅ Yes	✅ Yes (avec délai)	✅ Yes

Les limitations : parce que rien n'est parfait

1. Le problème des mainteneurs fantômes

Glasswing repose sur la confiance dans les mainteneurs de paquets. Sauf que 60% des paquets npm critiques sont maintenus par des bénévoles (source : Socket.dev).

Scénario catastrophe :

• Un mainteneur abandonne son paquet.
• Quelqu'un fork le projet et publie une version malveillante sous le même nom.
• Glasswing détecte la nouvelle signature... mais qui décide si elle est légitime ?

Anthropic propose une solution : un comité de validation (avec AWS, Google, etc.). Problème : Ça centralise le pouvoir entre quelques acteurs. "On remplace un problème de sécurité par un problème de gouvernance", râle un ingé chez Red Hat.

2. La compatibilité rétroactive (ou l'enfer des legacy systems)

Glasswing fonctionne bien avec les nouveaux projets. Mais que faire des systèmes existants ?

• Option 1 : Tout rebuilder avec Glasswing. Coût estimé pour une entreprise moyenne ? 6 mois-homme.
• Option 2 : Ne sécuriser que les nouvelles dépendances. Risque ? Laisser des portes dérobées ouvertes.

Exemple : Une banque utilisant TensorFlow 1.x (oui, ça existe encore) devra soit :

• Migrer vers TF 2.x (avec Glasswing).
• Prier pour que personne ne trouve de vulnérabilité dans son ancien setup.

3. Le coût caché : quand la sécurité devient un luxe

Glasswing est open-source, mais l'infrastructure de vérification ne l'est pas.

• Coût estimé pour une entreprise : ~$50k/an (pour les outils premium).
• Coût réel : "Ajoutez 20% pour la formation des devs et les ralentissements de CI", selon un CTO anonyme.

"C'est comme acheter une Ferrari pour aller faire ses courses : techniquement impressionnant, mais est-ce que ça vaut le coup ?", résume un ingé chez OVH.

Recherche & évolutions : vers une supply chain 100% vérifiable ?

1. L'intégration avec les LLMs (parce que l'IA aussi a des dépendances)

Les modèles comme Claude ou Gemini dépendent de centaines de bibliothèques (PyTorch, JAX, CUDA...). Glasswing travaille sur :

• Un système de "proof of training" : Vérifier que le modèle a bien été entraîné avec les données déclarées.
• Des enclaves sécurisées pour les poids des modèles (via AWS Nitro Enclaves).

Problème : "Comment vérifier que les données d'entraînement n'ont pas été empoisonnées ?", demande un chercheur chez Hugging Face. Réponse d'Anthropic : "On y travaille." (Traduction : "On n'en a aucune idée.")

2. Vers une standardisation ? (Ne rêvez pas trop)

Glasswing pousse pour que ses protocoles deviennent des standards via :

• L'IETF (pour la partie crypto).
• La Linux Foundation (pour l'intégration avec les distros).

Réalité : Les géants tech adorent les standards... tant qu'ils les contrôlent. "On va se retrouver avec 3 standards incompatibles : un pour Google, un pour Microsoft, un pour la Chine", prédit un observateur.

3. L'éléphant dans la pièce : et si le problème était ailleurs ?

Glasswing sécurise les dépendances. Mais 80% des failles viennent de :

• Mauvaises configurations (ex : un bucket S3 en public).
• Creds hardcodées (oui, en 2024, ça arrive encore).
• Logique métier défaillante (ex : une IA qui approuve tous les prêts immos).

"C'est comme mettre une alarme ultra-sophistiquée sur sa porte d'entrée... et laisser la fenêtre ouverte", résume un pentester.

FAQ

[Project Glasswing est-il compatible avec les projets existants ?] Oui, mais avec des limitations. Les nouveaux projets peuvent l'adopter facilement. Pour les legacy systems, préparez-vous à des migrations douloureuses ou à une couverture partielle. Priorisez les dépendances critiques (compilateurs, bibliothèques crypto) avant de tout migrer.

[Combien coûte vraiment l'adoption de Glasswing ?] Le code est open-source, mais l'infrastructure de vérification a un coût. Comptez 30k-100k/an selon la taille de votre org, plus le temps d'intégration (2-6 mois pour une entreprise moyenne). Le ROI ? Difficile à calculer... jusqu'à ce qu'une faille vous coûte $10M.

[Glasswing peut-il empêcher une attaque comme SolarWinds ?] En théorie, oui. SolarWinds reposait sur une compromission de la chaîne de build. Glasswing vérifie les builds et les signatures, ce qui aurait détecté l'intrusion. En pratique, rien n'est infaillible : si un attaquant compromise toutes les clés de signature, c'est fichu. Mais c'est déjà bien plus robuste que l'existant.