Détection de bugs C++ · Logiciel développé en Suisse

De vrais bugs prouvés par un test exécuté chez vous.

VaultLens cherche les bugs de votre code C++, puis tente de prouver chacun en compilant votre projet et en exécutant un test, sur votre propre machine. Un bug reproduit arrive avec sa preuve et les autres sont signalés comme moins sûrs.

Prouvé
Un bug est « reproduit » quand un test écrit par VaultLens l’a fait échouer pour de vrai.
Vérifiable
Votre développeur peut vérifier lui-même fichiers, lignes, tests, commandes et sorties.
Chez vous
VaultLens s’installe et s’exécute sur votre machine d’analyse.

01

Comment ça marche

Les analyseurs classiques signalent beaucoup de problèmes, dont beaucoup de faux. VaultLens prend le chemin inverse, des agents d’IA cherchent et chaque piste est confrontée à une exécution réelle sur votre projet.

  1. 01

    Chercher

    Des agents d’IA parcourent votre code C++ à la recherche de bugs. À ce stade, ce ne sont que des pistes.

  2. 02

    Vérifier en exécutant

    Pour chaque piste, VaultLens compile votre projet, écrit un test, l’exécute et rejoue la preuve. Le test doit réellement échouer, en plantant, en déclenchant une erreur mémoire ou un blocage, ou en donnant un résultat contraire à ce que prévoit la documentation.

  3. 03

    Livrer la preuve

    Chaque bug reproduit arrive avec le fichier et la ligne, une explication courte, le test, la commande lancée et la sortie qui échoue. Votre développeur peut la relancer lui-même.

02 — Exemple

À quoi ressemble un bug livré.

Exemple fictif, code inventé. Chaque fiche réunit les mêmes éléments : le niveau de confiance, l’endroit exact, l’explication, le test, la commande et la sortie qui échoue.

BUG-0042 Échec reproduit Atteint par une vraie entrée

Lecture hors limites dans FrameDecoder::payload()

Erreur mémoire · heap-buffer-overflow, lecture de 512 octets

src/codec/frame_decoder.cpp:88

Explication

payload() lit la longueur du contenu dans l’en-tête de la trame, puis copie ce nombre d’octets sans le comparer à la taille réellement reçue. Une trame courte qui annonce un long contenu fait lire la mémoire au-delà du tampon.

Pourquoi « Atteint par une vraie entrée »

Le test appelle FrameDecoder::decode(), le point d’entrée public, avec une trame de 8 octets : ce qu’un émetteur quelconque pourrait envoyer.

Code concerné

std::vector<uint8_t> FrameDecoder::payload(const uint8_t* data,
                                            size_t size) const {
    if (size < kHeaderSize) {
        return {};
    }
    const uint16_t len = read_u16_le(data + 2);
    std::vector<uint8_t> out(len);
    std::memcpy(out.data(), data + kHeaderSize, len);
    ↑ len vient de l’en-tête et n’est jamais comparé à size
    return out;
}

Test écrit par VaultLens

// Passe par l'API publique, comme une trame reçue.
#include "codec/frame_decoder.h"
#include <cstdint>
#include <vector>

int main() {
    // 8 octets reçus, l'en-tête en annonce 512.
    std::vector<uint8_t> frame = {0xA5, 0x01, 0x00, 0x02,
                                  0x10, 0x20, 0x30, 0x40};
    codec::FrameDecoder decoder;
    decoder.decode(frame.data(), frame.size());
    return 0;
}

Commande lancée

C:\analyse\projet> cmake --build build --config Debug --target frame_decoder_payload_overflow
C:\analyse\projet> build\vaultlens_tests\Debug\frame_decoder_payload_overflow.exe

Rejeu

La même commande, relancée, produit le même échec à la même ligne. Vous pouvez la relancer vous-même.

Sortie qui échoue (extrait)

=================================================================
==7316==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x11f0a2be0018 at pc 0x7ff7d1c2b3e4 bp 0x00a3c7cff1a0 sp 0x00a3c7cff1a8
READ of size 512 at 0x11f0a2be0018 thread T0
    #0 0x7ff7d1c2b3e3 in __asan_memcpy
    #1 0x7ff7d1c1a4f6 in codec::FrameDecoder::payload C:\analyse\projet\src\codec\frame_decoder.cpp:88
    #2 0x7ff7d1c19d01 in codec::FrameDecoder::decode C:\analyse\projet\src\codec\frame_decoder.cpp:41
    #3 0x7ff7d1c11085 in main C:\analyse\projet\vaultlens_tests\frame_decoder_payload_overflow.cpp:11

0x11f0a2be0018 is located 0 bytes after 8-byte region [0x11f0a2be0010,0x11f0a2be0018)
allocated by thread T0 here:
    #0 0x7ff7d1c2c8a1 in operator new
    #1 0x7ff7d1c1104b in main C:\analyse\projet\vaultlens_tests\frame_decoder_payload_overflow.cpp:8

SUMMARY: AddressSanitizer: heap-buffer-overflow C:\analyse\projet\src\codec\frame_decoder.cpp:88 in codec::FrameDecoder::payload
…
Niveau : Échec reproduit Badge : Atteint par une vraie entrée Pour vérifier : relancer les deux commandes ci-dessus

