Aujourd’hui je vais vous parler de ce qu’est l’audit de code source, c’est en pratique, une relecture du code source d’une application. Il permet d’identifier les vulnérabilités présentes dans le code source, d’en améliorer la maintenabilité, les performances ou de s’assurer de sa conformité à une norme ou aux processus métiers.
Un audit de code de développement est l’analyse du code à la fois des applications de pages Web et de tout type d’application, quel que soit le langage utilisé, ce qui permet de connaître en détail l’état actuel du code développé, tant en termes de sécurité que de qualité ou de performance.
Tout d’abord, nous allons définir quels types de code Audits existent :
Analyse de code statique, revue de code ou en anglais Static Application Security Testing (SAST) ou White Box Audit
Fondamentalement, cela fait référence à l’analyse qui est effectuée dans une version du code source et dans d’autres cas, elle est effectuée dans le code objet. Ce processus se fait principalement en examinant et en lisant le code. Celui-ci est généralement présenté sous la forme d’un code source original, bien qu’il puisse également être réalisé à partir d’exécutables, par ingénierie inverse ou par logiciel spécialisé.
Cela nécessite la collaboration de l’équipe de développement, car elle connaît la structure de l’application et peut faciliter le cheminement dans la revue de code en optimisant les zones de celle-ci qui seront auditées.
Test de sécurité dynamique des applications (DAST) ou audit Black Box
Fait référence à la simulation d’attaques sur une application ou un service Web en cours d’exécution pour identifier les vulnérabilités de sécurité des applications Web exploitables et les faiblesses architecturales. et c’est un complément à l’audit de code statique
Désormais, aucune technique d’analyse automatique ne peut trouver toutes les vulnérabilités possibles ; Chaque technique a ses propres forces et faiblesses.
Le graphique suivant montre les types de vulnérabilités que chaque technique peut découvrir et où ils se chevauchent pour la corrélation. Le grand cercle vert indique le nombre de problèmes de sécurité potentiels qui ont été détectés en effectuant des tests manuels et DAST et SAST.
Avec l’analyse dynamique, il est plus facile d’avoir une vue d’ensemble lorsqu’il s’agit de connecter la vulnérabilité. DAST montre les endroits dans l’application qui peuvent être exploités par les tests qu’il envoie ; il parcourt l’application automatiquement et teste les entrées possibles, envoie des demandes et reçoit des réponses qui sont ensuite reflétées dans le navigateur.
L’analyse statique inspecte les flux de données dans tout le code source et peut être utilisée dès le cycle de développement car l’application Web n’a pas besoin d’être exécutée. Alors que DAST est limité car il ne peut visualiser que le flux de données allant vers HTTP, SAST peut voir plusieurs flux de données se déplacer en arrière-plan et ne pas être exposés à des analyses dynamiques telles que les communications réseau back-end, les accès au système de fichiers, etc.
Pour cette raison, SAST rencontrera plus de problèmes que DAST.
Maintenant, la principale raison pour effectuer des tests d’audit de code est que 80% des applications contiennent au moins une vulnérabilité élevée et 90% des incidents de sécurité qui se produisent sont dus à des défauts dans la conception ou dans le code logiciel et en outre, une violation de la sécurité exigences n’est pas aussi évidente que de violer les exigences de qualité car une application qui ne fonctionne pas est évidente pour l’utilisateur final qu’une vulnérabilité dans l’application
Habituellement les failles de sécurité sont découvertes grâce à l’utilisation d’outils et de tests spécialisés dans le domaine de la cybersécurité tels que SonarQube, Veracode, Fortify
Il est courant de développer d’abord un logiciel puis de demander un audit. Cela peut être très improductif puisque les résultats d’un audit de code statique consistent en une série de vulnérabilités trouvées et des modifications ou actions nécessaires pour les corriger, ce qui implique beaucoup de temps de développement supplémentaire que si elle avait été détectée lors de son développement. .
Il est conseillé au cours du processus de développement de réaliser plusieurs audits accompagnés d’un développement logiciel sécurisé.
Conclusion
Tout développement de logiciel qui requiert un certain niveau de maturité doit gérer ses éventuelles vulnérabilités comme toute organisation qui l’utilise doit évaluer ses risques. Pour cela nous avons entre autres outils le code ou les audits statiques (SAST) qui sont ceux que cet article occupe avec sa description.
Ce type de pratique qui fait partie de la gestion de la sécurité informatique ou de la cybersécurité se complète comme je l’ai mentionné avec beaucoup d’autres comme l’analyse des risques, la création de politiques de sécurité, la découverte de vulnérabilités, le pentesting, les audits dynamiques (DAST)
Pour tous les nouveaux développements, la sécurité doit être intégrée dans l’Application Development Life Cycle ou en anglais Software Development Life Cycle (SDLC) où interviennent les aspects suivants :
Développement sécurisé : rétroaction continue sur les postes de travail des développeurs à la « vitesse DevOps »
Tests sécurisés : sécurité évolutive intégrée à la chaîne d’outils de développement d’applications.
Surveillance et protection en continu : Surveillance et protection des logiciels exécutés en Production
Pour développer un audit de code efficace, il est nécessaire d’utiliser ou de suivre une méthodologie du Guide de révision du code OWASP, toujours en production.
Enfin, l’outil que vous utilisez pour effectuer l’audit de code doit être intégré et disponible pour les développeurs, déterminer la traçabilité des défauts de développement et montrer des solutions rapides, ainsi que des solutions possibles.
Article original du site Live Sensei
