Sécurité des pipelines : quelles leçons tirer des attaques de la chaîne d'approvisionnement de mars 2026 ?

Remarque : le produit GitLab n'a utilisé aucune des versions de paquets compromises mentionnées dans cet article.

En l'espace de 12 jours, quatre attaques distinctes de la chaîne d'approvisionnement ont démontré que les pipelines d'intégration et de déploiement continus (CI/CD) sont devenus une cible de choix pour les acteurs malveillants les plus sophistiqués.

Entre le 19 et le 31 mars 2026, des acteurs malveillants ont compromis :

• Un scanner de sécurité open source (Trivy)
• Un scanner de sécurité d'Infrastructure as Code (IaC) (Checkmarx KICS)
• Une passerelle de modèles d'IA (LiteLLM)
• Un client HTTP JavaScript (axios)

Chaque attaque ciblait la même surface : le pipeline de build. Cet article décrit les faits, pourquoi les pipelines peuvent être particulièrement vulnérables, et comment l'application centralisée de politiques avec GitLab, grâce aux politiques décrites ci-dessous, peut bloquer, détecter et contenir ces catégories d'attaques avant qu'elles n'atteignent l'environnement de production.

Des outils adoptés par des millions d'utilisateurs, compromis en quelques minutes

Voici la chronologie des attaques de la chaîne d'approvisionnement :

19 mars : le scanner de sécurité Trivy devient un vecteur d'attaque

Trivy est l'un des scanners de vulnérabilités open source les plus utilisés au monde. C'est l'outil que les équipes exécutent à l'intérieur de leurs pipelines pour détecter les vulnérabilités.

Le 19 mars, un groupe d'acteurs malveillants connu sous le nom de TeamPCP a utilisé des identifiants compromis pour forcer le push de code malveillant dans 76 des 77 tags de version de l'action GitHub aquasecurity/trivy-action et dans les 7 tags de aquasecurity/setup-trivy. Simultanément, le groupe a publié un binaire Trivy trojanisé (v0.69.4) sur les canaux de distribution officiels. La charge utile était un logiciel malveillant destiné au vol d'identifiants qui collectait les variables d'environnement, les jetons cloud, les clés SSH et les secrets CI/CD de chaque pipeline exécutant un scan Trivy.

L'incident a été référencé sous le CVE-2026-33634 avec un score Common Vulnerability Scoring System (CVSS) de 9,4. L'Agence de cybersécurité et de sécurité des infrastructures (CISA) l'a ajouté au catalogue des vulnérabilités exploitées connues en l'espace de quelques jours.

23 mars : Checkmarx KICS tombe à son tour

À l'aide d'identifiants volés, le groupe TeamPCP s'est tourné vers le projet open source KICS (Keeping Infrastructure as Code Secure) de Checkmarx. Il a compromis les actions GitHub ast-github-action et kics-github-action, en injectant le même logiciel malveillant de vol d'identifiants. Le 23 mars, entre 12 h 58 et 16 h 50 UTC, tout pipeline CI/CD référençant ces actions exfiltrait silencieusement des données sensibles telles que des clés API, des mots de passe de bases de données, des jetons d'accès cloud, des clés SSH et des identifiants de comptes de service.

24 mars : LiteLLM compromis via des identifiants Trivy volés

LiteLLM, un proxy d'API LLM totalisant 95 millions de téléchargements mensuels, a été la cible suivante. Le groupe TeamPCP a publié des versions avec des portes dérobées (1.82.7 et 1.82.8) sur PyPI à l'aide d'identifiants collectés depuis le propre pipeline CI/CD de LiteLLM, qui utilisait Trivy pour le scan.

Le logiciel malveillant ciblant la version 1.82.7 utilisait une charge utile encodée en base64, injectée directement dans litellm/proxy/proxy_server.py, qui s'exécutait au moment de l'importation. Celui ciblant la version 1.82.8 utilisait un fichier .pth, un mécanisme Python qui s'exécute automatiquement au démarrage de l'interpréteur. La simple installation de LiteLLM suffisait à déclencher la charge utile. Les attaquants chiffraient les données volées (clés SSH, jetons cloud, fichiers .env, portefeuilles de cryptomonnaie) et les exfiltraient vers models.litellm.cloud, un domaine à l'apparence légitime.

