💻 computer science

Project-wise Comparison of Software Birthmarks Using Weighted Partial Similarity

Ce document propose un cadre de comparaison de signatures logicielles par projet qui emploie l'agrégation pondérée et des mécanismes de similitude partielle pour détecter de manière robuste la réutilisation partielle de code et atténuer les faux positifs causés par de petits modules, démontrant une performance supérieure aux méthodes existantes à travers divers projets Java open-source.

Auteurs originaux : Nikolay Fedorov, Akito Monden, Hiroki Inayoshi, Haruaki Tamada, Masateru Tsunoda

Publié 2026-06-30

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Nikolay Fedorov, Akito Monden, Hiroki Inayoshi, Haruaki Tamada, Masateru Tsunoda

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un détective tentant de résoudre une affaire de plagiat de logiciels. Quelqu'un a pris un morceau de code provenant d'un projet open-source, l'a légèrement modifié, et l'a revendiqué comme le sien. Votre tâche est de prouver qu'il a volé.

Dans le passé, les détectives (chercheurs) abordaient ce problème un fichier à la fois. Ils comparaient le Fichier A du Projet X avec le Fichier B du Projet Y. S'ils présentaient des similitudes, ils les signalaient.

Mais un logiciel réel est comme une immense bibliothèque, pas un simple livre unique. Un projet peut comporter des milliers de fichiers. Souvent, un voleur ne dérobe que un ou deux chapitres (modules) d'un livre et les insère dans sa propre encyclopédie massive. Si vous comparez l'encyclopédie entière à l'original, les chapitres volés se perdent dans le bruit. De plus, il arrive que deux bibliothèques complètement différentes partagent quelques mots génériques (comme "le" ou "et"), ce qui peut tromper le détective en lui faisant croire qu'il s'agit du même livre.

Cet article présente une nouvelle façon plus intelligente de comparer des projets logiciels entiers pour attraper ces voleurs. Voici comment ils ont procédé, expliqué simplement :

1. Le Problème : L'aiguille dans la botte de foin et la fausse alerte

Les auteurs ont identifié deux problèmes majeurs avec les anciennes méthodes :

L'aiguille dans la botte de foin (Réutilisation partielle) : Si un projet possède 1 000 fichiers et que seulement 10 ont été volés, regarder la similitude moyenne de l'ensemble des 1 000 fichiers dilue la preuve. Le "signal" de vol est noyé par les fichiers "propres".
La fausse alerte (Similitude accidentelle) : De petits fichiers génériques (comme un simple "Hello World" ou une fonction utilitaire de base) peuvent sembler similaires par pur hasard. Si vous traitez un minuscule fichier de 5 lignes de la même manière qu'un fichier massif de 5 000 lignes, ce petit fichier peut créer une fausse alerte, faisant passer deux projets innocents pour des jumeaux.

2. La Solution : Une stratégie de détective en deux étapes

Les auteurs ont proposé un nouveau cadre qui agit comme un filtre intelligent. Ils n'ont pas seulement regardé les fichiers ; ils ont regardé le poids des fichiers et ont ignoré le bruit.

Étape A : La "Balance de poids" (Pondération)

Imaginez que vous comparez deux paniers de fruits. L'un contient une énorme pastèque, et l'autre une minuscule grappe de raisin.

Ancienne méthode : Compte le raisin et la pastèque comme "1 fruit" chacun.
Nouvelle méthode : Réalise que la pastèque est beaucoup plus significative. Elle donne un "poids" important à la pastèque et un poids léger au raisin.

Dans leur logiciel, ils ont attribué une importance plus grande aux modules de code plus volumineux. Si un petit fichier ressemble à un autre petit fichier, le système dit : "C'est probablement une coïncidence ; ignorez-le." Mais si un fichier énorme et complexe ressemble à un autre, le système prête une attention particulière. Cela empêche les "fausses alertes" causées par des fichiers minuscules et génériques.

Étape B : La règle du "Top 1 %" (Similitude partielle)

Imaginez que vous cherchez une chanson spécifique dans une playlist de 1 000 chansons. Vous ne voulez pas écouter toute la playlist pour trouver la correspondance ; vous voulez juste entendre les quelques meilleures chansons qui ressemblent à votre cible.

Ancienne méthode : Calcule la moyenne de la similitude de chaque paire de fichiers entre deux projets.
Nouvelle méthode : Dit : "Regardons uniquement le top 1 % à 5 % des paires de fichiers les plus similaires."

