Nous avons vu précédemment que l’usine logicielle devait être isolée des autres environnements comme ceux de développement ou de production.

Nous devons aussi s’assurer qu’il n’y ait pas de connexion directe à Internet afin  de pouvoir suivre le trafic sortant et entrant et mettre en place les contrôles sur ce qui entre et qui sort.

En effet, de la même manière que nous ne souhaitons pas voir entrer des contenus malicieux, nous serons aussi attentifs à ne pas laisser sortir vers Internet des informations sensibles. 

Les contenus externes

Une usine logicielle consomme beaucoup de contenus externes, qu’ils soient publics, comme les projets Open Source, ou privés, comme des logiciels soumis à licence.

Nous trouverons 2 grandes familles de contenus externes : 

• Du code source
• Des artefacts

Sources et artefacts vont se retrouver sur les postes de développement et dans les chaînes de Continuous Integration et Continuous Deployment, ils seront présents partout sur l’ensemble du cycle de vie des produits qui vont les utiliser.

Code source

Les sources sont quasi exclusivement des contenus textuels, présents sur des plateformes collaboratives comme GitHub ou GitLab, dans des registres spécifiques comme Crates.io ou depuis des sites de mise à disposition comme pour la Fondation Apache.

Quand nous utilisons C/C++, Golang ou Rust, le code source externe est inclus dans le processus de compilation avec nos propres sources pour produire les applications. 

Le code source est évidemment totalement auditable et analysable car lisible par les développeurs et les outils d’analyse comme Sonarqube ou Snyk Code.

Artefacts

Les artefacts quant à eux sont souvent des fichiers binaires dont le format dépend du type (jar, war, oci) et ils sont disponibles dans des dépôts d’artefacts, publics ou privés, les plus connus étant Maven Central pour Java/Kotlin, NPM Registry pour NodeJS, ou PyPi pour Python.

Ce sont des dépendances applicatives utilisées dans le cycle de fabrication de vos produits, lors de la construction, les tests et embarqué tel quel dans les applications. 

De par leur nature binaire, l’audit est souvent impossible et les analyses se font sur des patterns de signature, comme les anti virus.

Contrôler les contenus externes

Nous avons donc 2 types de contenus à surveiller, les sources et les artefacts.

Pour les sources comme pour les artefacts, les accès se font généralement vers un nombre restreints de sites externes et en utilisant 2 protocoles, HTTP et SSH.

L’isolation et le contrôle se fera de manière différente suivant qu’il sagira de sources ou d’artefacts.

Pour les sources, nous utiliserons une mécanique de serveur proxy/cache qui sera le relais entre les consommateurs et Internet. 

Un serveur proxy/cache évitera des accès inutiles vers les distants pour les contenus déjà présents localement, accélérant ainsi les temps de construction.  

Pour les artefacts, nous nous orienterons plutôt vers un système de gestionnaire de d’artefacts. 

Un gestionnaire d’artefacts a plusieurs fonctions, comme héberger les dépôts d’artefacts produits en interne ou faire faire le proxy/cache de dépôts externes. 

Les dépôts externes à proxifier étant définis au préalable, nous avons un contrôle des sources. De même le proxy/cachant conservant les artefacts récupérés, cela évitera des accès inutiles vers Internet, permettant là aussi d’accélérer les temps de construction et fiabiliser les traitements.

Un gestionnaire d’artefacts est un élément central d’une chaîne de CI/CD, il est le pivot incontournable entre les phases de CI et CD.

Contrôler les sources via serveur relais (proxy)

La mise en place d’un proxy (relais), explicite ou transparent, permet de filtrer les contenus sources assez simplement.

Il faudra que l’ensemble des consommateurs de sources de l’usine logicielle passent par ce proxy. Ceci implique que les accès directs à Internet seront interdits pour l’ensemble des agents de construction, typiquement les exécuteurs GitLab ou les Runners GitHub.

Même s’il serait souhaitable d’appliquer la même règle aux postes de travail d’équipe de développement, le risque de pénaliser leur productivité n’est pas nul, il est recommandé d’aborder la problématique différemment, par de la formation et par la mise en place de règles qui rendent obligatoire l’inclusion des sources externes de manière dynamique dans la CI (où les règles peuvent s’appliquer). 

Il existe des solutions simples à mettre en place pour peu que nous retenions le protocole HTTP qui est utilisable dans l’immense majorité des sources externes. 

Un exemple simple de configuration d’un proxy Squid pour qu’il n’autorise les connexions qu’aux serveurs GitHub effectuée depuis un client git.

acl git_github dstdomain github.com

acl git_protocol header Access "User-Agent" "git"

acl git_methods method GET POST 

http_access allow git_github git_protocol git_methods 

http_access deny all

Contrôler les contenus des sources

La mise en place d’un proxy permet d’effectuer des contrôles sur le contenu et notamment s’assurer qu’il n’y pas de virus ou malwares.

La détection d’un contenu malicieux, virus ou malware, devra générer au moins 2 actions.

• Bloquer le téléchargement du contenu
• Déclencher une alerte auprès des équipes CI et/ou Sécurité pour investigation