31 mars : le code source d'un assistant de codage d'IA divulgué par une simple erreur d'empaquetage

Alors que l'attaque du groupe TeamPCP était encore en cours, un éditeur de logiciels a publié un paquet npm contenant un fichier de cartes de source de 59,8 Mo, qui référençait le code source TypeScript complet et non minifié de son assistant de codage d'IA, hébergé dans son propre compartiment Cloudflare R2.

La fuite a exposé 1 900 fichiers TypeScript, plus de 512 000 lignes de code, 44 feature flags cachés, des noms de code de modèles non publiés, ainsi que le prompt système complet, à la vue de tous ceux qui savaient où chercher. Comme l'a expliqué l'ingénieur Gabriel Anhaia : « Un seul fichier .npmignore ou champ files mal configuré dans package.json peut tout exposer. »

31 mars : axios et un autre cheval de Troie dans la chaîne d'approvisionnement

Le même jour, une attaque sophistiquée a ciblé le paquet npm axios, un client HTTP JavaScript qui totalise plus de 100 millions de téléchargements hebdomadaires.

Un compte de chargé de maintenance compromis a publié des versions avec des portes dérobées (1.14.1 et 0.30.4). Elles injectaient une dépendance malveillante ([email protected]) qui déployait un cheval de Troie d'accès à distance (RAT) capable de fonctionner sur macOS, Windows et Linux. Les deux branches de release ont été touchées en 39 minutes, et le logiciel malveillant était conçu pour s'autodétruire après exécution.

Les schémas derrière ces attaques

À travers ces cinq incidents, trois schémas d'attaque distincts se dégagent, et tous exploitent la confiance implicite que les pipelines CI/CD accordent à leurs données d'entrée.

Schéma 1 : outils et actions compromis

La série d'attaques du groupe TeamPCP a exploité une hypothèse fondamentale : celle selon laquelle les outils de sécurité exécutés à l'intérieur de votre pipeline sont eux-mêmes dignes de confiance. Lorsqu'un tag d'action GitHub ou une version de paquet PyPI recèle du code malveillant, le pipeline l'exécute avec un accès complet aux secrets de l'environnement, aux identifiants cloud et aux jetons de déploiement. Il n'y a aucune étape de vérification, car le pipeline fait confiance au tag.

