Story #13030 Checkmarx: Limit number of fields (100k) in JSON to prevent possible infinite loop

[marob]

Description

Cette MR avait pour but de limiter l'itération while sur les fields pour éviter les boucles "infinies".
Le but était que Checkmarx ne remonte plus la vulnérabilité "Unchecked Input for Loop Condition".

Le problème est que Checkmarx n'ignore cette vulnérabilité que s'il détecte une vérification de la taille de la liste sur laquelle on itère. Cette vérification se fait sur la présence d'un .size(), .length() ou équivalent dans le code. Mais ici, on itère sur un iterator. Or, on ne peut pas connaître la taille d'un iterator sans le consommer (et itérer dessus avec une boucle, et donc potentiellement une boucle infinie...).
La solution mise en place dans cette MR est fonctionnelle : on itère sur l'iterator puis on stoppe l'itération si on atteint un certain nombre. Par contre, Checkmarx n'est pas capable nativement d'analyser ce code pour ne plus remonter la vulnérabilité "Unchecked Input for Loop Condition".

Cette MR introduit donc une contrainte fonctionnelle supplémentaire (si jamais on a un cas qui dépasse la limité arbitrairement mise en place) sans pour autant faire disparaître la vulnérabilité remontée par Checkmarx.
Si l'on souhaite merger cette MR, il faut que la contrainte fonctionnelle soit validée par les PO et idéalement que Checkmarx soit configuré pour "comprendre" ce code et ignorer la vulnérabilité (c'est surement faisable, mais pas évident vu la complexité et le manque de documentation de leur "query editor").

Une autre solution est de n'ignorer manuellement cette vulnérabilité dans Checkmarx en la marquant comme faux positif (en la corrigeant ou non si l'on considère que ce n'est pas un cas réaliste).

Type de changement

Indiquer le ou les types de changements

• Build
• PKI
• Ansiblerie
• Nouveau Code
• Correction
• Refactorisation de code
• Autre

Documentation

Indiquer la documentation mise à jour

• Quels sont les nouvelles documentations ?
• Quels sont les modifications existantes ?
• Quels sont les documentations ou sections de documentations supprimés ?

Tests

Indiquer comment le code à été testé (manuel, environnement, TU, etc)

• manuel
• environnement
• TU

Migration

Indiquer si les modifications apportées impliquent une migration sur l'existant et comment la faire

Checklist

Sélectionner les éléments de la checklist

• Mon code suit le style de code de ce projet.
• J'ai commenté mon code, en particulier dans les classes et les méthodes difficile à comprendre.
• J'ai fait les changements correspondant dans la documentation RAML.
• J'ai fait les changements correspondant dans la documentation Métier.
• J'ai fait les changements correspondant dans la documentation Technique.
• J'ai rajouté les tests unitaires vérifiant mes fonctionnalités.
• J'ai rajouté les tests de non régression vérifiant mes fonctionnalités.
• Les tests unitaires nouveaux et existants passent avec succès localement.
• Toutes les dépendances ont été mergées en priorité

Contributeur

Indiquer qui a développé cette fonctionnalité

• VAS (Vitam Accessible en Service)
• CEA (Commissariat à l'énergie atomique et aux énergies alternatives)