Est-ce que mon application est maintenable ?

On se pose souvent la question: Est-ce que mon application est maintenable à moyen et long terme? Mais comment peut-on l’évaluer ?

Quand on parle de maintenabilité, on pense souvent au code que l’on a écrit, mais qu’en est-il du code généré ou inclus dans notre application ? On peut penser à nos dépendances externes ou encore au code généré par Copilot. C’est pour cela qu’on va analyser la question sous les deux angles: l’analyse automatique de notre code et l’analyse de ses dépendances externe qui est souvent l’angle mort de notre analyse.

Pour cela, on verra aussi comment les choisir, les analyser et s'assurer de ne pas rajouter des risques à long terme ? Aussi, au moment du choix, une librairie peut être la bonne, mais des mois ou des années après, est-ce qu'on est à jour, est-ce que des failles de sécurités ont été découverte ?

Et surtout, essayons de réconcilier deux concepts souvent opposé : productivité versus maintenabilité. Comment s’assurer de ne pas sacrifier l’un des deux dans nos développement ?

Transcript

1. Est-ce que mon application est maintenable ?
2. Julien Maitrehenry Qui suis-je? Dev, Ops, Cloud Architect, mentor Co-fondateur @Kumojin Microsoft MVP Azure Docker Captain Kumojin.com jmaitrehenry.ca Github.com/jmaitrehenry Linkedin/in/jmaitrehenry
3. Qu’est que la maintenabilité ? Analyser le code écrit Analyser le code ajouté AGENDA
4. Maintenabilité, qu’est-ce que c’est ?
5. Capacité à intervenir sur une application: • De manière cohérente • Simplement • Rapidement • Sans causer d’effets secondaires Maintenabilité, qu’est-ce que c’est ?
6. Comment le mesurer ?
7. • Temps pour ajouter / modifier des fonctionnalités • Nombre de bugs • Temps Moyen jusqu’à Réparation (MTTR) • Satisfaction des devs à travailler dans l’application Comment le mesurer ?
8. Quoi mesurer ?
9. Le code écrit • Analyse statique • Analyse dynamique • Code généré par l’IA Le code externe ajouté (librairies) • Analyse de composition (SCA) Quoi mesurer ?
10. Le code écrit
11. • N’exécute pas le code • Aucun requis autre que le code • Dès le début du projet • Approximatif • Faux positifs • Faux négatifs Analyse statique
12. Validations: • Du style (linter) • Complexité • Duplication • Sécurité (SAST) Analyse statique
13. • Exécute l’application • Valide le comportement • Se fait une fois l’application fonctionnelle Analyse dynamique
14. Plusieurs enjeux: • Maintenabilité • Propriété intellectuelle • Sécurité Code généré par l’IA
15. • Fonctionne-t-il ? • Est-il efficace/efficient ? • Respecte-t-il les standards du projet ? • Ajoute-t-il des bugs ? Code généré par l’IA - Maintenabilité
16. • Inclusion de code licencié ? • Valeur du code ? Code généré par l’IA – Propriété intellectuelle
17. • Génère du code non sécuritaire • Donne l’impression d’écrire du code sécuritaire Code généré par l’IA – Sécurité Étude de Standford: Do Users Write More Insecure Code with AI Assistants? https://arxiv.org/pdf/2211.03622
18. Le code externe ajouté
19. Qu’est-ce qu’une dépendance ?
20. Qu’est-ce qu’une dépendance ? • Une librairie externe au projet • Runtime: nécessaire au fonctionnement de l’application • Dev: nécessaire pour le développement et/ou le test de l’application • Est versionné • Peut avoir des dépendances
21. Problèmes
22. Dependency Hell • Beaucoup de dépendances nécessaires • Longue chaine de dépendances (lib A dépend de lib B qui dépend …) • Conflit de dépendances • Dépendances circulaires • Multiple version d’une même dépendance
23. Problèmes • Est-ce que cela existait déjà ? • Est-ce que le développeur continue de la maintenir ? • Est-ce que celle-ci est bien faite ? • Sans faille de sécurité • Sans autres problématique • Est-ce que la licence me permet de l’utiliser dans un projet ?
24. Problèmes • Comment choisir la bonne librairie ? • Comment s’assurer qu’elle est maintenue ?
25. Problèmes https://nvd.nist.gov/vuln/search/statistics?form_type=Basic&results_type=statistics&search_type=all&isCpeNameSearch=false • Nombre de vulnérabilité découverte augmente à chaque année • 2021 à 2023: +30% K 5K 10K 15K 20K 25K 30K 35K 40K 2019 2020 2021 2022 2023 Vulnérabilité découverte par année
26. Ce qu’on doit analyser
27. Sécurité • Dépendance direct et indirect du projet • Le plus simple à mettre en place • Lister les CVEs par • Sévérité • Ancienneté • Si une version avec un correctif existe ou pas
28. Légale / Licence • Type de licence • Open source • Open source mais interdite à l’interne (ex: GPL) • Licence non ouverte et/ou n’autorisant pas l’utilisation • Pays de la licence • Restriction d’importation • Pays restreint sur l’utilisation d’une licence commercial ex: Indonesie
29. Maintenabilité • Seulement les dépendances directes • Est-ce maintenue activement ? • Issue Github • Ouvertes vs Fermées • Ouvertes sans réactions • Nombre de PR ouverte • Ouvertes vs Fermées • Ouvertes sans réactions • Nombre de contributeur • Mise à jour du code et des dépendances du projet
30. Quand vérifier ?
31. Quand vérifier ?
32. Quand vérifier ? • Le plus tôt possible • Lors de l’ajout • Lors d’un changement ICI ICI
33. Quand vérifier ? • De manière périodique • Nouvelles failles de sécurité • NPM: 2.3 ans pour 50% des vulnérabilités • RubyGems: 7 ans • Nouvelle version • Arrêter d’être maintenue • Être supprimé ou renommé
34. Comment vérifier ?
35. • Détecte le code open source inclus • Évalue celui-ci sur plusieurs aspects: • Qualité • Sécurité • Licence • De manière automatisé Software Composition Analysis (SCA)
36. Software Composition Analysis (SCA)
37. SBOM
38. SBOM • Généré lors du build • De l’application • De l’environnement • Traçabilité • Qui, quand, pourquoi une librairie fut ajouté/modifié
39. Conclusion • Développer du logiciel maintenable c’est compliqué ! • Analyser le code écrit le plus tôt possible coûte moins cher à long terme • Analyser le code inclut lors de l’ajout et de manière récurrente est important • L’IA peut être un bon outil mais il faut se poser les bonnes questions
40. Merci Questions RÉPONSES Interrogations Suggestions COMMENTAIRES JASETTE SUGGESTIONS CAUSERIE Palabre INFORMATION