Contrôle recommandé au niveau du pipeline : épinglez les outils et actions sur des références immuables (SHA de commit ou empreintes d'image) plutôt que sur des tags de version mutables. Lorsque l'épinglage n'est pas envisageable, vérifiez l'intégrité des outils et des dépendances par rapport à des sommes de contrôle ou des signatures. Bloquez l'exécution en cas d'échec de la vérification.

Schéma 2 : erreurs de configuration de l'empaquetage qui exposent la propriété intellectuelle

Un pipeline de build mal configuré a inclus des artefacts de débogage directement dans le paquet de production. Un fichier .npmignore ou un champ files mal configuré dans package.json suffit. Une étape de validation pré-publication devrait systématiquement détecter ce type d'erreur.

Contrôle recommandé au niveau du pipeline : avant toute publication de paquet, exécutez des vérifications automatisées qui valident le contenu du paquet par rapport à une liste d'autorisation, signalent les fichiers inattendus (cartes de source, configurations internes, fichiers .env) et bloquent l'étape de publication en cas d'échec.

Schéma 3 : vulnérabilités dans les dépendances transitives

L'attaque axios ne ciblait pas uniquement les utilisateurs directs d'axios, mais toute personne dont l'arbre de dépendances utilisait la version compromise. Une seule dépendance compromise dans un fichier de verrouillage (« lockfile ») peut ainsi se propager à travers l'ensemble de l'infrastructure de build d'une organisation.

Contrôle recommandé au niveau du pipeline : comparez les sommes de contrôle des dépendances avec l'état connu du fichier de verrouillage. Détectez les nouvelles dépendances inattendues ou les changements de version. Bloquez les builds qui introduisent des paquets non vérifiés.

Comment les politiques d'exécution des pipelines de GitLab répondent à chaque modèle d'attaque

Les politiques d'exécution des pipelines de GitLab (PEP) permettent aux équipes de sécurité et de plateforme d'injecter des jobs CI/CD obligatoires dans chaque pipeline à l'échelle d'une organisation, quel que soit le contenu défini par un développeur dans son fichier .gitlab-ci.yml. Les jobs définis dans les PEP ne peuvent pas être ignorés, même avec les directives [skip ci] ou [no_pipeline]. Les jobs peuvent être exécutés dans des étapes réservées (.pipeline-policy-pre et .pipeline-policy-post) qui encadrent le pipeline du développeur.

Nous avons publié des politiques d'exécution des pipelines prêtes à l'emploi pour les trois modèles sous forme de projet open source : politiques des chaînes d'approvisionnement. Ces politiques sont déployables de manière indépendante, et chacune est livrée avec des exemples de violations que vous pouvez utiliser pour les tester. Voici comment chacune fonctionne.

Cas d'utilisation 1 : prévenir les expositions accidentelles lors de la publication de paquets

Problème : un fichier de cartes de source s'est retrouvé dans le paquet npm d'un outil de codage alimenté par l'IA parce que le pipeline de build n'avait pas exécuté de validation au moment de la publication.

Approche PEP : nous avons créé une politique d'exécution des pipelines open source spécialement conçue pour cette catégorie d'erreurs : maintien de la qualité de l'artefact.

La politique injecte des jobs .pipeline-policy-pre qui détectent automatiquement le type d'artefact (paquet npm, image Docker ou chart Helm) et inspectent le contenu avant l'exécution de toute étape de publication. Pour les paquets npm, elle effectue trois vérifications :

1. Liste de blocage des motifs de fichiers. Analyse les données de sortie du paquet npm à la recherche de cartes de source (.map), répertoires de tests, fichiers de configuration de build, paramètres IDE et répertoires src/.
2. Contrôle de la taille du paquet. Bloque les paquets dépassant 50 Mo, comme le paquet de 59,8 Mo qui a provoqué la fuite de l'outil d'IA.
3. Analyse sourceMappingURL. Détecte les URL externes (le schéma du bucket R2 qui a exposé le code source d'un éditeur majeur d'IA) et les données inline : URI et références à des fichiers locaux intégrés dans les paquets JavaScript.

Lorsque des violations sont détectées, le pipeline échoue avec un rapport clair dans les logs du job CI en échec :

      =============================================
FAILED: 3 violation(s) found
=============================================
BLOCKED: dist/index.js.map (matched: \.map$)
BLOCKED: dist/index.js contains external sourceMappingURL
BLOCKED: dist/utils.js contains inline sourceMappingURL

This check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.

    

La politique ne comporte aucune variable CI configurable par l'utilisateur. Les développeurs ne peuvent ni la désactiver ni la contourner. Les exceptions sont gérées par l'équipe de sécurité au niveau de la politique afin de garantir un processus délibéré et une piste d'audit complète.

Le dépôt inclut un projet de test avec des violations intentionnelles (examples/leaky-npm-package/) pour que vous puissiez voir la politique en action avant de la déployer dans votre organisation. Le fichier README comprend un guide de démarrage rapide complet pour la mise en place et le déploiement.

Ce que cette politique détecte : n'importe lequel de ces contrôles aurait probablement empêché la fuite du code source de l'éditeur d'IA :

• Le fichier de cartes de source déclenche la liste de blocage des motifs de fichiers.
• Sa taille de 59,8 Mo déclenche le contrôle de taille.
• Le sourceMappingURL pointant vers un bucket R2 externe déclenche l'analyse d'URL.

Cas d'utilisation 2 : détecter la falsification de dépendances et la manipulation de fichiers de verrouillage

Problème : l'attaque axios a introduit une dépendance transitive malveillante (plain-crypto-js) qui exécutait un RAT à l'installation. Toute personne ayant exécuté un script npm install pendant la fenêtre de compromission a récupéré le cheval de Troie.

Approche PEP : la politique d'intégrité des dépendances injecte des jobs .pipeline-policy-pre qui détectent automatiquement l'écosystème de paquets (npm ou Python) et effectuent trois vérifications :

Pour les projets npm (déclenchés par package-lock.json, yarn.lock ou pnpm-lock.yaml) :

1. Intégrité du fichier de verrouillage. Exécute npm ci --ignore-scripts, qui échoue si node_modules diffère de ce que spécifie le fichier de verrouillage. Cette vérification permet de détecter les cas où package.json a été mis à jour sans régénérer le fichier de verrouillage, et vérifie également les hashes d'intégrité SRI.
2. Analyse des paquets bloqués. Croise l'arbre complet de dépendances du fichier de verrouillage avec blocked-packages.yml, une liste maintenue par GitLab des versions de paquets connues comme compromises. La liste de blocage fournie inclut [email protected], [email protected] et [email protected].
3. Détection des dépendances non déclarées. Après l'installation, compare le contenu de node_modules avec le fichier de verrouillage. Tout paquet présent sur le disque mais absent du fichier de verrouillage indique une falsification (par exemple, un script postinstall compromis qui récupère des paquets supplémentaires).

Pour les projets Python (déclenchés par requirements.txt, Pipfile.lock, poetry.lock ou uv.lock) :

1. Intégrité du fichier de verrouillage. Installe dans un environnement virtuel isolé et vérifie que l'installation réussit à partir du fichier de verrouillage.
2. Analyse des paquets bloqués. Même approche de liste de blocage. La liste fournie inclut litellm==1.82.7 et litellm==1.82.8.
3. Détection des fichiers .pth. Analyse les site-packages à la recherche de fichiers .pth contenant des motifs de code exécutable (import os, exec(, eval(, __import__, subprocess, socket). C'est exactement le mécanisme qu'utilisait la porte dérobée de LiteLLM.

Lorsqu'une violation est détectée :

      =============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: [email protected] is a known-compromised package

This check is enforced by a Pipeline Execution Policy.

    

La politique fonctionne en mode strict : toute dépendance absente du fichier de verrouillage validé bloque le pipeline. Si un développeur doit ajouter une dépendance, il effectue un commit du fichier de verrouillage mis à jour. La politique vérifie que la version installée correspond à la version validée. Si un élément apparaît sans avoir été validé (par exemple, une dépendance transitive injectée via un paquet amont compromis), le pipeline est bloqué.

Ce que cette politique détecte : l'introduction de plain-crypto-js en tant que nouvelle dépendance inédite serait signalée par la vérification des dépendances non déclarées. La version [email protected] serait interceptée par l'analyse des paquets bloqués. Le fichier .pth de LiteLLM serait détecté par la vérification des fichiers .pth. Chaque attaque présente au moins un, et souvent deux, signaux de détection indépendants.

Cas d'utilisation 3 : détecter et bloquer les outils compromis avant leur exécution

Problème : le groupe TeamPCP a remplacé les tags des actions GitHub Trivy et Checkmarx de confiance par des versions malveillantes. Tout pipeline référençant ces tags exécutait un logiciel malveillant de vol d'identifiants.

Approche PEP : la politique d'intégrité des outils injecte un job .pipeline-policy-pre qui interroge l'API CI Lint de GitLab (ou se rabat sur l'évaluation de .gitlab-ci.yml), extrait les références d'images de conteneurs et les compare à une liste d'images approuvées maintenue par l'équipe de sécurité.

La liste d'autorisation (approved-images.yml) prend en charge trois contrôles par image :

Dépôts approuvés : seules les images provenant de dépôts figurant sur la liste sont autorisées. Un dépôt inconnu bloque le pipeline.

Tags autorisés : seuls des tags spécifiques sont autorisés au sein d'un dépôt approuvé. Cela empêche la dérive vers des versions non testées.

Tags bloqués : les versions connues comme compromises peuvent être explicitement bloquées, même si le dépôt est approuvé. La liste d'autorisation fournie bloque les versions aquasec/trivy:0.69.4 à 0.69.6, les versions exactes trojanisées par TeamPCP.

Lorsqu'une violation est détectée, le pipeline échoue avant l'exécution de tout autre job :

      =============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)

 - tag '0.69.4' is known-compromised

This check is enforced by a Pipeline Execution Policy.

    

La liste d'autorisation est maintenue via des merge requests sur le projet de politique. Pour ajouter une nouvelle image approuvée, l'équipe de sécurité ouvre une merge request. Pour réagir à une nouvelle compromission, elle ajoute un tag bloqué. Aucune modification de code n'est nécessaire : uniquement du YAML.

Ce que cette politique détecte : lorsque des images avec des tags non approuvés sont détectées, la politique compare les noms de dépôts et les tags des images à la liste d'autorisation. Un échec de correspondance bloque le pipeline avant l'exécution de tout scanner, empêchant ainsi l'exfiltration d'identifiants.

Remarque : en étendant l'exemple ci-dessus, les PEP peuvent être utilisées pour imposer l'épinglage sur des empreintes (digests) plutôt que sur des tags, ce qui protège contre les pushs forcés. Cet exemple illustre un schéma d'application plus élémentaire basé sur les tags.

Au-delà des PEP : les défenses de GitLab concernant la chaîne d'approvisionnement

Les politiques d'exécution des pipelines constituent la couche d'application, mais elles fonctionnent au mieux dans le cadre d'une stratégie de défense en profondeur plus large. GitLab offre plusieurs fonctionnalités qui complètent ces politiques pour la protection de la chaîne d'approvisionnement :

Détection des secrets

La détection des secrets de GitLab empêche les identifiants d'atterrir dans le dépôt et réduit considérablement ce qu'un outil de pipeline compromis peut collecter. Dans le contexte des attaques de mars 2026 :

• Les identifiants stockés dans les dépôts sont à la fois plus faciles à découvrir pour les attaquants et plus longs à renouveler. L'incident Trivy a montré que même le processus de rotation peut être exploité : la rotation des identifiants d'Aqua Security n'était pas atomique, et l'attaquant a capturé les jetons qui venaient d'être émis avant que les anciens ne soient entièrement révoqués. La détection des secrets de GitLab inclut la révocation automatique des jetons GitLab divulgués et une API partenaire qui notifie les fournisseurs tiers pour qu'ils révoquent leurs identifiants afin d'accélérer la réponse en cas de violation.
• La détection des secrets, combinée à une gestion appropriée des secrets (jetons à durée de vie limitée, identifiants gérés par un coffre-fort, exposition minimale des secrets dans les pipelines), limite ce qu'un attaquant peut atteindre même lorsqu'un outil de confiance se retourne contre vous.

Analyse des dépendances via l'analyse de la composition logicielle (SCA)

L'analyse des dépendances de GitLab identifie les vulnérabilités connues dans les dépendances des projets en analysant les fichiers de verrouillage et les manifestes. Dans le contexte des attaques de mars 2026 :

• Pour LiteLLM, les versions compromises (1.82.7, 1.82.8) sont répertoriées dans la base de données d'avis de sécurité de GitLab, qui signale automatiquement les projets Python concernés.
• Pour axios, l'analyse des dépendances identifie les versions compromises (1.14.1, 0.30.4) dans tous les projets de l'organisation et offre aux équipes de sécurité une vue unifiée pour évaluer le rayon d'impact et prioriser le renouvellement des identifiants.
• Tous les paquets npm compromis par la propagation CanisterWorm de TeamPCP sont également signalés lorsqu'ils sont utilisés.

L'analyse des conteneurs de GitLab détecte les images de conteneurs vulnérables utilisées dans vos déploiements. Pour la compromission de Trivy, l'analyse des conteneurs signale les images Docker Trivy trojanisées (0.69.4 à 0.69.6) lorsqu'elles apparaissent dans votre registre de conteneurs ou vos manifestes de déploiement.

Politiques d'approbation des merge requests

Les politiques d'approbation des merge requests peuvent exiger l'approbation de l'équipe de sécurité avant que des modifications apportées aux fichiers de verrouillage de dépendances ou aux configurations CI/CD ne soient fusionnées. Cette approche garantit un point de contrôle humain pour les types de modifications que les attaques de la chaîne d'approvisionnement introduisent habituellement.

À venir : fonctionnalité Dependency Firewall, registre des artefacts et attestation et vérification SLSA de niveau 3

Les futures fonctionnalités de sécurité de la chaîne d'approvisionnement de GitLab renforcent l'application des politiques sur deux points de contrôle critiques : le registre et le pipeline. La fonctionnalité Dependency Firewall et le registre des artefacts bloqueront les paquets non conformes, tandis que l'attestation Supply chain Levels for Software Artifacts (SLSA) de niveau 3 fournira une preuve cryptographique que les artefacts ont été produits par des pipelines approuvés et n'ont pas été modifiés. Ensemble, ils offriront aux équipes de sécurité un contrôle vérifiable sur ce qui entre dans la chaîne d'approvisionnement logicielle et ce qui en sort.

Ce que cela signifie pour votre organisation

Face à la montée des menaces assistées par l'IA, les attaques contre les pipelines CI/CD deviennent monnaie courante. La série d'attaques du groupe TeamPCP démontre comment un seul identifiant compromis peut se propager en cascade à travers tout un écosystème d'outils de confiance.

Si votre organisation a utilisé l'un des composants affectés, partez du principe que tous vos secrets de pipeline ont été exposés : renouvelez-les immédiatement et auditez vos systèmes à la recherche de portes dérobées persistantes. Dans tous les cas, le renouvellement régulier des identifiants et l'utilisation de jetons à durée de vie limitée réduisent le rayon d'impact de toute compromission future.

Voici nos recommandations :

1. Épinglez les dépendances sur des sommes de contrôle, dans la mesure du possible. Les tags de version mutables (comme ceux détournés par TeamPCP) ne constituent pas une frontière de sécurité. Utilisez des références épinglées par SHA pour tous les composants CI/CD, actions et images de conteneurs.
2. Exécutez des vérifications d'intégrité avant l'exécution. Utilisez les politiques d'exécution des pipelines pour vérifier l'intégrité des outils et des dépendances avant l'exécution de tout job de pipeline. C'est l'étape .pipeline-policy-pre.
3. Auditez ce que vous publiez. Chaque étape de publication de paquet devrait inclure une validation automatisée du contenu de l'artefact. Les cartes de source, les fichiers d'environnement et les configurations internes ne devraient jamais quitter votre environnement de build. Le projet politiques des chaînes d'approvisionnement fournit un point de départ prêt à déployer pour les artefacts npm, Docker et Helm.
4. Détectez la dérive des dépendances. Comparez les résolutions de dépendances avec les fichiers de verrouillage validés à chaque exécution de pipeline. Surveillez l'apparition de nouvelles dépendances inattendues.
5. Centralisez la gestion des politiques. Ne comptez pas sur le fait que les développeurs se souviennent d'inclure les vérifications de sécurité. Appliquez-les au niveau du groupe ou de l'instance via des politiques que les développeurs ne peuvent ni supprimer ni contourner.
6. Considérez vos outils de sécurité comme des cibles. Si votre scanner de vulnérabilités, votre outil de test statique de sécurité des applications (SAST) ou votre passerelle d'IA peut être compromis, il le sera. Limitez chaque outil au strict minimum de privilèges nécessaires et vérifiez qu'il ne peut accéder à rien d'autre.

Protégez vos pipelines avec GitLab

En deux semaines, des attaquants ont compromis les pipelines de production d'organisations utilisant certains des outils les plus largement adoptés de l'écosystème de développement logiciel.

La leçon est claire : les pipelines de build nécessitent le même niveau de protection centralisée et pilotée par des politiques que celui que nous appliquons aux réseaux et à l'infrastructure cloud.

Les politiques d'exécution des pipelines de GitLab fournissent cette couche d'application. Elles garantissent que les vérifications de sécurité s'exécutent dans chaque pipeline, dans chaque projet, indépendamment des configurations individuelles des projets. Combinées à l'analyse des dépendances, à la détection des secrets et aux politiques d'approbation des merge requests, elles peuvent bloquer, détecter et contenir la catégorie d'attaques observée en mars 2026.

Le projet politiques des chaînes d'approvisionnement fournit une politique d'exécution des pipelines opérationnelle qui détecte exactement la catégorie d'erreurs à l'origine de la fuite du code source d'un éditeur majeur d'IA, avec une couverture pour les paquets npm, les images Docker et les charts Helm. Clonez-le, déployez-le dans votre groupe et assurez-vous que tous vos pipelines sont prêts à affronter les attaques de la chaîne d'approvisionnement à venir.

Pour tester les politiques de pipeline centralisées, inscrivez-vous pour un essai gratuit de GitLab Ultimate.

Cet article de blog contient des « déclarations prospectives » au sens de la section 27A du Securities Act de 1933, tel que modifié, et de la section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes exprimées dans ces déclarations soient raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus susceptibles d'entraîner des résultats réels sensiblement différents. De plus amples informations sur ces risques et autres facteurs figurent sous la rubrique « Facteurs de risque » dans nos dépôts auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de cet article de blog, sauf si la loi l'exige.