Pourquoi la compilation doit-elle être impliquée dans le processus d’inspection du code ?

Cet article est partagé par la communauté Huawei Cloud  « Pourquoi la compilation doit-elle être impliquée dans le processus d'inspection du code ? » , auteur : gentle_zhou.

Alors que tout le monde accorde de plus en plus d'attention à la sécurité des logiciels, la protection de la sécurité du code source pendant la phase de codage est également de plus en plus fréquemment mentionnée par les équipes de R&D, de test, d'exploitation et de maintenance et par les développeurs individuels d'entreprises de tous horizons, parmi lesquels lequel l'outil SAST d'inspection de code statique fait particulièrement saillie.

Le service d'inspection de code SAST est un outil qui permet de vérifier la qualité (y compris le style), la sécurité, les spécifications et d'autres aspects du code source. Il peut détecter les défauts et les risques dans le code. Comme tout le monde utilise l'outil en profondeur, de nombreux amis sont confus pendant le processus d'utilisation : n'ont-ils pas accepté de vérifier uniquement le code source ? Pourquoi la compilation est-elle impliquée ? Pourquoi la compilation réussit-elle dans mon environnement local, mais lorsque je la mets dans l'environnement cloud, il est indiqué que la compilation a échoué ?

Cet article tente d'expliquer les problèmes ci-dessus un par un afin que les amis puissent comprendre le processus et les principes.

1. N'avez-vous pas accepté de vérifier uniquement le code source ? Pourquoi la compilation est-elle impliquée ?

De manière générale, oui, l'inspection statique du code SAST est une technologie de test de sécurité des applications statiques, qui est généralement effectuée avant la compilation du code ; c'est-à-dire que l'outil SAST ne force pas l'exécution ou l'exécution du code avant qu'il puisse être utilisé. . Il cible le code source lui-même. Vous pouvez analyser la syntaxe, la structure, la logique, etc. du code.

Cependant, cela ne signifie pas que l'outil SAST n'a rien à voir avec la compilation ; en fait, si nécessaire, l'outil SAST doit également utiliser l'outil de compilation et de construction pour compiler le code, puis analyser le produit de compilation généré pour analyser le la sémantique du code et la logique pour avoir une compréhension et une analyse plus approfondies.

2. Quel est le processus général de compilation ?

Avant de parler du processus de compilation, comprenons d’abord quelques noms propres.

AST, Abstract Syntax Tree, est une structure de données en forme d'arbre utilisée pour représenter la structure du code d'un programme. Elle peut refléter la syntaxe et la logique du code. AST peut être utilisé pour la vérification de la syntaxe, la vérification du style de code, le code formaté, la coloration syntaxique, les invites d'erreur, la complétion automatique, etc.

cke_114.png

IR, Intermediate Representation, est une structure de données utilisée pour représenter la sémantique du code d'un programme. Elle peut convertir les codes de différents langages de programmation en une forme commune pour faciliter l'analyse et l'optimisation.

cke_115.png

CFG, Control Flow Graph, est une structure de données graphique utilisée pour représenter le flux d'exécution du code du programme. Il peut diviser le code en blocs de base et utiliser des arêtes pour représenter les relations de saut entre les blocs de base.

cke_116.png

Les trois noms techniques ci-dessus jouent un rôle en permettant aux outils de mieux comprendre et traiter la sémantique et la logique du code pendant le processus d'inspection du code, contribuant ainsi à améliorer la précision de l'analyse.

Revenons au fait, par quels processus allons-nous passer pendant le processus de compilation de l'outil de vérification de code SAST ? De manière générale, le processus de compilation complet passera par : l'analyse du code source pour la syntaxe, le lexique et la sémantique, la génération d'AST, puis la conversion en IR, la génération de CFG, l'analyse et l'optimisation du flux de données et la génération du code cible.

L'inspection du code SAST n'est donc pas totalement indépendante de la compilation. Dans une certaine mesure, elle doit s'appuyer sur des outils de compilation et de construction pour faciliter une analyse approfondie.

3. Pourquoi la compilation réussit-elle dans mon environnement local mais échoue lorsque je la place dans l'environnement cloud ?