En se concentrant uniquement sur les "meilleures correspondances" et en ignorant le reste, le système ignore les milliers de fichiers non liés qui n'ont pas d'importance. Cela permet de repérer beaucoup plus facilement "l'aiguille" (le code volé), même s'il ne s'agit que d'une petite partie d'un projet immense.

3. L'Expérience : Tester le nouveau détective

Pour prouver que cela fonctionne, les chercheurs ont construit un laboratoire de test :

Les Sujets de test : Ils ont rassemblé 35 projets Java réels (comme des lecteurs multimédias, des éditeurs de texte et des outils de test) provenant de GitHub.
La Configuration : Ils ont traité différentes versions du même projet comme des cas de "vol" (puisque les nouvelles versions ne sont que d'anciennes versions modifiées). Ils ont traité différents projets de la même catégorie (par exemple, deux lecteurs multimédias différents) comme des cas "innocents".
La Métrique : Ils ont mesuré deux choses :
1. Résilience : Peut-il encore trouver le code "volé" même si le voleur l'a modifié ?
2. Crédibilité : Peut-il dire correctement "Non, ces deux-là sont différents" lorsqu'ils le sont réellement.

4. Les Résultats : La nouvelle méthode gagne

Les résultats étaient clairs :

La nouvelle méthode (Pondération + Focus sur le Top 1 %) était significativement meilleure que toutes les méthodes existantes.
Elle était très stable (résultats cohérents) et faisait rarement des erreurs.
Curieusement, ils ont découvert que la symétrie importait. Si vous comparez le Projet A au Projet B, le score doit être le même que si vous comparez B à A. Leur nouvelle méthode garantissait cet équilibre, là où les anciennes méthodes échouaient.
Ils ont également découvert que la Distance d'Édition (une façon de mesurer le nombre de changements nécessaires pour transformer une chaîne en une autre) était le meilleur outil pour comparer les extraits de code réels.

L'essentiel à retenir

Ce document ne dit pas seulement "nous avons trouvé une meilleure façon de compter le code". Il dit : "Pour attraper un voleur qui n'a dérobé que quelques pages d'une bibliothèque, vous devez ignorer les pages minuscules et génériques et vous concentrer uniquement sur les chapitres lourds et complexes qui correspondent."

En accordant plus de poids aux gros fichiers et en ne regardant que les meilleures correspondances, ce nouveau cadre rend la tâche beaucoup plus difficile pour les plagiaires qui tentent de cacher leur vol dans un océan de code, et rend beaucoup plus difficile l'accusation injuste de projets innocents.

Résumé Technique : Comparaison par projet de signatures logicielles (software birthmarks) utilisant la similitude partielle pondérée

Énoncé du problème
Les signatures logicielles (software birthmarks) sont des caractéristiques intrinsèques des programmes utilisées pour détecter le plagiat et la réutilisation non autorisée de code. Bien que les mesures de similitude existantes soient efficaces au niveau du module (par exemple, en comparant des fichiers sources ou des classes individuels), elles sont insuffisantes pour les écosystèmes logiciels réels à grande échelle, où les systèmes sont composés de nombreux modules. Deux défis primaires se posent lors de l'agrégation des comparaisons de modules au niveau du projet :

Réutilisation partielle : Dans de nombreux cas, seule une partie des modules d'un projet est réutilisée, tandis que la majorité reste sans rapport. L'agrégation uniforme de tous les couples de modules dilue le signal de la réutilisation réelle.
Similitude accidentelle : Les modules de petite taille ou génériques peuvent présenter une similitude élevée par hasard entre des projets non liés. Lorsqu'ils sont traités de la même manière que les modules plus importants, ces correspondances « bruitées » peuvent entraîner des faux positifs, compromettant la crédibilité de la détection.

Les méthodes actuelles de comparaison par projet échouent souvent à traiter ces problèmes de manière systématique, manquant de mécanismes robustes pour distinguer la réutilisation partielle significative du bruit accidentel.

Méthodologie
Les auteurs proposent un cadre de comparaison de signatures par projet qui agrège les similitudes de modules en utilisant deux mécanismes complémentaires : l'Agrégation Pondérée et la Similitude Partielle.

Agrégation Symétrique (AS) : Le cadre établit une méthode de base d'agrégation symétrique. Contra à les approches asymétriques précédentes, l'AS calcule la moyenne des scores de similitude les plus élevés trouvés pour chaque module du Projet A contre le Projet B, et vice versa. Cela garantit que le score de similitude est indépendant de l'ordre des entrées.
Assignation de Poids : Pour atténuer la similitude accidentelle des petits modules, les auteurs assignent des poids aux modules basés sur leur taille (spécifiquement, le nombre de $k$ -grammes). Une transformation logarithmique ( $W = \ln(K)$ ) est appliquée pour compresser la plage de poids, empêchant les modules extrêmement volumineux de dominer le score tout en réduisant l'influence des petits modules bruyants. La similitude pondérée finale entre deux modules est le produit de leur similitude brute et du minimum de leurs poids normalisés.
Similitude Partielle : Pour traiter la réutilisation partielle, le cadre se concentre uniquement sur la fraction supérieure ( $\alpha\%$ ) des scores de similitude pondérés les plus élevés entre les paires de modules. En ignorant la masse des paires de modules non liés, cette méthode met l'accent sur les composants réutilisés les plus pertinents.
Métriques d'Évaluation : La performance est évaluée par la Résilience (la capacité à détecter le code réutilisé malgré les modifications) et la Crédibilité (la capacité à distinguer des projets développés indépendamment). Celles-ci sont combinées via leur moyenne harmonique ( $H_{mean}$ ) afin d'assurer un équilibre entre la détection des vrais positifs et l'évitement des faux positifs.

Configuration Expérimentale
L'étude utilise un ensemble de données de 35 projets Java open-source répartis dans 10 catégories. Les cas de réutilisation sont simulés en comparant différentes versions d'un même projet, tandis que les cas de non-réutilisation sont formés en comparant différents projets au sein d'une même catégorie. Les expériences utilisent des signatures statiques de $k$ -grammes et évaluent diverses fonctions de similitude de modules (par exemple, Cosine, Jaccard, Distance d'Édition) ainsi que diverses configurations de paramètres.