Il sera important d’impliquer dans la phase d’analyse, l’équipe consommatrice du contenu détecté malicieux. Pour ce faire, il faut s’assurer que nous puissions l’identifier simplement, par exemple via la mise en place de tags (étiquettes) sur les processus de construction.

Les résultats de l’analyse devront donner lieu à un Post Mortem et des actions liées, à but pédagogique mais aussi de traçabilité.  

Si nous utilisons Squid, nous pourrons par exemple utiliser l’anti-virus gratuit ClamAV et SquidClamAV. Nous  pourrons aussi utiliser d’autres moteurs d’antivirus via le support SslBump de Squid.

Contrôler les origines des sources

L’utilisation d’un proxy permet de mettre en place des mécaniques de filtrage, typiquement avec des listes blanches qui ne vont autoriser que les accès que vers des sites distants identifiés.

La définition de la liste blanche est un moment important de la collaboration entre les équipes de consommateurs (développeurs) et les équipes CI et/ou Sécurité.

Cela permet de bâtir ensemble une cartographie des sites sources distants dit de confiance et des contenus nécessaires et suffisants à l’activité de développement.

C’est un travail itératif, souvent peu chronophage, qui permet de discuter régulièrement des nouveaux risques et de faire des piqûres de rappel sur les bonnes pratiques en termes de sécurité sur l’usine logicielle. 

Cela participe en plus à l’inventaire des sources externes qui peuvent être demandées lors d’audit de certifications.

Contrôler les artefacts via gestionnaire d’artefacts

Les artefacts sont stockés dans des dépôts sur Internet qui vont utiliser des formats de stockage et d’indexation propres au type d’artefact. 

Il s’agit de jar/war sur Maven Central, d’OCI sur Docker Hub, de packages Node pour le registre NPM ou de packages Python sur PyPi.

Nous trouvons des gestionnaires d’artefacts aptes à gérer plusieurs types de d’artefact, comme JFrog Artifactory ou Sonatype Nexus et des gestionnaires dédiés à un seul type comme Harbor pour le format OCI (Docker).

Dans une usine logicielle, nous manipulons plusieurs types d’artefacts, par exemple Java/Node coté développement et OCI coté production, retenir des gestionnaires comme Artifactory ou Nexus est préférable pour réduire les solutions mises en place.

Dans le gestionnaire d’artefacts, nous décrirons les dépôts d’artefacts distants autorisés, le gestionnaire se chargera de télécharger localement les artefacts distants et les exposera ensuite à l’ensemble des acteurs de l’usine logicielle, développeurs comme les agents de CI/CD.

Nous aurons ainsi une même source d’alimentation en artefacts, que ce soit depuis les postes de développeurs ou les serveurs de la CI/CD, cette source unique devra être unique et un point de passage obligatoire.

Les mécaniques de contrôles des artefacts

Des solutions comme Artifactory ou Nexus peuvent effectuer des contrôles sur les contenus mais aussi la distribution des contenus.

Exclusion de artefacts à risque 

Nous pouvons mettre en place des règles interdisant la distribution d’artefacts identifiés comme dangereux. 

Avec ses règles en place, les contenus douteux ne seront plus accessibles et les processus de construction qui les référencent finiront en erreur, obligeant à traiter le problème sans tarder.

Exemples d’exclusion des artefacts à risques log4j sur Artifactory et log4j sur Nexus

Analyse des artefacts existants

Des outils comme JFrog XRay peuvent analyser l’ensemble des artefacts présents dans vos référentiels Artifactory et remonter les vulnérabilités rencontrées. 

Il peut aussi s’intégrer à la chaîne de CI/CD pour alerter en cours de construction et ainsi permettre un traitement rapide des artefacts qui posent problème.

Cartographie des artefacts

Des vulnérabilités sont découvertes régulièrement, ce qui fait qu’un artefact peut devenir dangereux et qu’il devra être étudié et remplacé si la faille est exploitable.

Pour ce faire, il est recommandé d’utiliser des mécaniques d’inventaire automatique qui vont construire une cartographie des composants et artefacts présents dans vos livrables.

En plus des proxies de sources et gestionnaire d’artefacts, un outil comme DependencyTrack est un outil précieux à mettre en place pour vous permettre de suivre les risques tout au long du cycle de vie de vos produits. 

Pour rappel l’exposition du SBOM (la liste des composants logiciels hébergés dans vos applications) est fortement recommandée depuis l’Executive Order 14028 de 2021, ce n’est pas une obligation à ce jour.

L’adoption SBOM augmente dans l’industrie car elle apporte des garanties de transparence, sécurité, conformité permettant une meilleure gestion des risques côté client.

Conclusion

Avec des outils simples, il est possible de protéger efficacement et simplement son usine logicielle des contenus dangereux.

Dès lors que les contenus sources et artefacts ne sont plus consommés directement depuis Internet mais passent via des proxys et gestionnaires d’artefacts, nous aurons la possibilité de faire des analyses, interdire les contenus à risque et avertir sur des contenus nouvellement à risque.

Pensez également à réaliser une cartographie complète de l’ensemble de vos composants logiciels tiers, nous ne pouvons que suggérer d'introduire la fourniture de SBOM dans vos processus CI/CD.