EXI EDC PSC 102-4
Document de conformité
xxx
Chapitre 1 : Prérequis Maturité Technique
En tant que FS, j’ai pour obligation de m’approprier et paramétrer à un niveau de sécurité satisfaisant toute configuration par défaut le nécessitant, et d’effectuer une revue régulière de ces configurations notamment à l’occasion des montées de version des composants.
Lorsqu’ils sont disponibles, je devrais utiliser des outils pour auditer l’ensemble des composants du système à chaque modification.
Les composants issus de tiers doivent être sélectionnés en tenant compte du respect de bonnes pratiques similaires par ces tiers.
| EXI EDC PSC 102-4 | |||
|---|---|---|---|
| Éditeur de Logiciel Utilisateur | Éditeur de Logiciel Proxy e-santé | ||
|
[Il est attendu que le Fournisseur de Service détaille quels fichiers de configuration (de librairies, services,
systèmes…) ont été personnalisés et quelles bonnes pratiques ont été mises en place pour garantir la
sécurisation globale du système, en particulier lorsqu’il s’agit de sous-systèmes sensibles ou issus de tiers
OU fasse référence à un extrait, clairement identifié, d’un document qu’il fournira. ] |
|||
Exemple de structure de réponse à compléter :
Bill Of Materials
Une bonne pratique est d’avoir un projet père (BOM) contenant toutes les versions des dépendances.
Repositories officiels
Les dépendances autorisées doivent être récupérées depuis des repositorys de confiance (donner la liste)
Tous les repositories à utiliser doivent être déclarés dans le BOM et vérifiés au préalables. Il est interdit d’ajouter individuellement un repository dans un module ou sous module d’un projet.
Tools
Liste des outils à utiliser pour la vérification des packages
Exemple pour maven et Docker :
Maven
enforcer
Permet de forcer tous les projets à utiliser les versions validées de java notamment
- maven-enforcer-plugin : https://maven.apache.org/enforcer/maven-enforcer-plugin/
Exemple de mise en oeuvre.
dependency:tree
mvn dependency:tree donne un arbre de toutes les dépendances transitives utilisées dans les différents projets. Utile pour checker l’usage d’une librairie.
Plugin Intellij Package checker
Permet de vérifier en temp réel les failles de sécurité des dépendances maven (s’appuie sur CheckMark)
Docker scout
Docker Scout permet l’analyse des vulnérabilités selon la spécification CVSS (Common Vulnerability Scoring System) : https://www.first.org/cvss/v4-0/specification-document
C’est un outil essentiel pour le bon suivi des vulnerabilités des librairies utilisées.
Exemple de vulnérabilité critique détecté dans le package commons-collections :
Généralement, la description CVE permet de donner l’indication concernant la version de la librairie correctrice de la vulnérabilité. Une fois la vulnérabilité détectée, monter sur la version de correction de la librairie impactée dans le BOM si la librairie est susceptible d’être utilisé dans plusieurs projets, dans le POM parent du projet sinon.
Analyse d’une vulnérabilité - Cas d’école
Prenons l’exemple de la distribution devboxsante/devboxsante-eproxy dans la version de développement en cours (tag:dev).
- Construction de l’image docker :
git clone xxx.xxx.git
mvn clean install -Pdocker
- Ouverture de docker desktop et analysons l’image :
Ici, on voit que l’image de base eclipse-temurin n’a pas de vulnérabilité avec des sévérités supérieures à médium et que la provenance est officielle (Docker official image). On peut aussi remarquer qu’une image plus récente est disponible.
==> On peut donc envisager une montée de version de l’image de base , cette montée de version doit faire l’objet d’un ticket dans le projet et de réaliser les tests de non régression ‘bruno’ et spécifiques (ici la pfi a des flux hl7 ou les tests sont manuels)
Le reste de l’analyse remonte aucune vulnérabilité critique, ce qui est une bonne nouvelle, mais quant même 4 hautes.
En fait 5, mais une deux fois dans la même librairie mais dans une version différente :
Un mvn dependency:tree sur le projet distrib pfi-docker remonte d’où elle est tirée :
Docker scout nous dit que la version corrigée est la version 2.14 :
La lecture des release notes de commons-io : https://commons.apache.org/proper/commons-io/changes.html , nous dit que la version courante est la version 2.19.0 et qu’il y a un grand nombre de fix dans les différentes versions.
Expliquer ensuite comment vous remédiez à la vulnérabilité.
Conclusion
- Le BOM utilisé est un pattern puissant pour la bonne gestion des dépendances.
- Se mettre à jour au plus tôt dans les versions utilisées éliminent la plupart des risques de vulnérabilité de nos dépendances. Pour cela utiliser le plugin Package Checker d’Intellij.
- Docker Scout est la “silver bullet” pour l’analyse des vulnérabilités des livrables DevBox-Santé.