L'évolution de l'analyse statique : des motifs à l'analyse de flux de données dans sa-tests-db
Un analyseur statique se qualifie selon GOST R 71207-2024 en utilisant le corpus sa-tests-db pour six langages : C, C#, Go, Java, JavaScript, Python. Cela est réalisé en passant de la recherche basée sur des motifs à l'analyse de flux de données, qui prend en compte les appels interprocéduraux, le flux de contrôle et la sensibilité aux champs dans les structures. Cette approche minimise les faux positifs et les faux négatifs pour tous les types d'erreurs.
Limites de la recherche basée sur des motifs
L'analyse basée sur des motifs recherche des appels dangereux comme sprintf, system ou SPI_execute dans un contexte de quelques lignes. Elle est efficace pour un balayage initial rapide, mais présente des limites :
- Elle ne tient pas compte des flux de données entre les points de définition et d'utilisation.
- Les faux positifs surviennent de la proximité accidentelle de code suspect sans connexion réelle.
- Elle manque les chaînes longues qui passent par des fonctions ou des fichiers.
Sur le corpus externe sa-tests-db, ces limites deviennent rapidement apparentes, nécessitant un passage à l'analyse de flux de données.
Analyse de flux de données
Le passage à l'analyse de flux de données répond à la question : les données provenant de sources (comme getenv, recv, fgets) peuvent-elles atteindre des puits dangereux ? Cela construit un graphe de connexions entre la définition et l'utilisation des valeurs.
Avantages :
- Réduit les faux positifs en vérifiant le chemin réel.
- Découvre les chemins interfonctionnels.
Dans l'implémentation, l'analyseur suit la propagation de la contamination, en excluant les valeurs non liées.
Analyse interprocédurale
Le flux de données intra-fonctionnel est insuffisant pour les vulnérabilités réelles qui passent par des chaînes d'appels. La couche interprocédurale connecte les arguments avec les paramètres :
- Suivi des valeurs de retour.
- Analyse des arguments dans les appels.
- Construction d'un graphe d'appels pour les chemins inter-fichiers.
Sans cela, les motifs ne voient que des blocs locaux, perdant le contexte système.
Prise en compte du flux de contrôle
L'existence d'un chemin de données ne garantit pas une vulnérabilité. Le chemin peut être bloqué par :
- Une validation.
- Une gestion d'erreur.
- Des vérifications de permissions.
- Des branches logiquement inaccessibles.
L'intégration de l'analyse du flux de contrôle classe les chemins :
- Inconditionnels (haute priorité).
- Conditionnels (nécessite une revue manuelle).
Cela filtre le bruit, améliorant la précision des rapports.
Sensibilité aux champs dans les structures
Dans les structures, la contamination d'un champ ne doit pas se propager à toute la structure. Distinguer les champs réduit les fausses alertes :
- Suivi séparé de la
contaminationpour chaque champ. - Exclusion des champs sûrs lors de l'atteinte d'un puits.
Ces détails sont cruciaux pour le code de production avec des données complexes.
Architecture hybride de l'analyseur
L'approche optimale combine des étapes :
- Pré-balayage basé sur des motifs pour les candidats.
- Filtrage des cas trivialement sûrs.
- Analyse complète de flux de données pour le reste.
- Priorisation basée sur les chemins confirmés.
- Rétrogradation du rang de ceux non confirmés.
Cela équilibre vitesse et précision.
Le rôle de sa-tests-db dans le développement
L'ensemble sa-tests-db sert de référence externe pour les types d'erreurs correspondant à GOST R 71207-2024. Il détecte les régressions pendant les modifications :
- Métriques : faux positifs, faux négatifs par langage.
- Pas des moyennes agrégées, mais une ventilation par catégories.
Une exécution du 23 mars 2026 a confirmé la qualification pour C, C#, Go, Java, JS, Python.
Points clés à retenir
- Les motifs ne conviennent que pour un filtrage rapide ; le flux de données est essentiel pour la précision.
- L'analyse interprocédurale + flux de contrôle trouve 80 % des chemins réels.
- La sensibilité aux champs réduit le bruit de 30 à 50 % dans les structures.
- sa-tests-db est un test de régression, pas une démonstration ponctuelle.
- GOST exige des métriques par type d'erreur, pas des chiffres généraux.
— Editorial Team
Aucun commentaire pour le moment.