Dans l'incident SolarWinds, découvert en décembre 2020, des attaquants se sont introduits dans l'environnement de build d'un logiciel d'administration informatique et du code malveillant a été inséré dans des mises à jour légitimes. Ces mises à jour ont été distribuées avec la signature de code légitime du développeur. Quel est l'enseignement le plus approprié de cet incident ?

Réponse : C. Une signature de code montre seulement qui a signé et si le code a été modifié après la signature ; les développeurs doivent donc protéger l'environnement de build, et les utilisateurs surveiller aussi le comportement des logiciels de confiance

La signature de code confirme qui a signé et que le contenu n'a pas été modifié après la signature ; elle ne peut pas reconnaître du code malveillant inséré avant la signature. Dans l'incident SolarWinds, exemple type d'attaque par la chaîne d'approvisionnement logicielle, du code malveillant a été ajouté pendant le build, si bien qu'il est parvenu à de nombreuses organisations sous forme de mises à jour légitimes et signées. Dans la porte dérobée de xz-utils, découverte en mars 2024, une personne qui avait passé longtemps à gagner la confiance en tant que développeur a elle aussi glissé du code malveillant dans les fichiers distribués. Il est important que les développeurs isolent et protègent l'environnement de build et enregistrent et vérifient la provenance, du code source jusqu'au build, et que les utilisateurs surveillent même les logiciels de confiance pour détecter les communications et comportements suspects avec l'EDR et des outils similaires.