Maquette fictive : le code, les chemins et les adresses sont inventés pour l’illustration.

Les niveaux de confiance affichés

Chaque fiche indique ce qui a été prouvé, et comment.

Échec reproduit
VaultLens a fait échouer le code pour de vrai, par un test qu’il a lui-même exécuté.
Atteint par une vraie entrée
Badge ajouté quand le bug est atteint comme un vrai utilisateur le ferait.
Suspecté
Probable, mais pas reproduit.
À examiner
Le juge (l’IA de VaultLens chargée de trier les pistes) n’a pas su trancher.

03 — Sécurité

Une analyse confidentielle, sous votre contrôle.

  • Sur votre machine d’analyse

    VaultLens est installé et s’exécute sur votre machine d’analyse.

  • Un modèle chez vous, ou en Suisse

    Le modèle d’IA tourne sur votre propre serveur, ou sur un serveur dédié en Suisse.

  • Une machine dédiée

    L’analyse a sa place sur une machine dédiée ou une machine virtuelle.

Schéma : sur votre machine d’analyse, VaultLens compile votre projet C++ et exécute les tests. Il s’appuie sur un serveur de modèle d’IA, qui est le vôtre ou un serveur dédié en Suisse.

Votre machine d’analyse

Votre code C++ sur votre machine
VaultLens compile et exécute les tests
Serveur de modèle d’IA le vôtre, ou dédié en Suisse

Ce site n’utilise aucun cookie de suivi, aucun traqueur, et ne charge ni police ni script depuis un autre serveur.

04 — Résultats

Ce que nous avons mesuré.

Sur deux projets C++ open source. Chaque bug a été vérifié de façon indépendante, à l’aveugle, et reproduit quand c’était possible. Méthode détaillée sur demande.

libzmq

≈ 55 %

des bugs signalés étaient vrais, soit 26 bugs vrais distincts.

SRT

≈ 65 %

des bugs signalés étaient vrais, soit 20 bugs vrais distincts.

clang-tidy et cppcheck

≈ 0 sur 30

Les analyseurs classiques, sur les mêmes projets : environ 0 vrai bug dans 30 alertes tirées au hasard.

Confirmation extérieure : 11 des 46 bugs distincts trouvés sur libzmq et SRT ont, depuis la version analysée, été corrigés (5) ou signalés (6) de leur côté par les projets ou leurs contributeurs.

Du code open source n’est pas votre code. Le mieux est de mesurer vous-même, sur le vôtre : c’est le but de l’essai.

05 — L’essai

Commencez par un essai, sur votre code.

Pour commencer

Un essai sur un module de votre choix, sur votre machine

Vous choisissez le module. VaultLens l’analyse chez vous, et vous jugez vous-même les bugs livrés, preuves à l’appui.

Parlons de votre code

Prérequis actuels

  • Du C++ compilé avec CMake, sous Windows
  • Une machine dédiée ou une machine virtuelle, sur laquelle VaultLens s’installe
  • Un serveur de modèle d’IA : le vôtre, ou un serveur dédié en Suisse

Ce que VaultLens ne fait pas

  • Analyser d’autres langages que le C++
  • Garantir de trouver tous les bugs

Ne rien trouver ne veut pas dire que le code est sûr.

06 — FAQ

Questions fréquentes

Quels langages ?

Uniquement le C++. Aujourd’hui, le projet doit se compiler avec CMake, sous Windows.

Combien de temps dure une analyse ?

La durée dépend de la taille du code et du serveur de modèle ; nous l’estimons avec vous avant l’essai.

Faut-il du matériel ?

Oui, deux éléments : une machine d’analyse, dédiée ou virtuelle, sur laquelle VaultLens s’installe, et un serveur qui fait tourner le modèle d’IA (le vôtre, ou un serveur dédié en Suisse).

Où tourne l’analyse ?

VaultLens est installé et s’exécute sur votre machine d’analyse. Le modèle d’IA tourne sur votre propre serveur, ou sur un serveur dédié en Suisse.

L’analyse a sa place sur une machine dédiée ou une machine virtuelle.

Que veut dire « Échec reproduit » ?

VaultLens a fait échouer le code pour de vrai, par un test qu’il a lui-même exécuté (plantage, erreur mémoire, blocage, ou résultat contraire à ce que la documentation prévoit), puis l’a rejoué avec le même échec.

La fiche donne la commande exacte : vous pouvez relancer le test et constater l’échec vous-même.

Tous les bugs livrés sont-ils prouvés ?

Non. Seuls ceux marqués « Échec reproduit » le sont. « Suspecté » veut dire probable mais pas reproduit ; « À examiner », que le juge n’a pas su trancher. Chaque fiche indique son niveau.

07 — Contact

Parlons de votre code

Dites-nous quel module vous aimeriez faire analyser. Nous vous répondons par e-mail.

Par e-mail

contact@vaultlens.ch

Vos informations servent uniquement à vous répondre. Politique de confidentialité.

Tous les champs sont obligatoires, sauf l’entreprise.

Par exemple : le module à analyser et sa taille approximative.