À ce stade, je pense que la plupart des amis comprendront que l'opération de compilation est utilisée dans l'outil SAST, mais je pense qu'il y aura toujours des scènes d'analyse infructueuse lors de l'utilisation. La plus typique doit être le problème dans le sous-titre : Pourquoi ma compilation locale réussit-elle, mais lorsque je la soumets à la vérification de l'environnement cloud, il est indiqué que la compilation a échoué ?

Concrètement, il y a à peu près les raisons suivantes :

  • La chose la plus courante est que dans l'environnement local, le projet fait référence à certaines dépendances ou configurations privées stockées localement. Dans l'environnement cloud, pendant le processus de compilation SAST, ces dépendances ou configurations sont introuvables et la compilation échoue.
  • Le projet de l'utilisateur lui-même n'est pas un projet compilé ou, bien que le projet soit un projet compilé, il n'est pas configuré correctement dans le projet. Par exemple, un problème souvent rencontré est que les utilisateurs se contentent de reprendre un projet et d'obtenir l'information qu'il s'agit d'un projet compilé, alors qu'en fait le projet ne contient pas le fichier de configuration principal. Par exemple, le fichier de configuration principal pom.xml est manquant dans le projet maven.
  • Les paramètres de compilation des chèques dans l'outil cloud SAST ne sont pas sélectionnés correctement. Par exemple, le projet de l'utilisateur est un projet Maven, mais l'utilisateur pense à tort qu'il s'agit d'un projet Gradle et sélectionne Gradle comme outil de compilation dans le cloud. Pour un autre exemple, dans le projet C#, pour le projet de compilation msbuild, la mauvaise version du framework .net a été sélectionnée (3.5 a été sélectionnée au lieu de 4.8).
  • Il y a des erreurs grammaticales ou des erreurs de type (telles que des fautes d'orthographe, des points-virgules manquants, des incohérences de type, etc.) dans le code du projet de l'utilisateur. Dans l'environnement local, l'aide de l'EDI les corrige automatiquement ou le compilateur local ne les vérifie pas. L'outil cloud SAST utilise un compilateur plus strict ou de niveau supérieur, ce qui entraîne l'échec de la compilation.
  • Il existe des fonctionnalités de langage spéciales ou du sucre syntaxique dans le projet de l'utilisateur, telles que les expressions Lambda, les compréhensions de listes, etc. Le compilateur local prend en charge ces fonctionnalités, tandis que l'outil cloud SAST utilise un compilateur qui ne prend pas en charge ces fonctionnalités ou une version de langage inférieure. . Provoque l'échec de la compilation.

Bien entendu, différents outils SAST utilisent différentes méthodes et technologies d'analyse, ils ont donc également différentes méthodes de compilation et différents degrés de dépendance à l'égard de l'environnement de compilation.

Les références

1. https://en.wikipedia.org/wiki/Abstract_syntax_tree

2、https://www.twilio.com/blog/abstract-syntax-trees

3、https://www.cs.princeton.edu/courses/archive/spr03/cs320/notes/IR-trans1.pdf

4、https://gcc.gnu.org/onlinedocs/gccint/Control-Flow.html# : ~:text=Un graphe de flux de contrôle (CFG) est une donnée, le comportement d'une fonction en cours de compilation.

5、https://www.csl.cornell.edu/ ~zhiruz/5997/pdf/lecture04.pdf

 

Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~

 

Amende de 200 yuans et plus d'un million de yuans confisqués You Yuxi : L'importance des documents chinois de haute qualité Le serveur de migration hard-core de Musk Solon pour JDK 21, les fils virtuels sont incroyables ! ! ! Le contrôle de la congestion TCP sauve Internet Flutter pour OpenHarmony est là La période LTS du noyau Linux sera restaurée de 6 ans à 2 ans Go 1.22 corrigera l'erreur de variable de boucle for Svelte a construit une "nouvelle roue" - les runes Google fête son 25e anniversaire
{{o.name}}
{{m.nom}}

Je suppose que tu aimes

Origine my.oschina.net/u/4526289/blog/10114610
conseillé
Classement