Résultats Clés

Supériorité de la méthode proposée : La méthode proposée (combinant la pondération et la similitude partielle avec une portée de 1 %) surpasse systématiquement les approches existantes, y compris la méthode de base de Lee et al. et les variantes précédentes de similitude agrégée. Elle atteint la $H_{mean}$ médiane la plus élevée (0,9728) avec une faible variance.
Nécessité de la pondération : La pondération est critique. Lorsque la similitude partielle est appliquée sans pondération, la performance se dégrade considérablement (passant même en dessous de la similitude aléatoire dans certaines configurations) car les petits modules dominent les paires les mieux classées. La pondération supprime ce bruit, stabilisant les résultats.
Efficacité de la Similitude Partielle : Se concentrer sur un petit sous-ensemble de paires de modules hautement similaires (par exemple, le top 1 % ou 5 %) donne de meilleurs résultats que de considérer toutes les paires. Cela confirme qu'ignorer les modules non liés est essentiel pour détecter la réutilisation partielle.
Configurations Optimales : La meilleure performance est obtenue avec de petites portées de comparaison (1–5 %), des tailles de $k$ -grammes plus grandes (3–4) et la fonction de similitude de Distance d'Édition, qui a démontré la plus haute précision et stabilité parmi les fonctions testées.
Base d'Agrégation Symétrique : Même sans pondération ni similitude partielle, la formulation de l'agrégation symétrique elle-même surpasse les méthodes asymétriques existantes, fournissant une base solide pour la comparaison par projet.

Signification et Revendications
L'article affirme établir un cadre robuste pour la comparaison de signatures par projet qui répond aux limitations spécifiques de l'analyse au niveau du module dans les systèmes à grande échelle. Les auteurs affirment que :

La similitude par projet est une composante nécessaire pour la première étape de la détection de plagiat à grande échelle (la recherche/retrieval), précédant la vérification détaillée au niveau du module.
La combinaison de la pondération basée sur la taille et de la similitude partielle est un mécanisme complémentaire qui améliore conjointement la résilience aux modifications de code et la crédibilité dans la distinction de projets non liés.
Une similitude par projet efficace ne nécessite pas de stratégies de correspondance complexes ; au contraire, une simple combinaison d'agrégation symétrique, de poids sensibles à la taille et d'une focalisation sélective sur les paires de haute similitude offre une solution pratique et robuste.
Le cadre proposé est général et applicable à divers types de signatures, bien que cette étude le valide spécifiquement à l'aide de signatures de $k$ -grammes statiques sur des projets Java.

Les auteurs reconnaissent des limites, notant que l'ensemble de données est composé de projets Java open-source et ne comprend pas de cas de plagiat réels confirmés ou de code obscurci de manière adverse. Ils positionnent leur travail comme une évaluation systématique des stratégies d'agrégation de similitude, avec des travaux futurs prévus pour étendre l'étude à d'autres langages et étudier la robustesse face à l'obscurcissement.