Vérifier qu'aucune donnée ne sort

À la fin de ce tutoriel, vous avez construit l’artefact que reçoit un client et obtenu la preuve, sur ce binaire précis, qu’il ne contient aucun appel réseau sortant.

Le temps se répartit inégalement. Les deux premières étapes installent et construisent le dépôt, une fois pour toutes, et prennent de quelques minutes à une vingtaine selon votre ligne et l’état de votre cache npm. La vérification elle-même, les étapes 3 à 6, prend quelques secondes. L’étape 7, facultative, vérifie le greffon JetBrains et demande à nouveau quelques minutes de construction.

Cette vérification, vous la faites vous-même, sur le produit livré, sans relire le code source. Elle vaut pour les deux façons de déployer Lemniscate, intégré à votre stack ou en assistant de code complet : les artefacts sont les mêmes.

Lemniscate s’engage à n’envoyer aucune donnée à l’éditeur : ni télémétrie, ni erreur, ni vérification de licence. Cet engagement correspond à une absence de code, constatable lors d’un audit (livre blanc sécurité V3, sections 1.3 et 11.3). Ce tutoriel fait ce constat sur les artefacts. Il complète la première des six vérifications que le livre blanc propose au responsable de la sécurité, l’observation du réseau, sans la remplacer : la dernière section les situe.

1. Installer les dépendances

Un npm ci à la racine seul n’installe que les outils de formatage : le dépôt n’est pas un espace de travail npm unique. La chaîne complète est celle-ci, et le contrôle des extraits du dépôt l’exécute.

npm ci
node ./scripts/build-packages.js
npm ci --prefix core
npm run build --prefix core
npm ci --prefix packages/lemniscate-sdk/typescript
npm run build --prefix packages/lemniscate-sdk/typescript
npm ci --include=optional --prefix extensions/cli
npm ci --prefix extensions/vscode
npm ci --prefix gui
npm ci --prefix llm-gateway
npm ci --prefix gateway-admin

2. Construire les autres unités livrables

Le contrôle de l’étape 4 inspecte les six unités livrées : le terminal, l’extension VS Code, l’interface graphique, la passerelle, sa console, et le greffon JetBrains. Il refuse de conclure sur une unité absente : un artefact manquant ne se lit pas comme un artefact propre. Les six doivent donc exister sur votre disque.

Cinq se construisent avec les commandes ci-dessous. Le sixième, le greffon JetBrains, demande une machine virtuelle Java et plusieurs minutes : il a sa propre étape, à la fin, et le contrôle dit lui-même qu’il ne l’a pas regardé tant que vous ne la faites pas.

mkdir -p extensions/vscode/build
(cd extensions/vscode && npm run esbuild-base)
(cd gui && NODE_OPTIONS=--max-old-space-size=6144 npx vite build)
(cd llm-gateway && npm run build)
(cd gateway-admin && npm run build)

npx vite build plutôt que npm run build pour l’interface : le script de construction du dépôt y enchaîne une vérification de types que le contrôle de conformité n’exige pas. La mémoire est relevée parce que la construction de l’interface épuise le tas par défaut de Node et s’arrête sans message.

Ces deux premières étapes sont les seules qui demandent un accès Internet, et les seules qui soient longues. Vous ne les referez pas. Tout ce qui suit s’exécute réseau coupé et se compte en secondes.

3. Construire le terminal, sans préciser de profil

npm run build --prefix extensions/cli

Ne passez aucun profil. Sans instruction, la construction produit l’artefact restreint. Le défaut est fermé.

4. Demander la preuve

node scripts/verify-onprem-artifact.mjs \
  --composant cli --composant vscode --composant gui \
  --composant llm-gateway --composant gateway-admin

Le script inspecte les artefacts qui viennent d’être produits et y cherche les symboles de la couche de sortie réseau. Il s’achève avec succès, et sa dernière ligne commence par « Aucune violation nouvelle ».

Au-dessus, il liste des chemins de sortie encore présents, avec un compte de « dette connue ». Ce n’est pas un échec : le contrôle connaît la liste des chemins qui n’ont pas encore été retirés du produit. Elle est écrite dans scripts/onprem-violations-baseline.json avec, pour chacun, la raison de sa présence. Cette liste ne peut que rétrécir : un chemin qui apparaît sans y figurer fait échouer le contrôle, et un chemin retiré du produit sans que sa ligne soit effacée le fait échouer aussi. La garantie porte sur ce point : aucun reste ne peut s’ajouter sans que vous le voyiez.

Le rapport nomme le greffon JetBrains parmi ce qu’il n’a pas regardé, et précise que les lignes de dette portant sur ce greffon ne sont ni jugées, ni déclarées payées. Le contrôle n’affirme rien d’un artefact qu’il n’a pas ouvert, ni en bien ni en mal. L’étape 7 le lui donne à regarder.

5. Voir le contrôle échouer

Reconstruisez en demandant explicitement le profil ouvert :

LEMNISCATE_DEPLOYMENT_PROFILE=serverless npm run build --prefix extensions/cli
node scripts/verify-onprem-artifact.mjs \
  --composant cli --composant vscode --composant gui \
  --composant llm-gateway --composant gateway-admin

Cette fois le script signale les symboles présents et sort en erreur. Vous avez vu la différence entre les deux artefacts, et constaté que le contrôle la détecte.

6. Revenir à l’artefact fermé

npm run build --prefix extensions/cli

7. Le sixième livrable : le greffon JetBrains

Le greffon est écrit en Kotlin et livré sous forme d’archive, pas de fichier JavaScript. Sa construction demande une machine virtuelle Java 17 et prend plusieurs minutes. La règle est la même : sans profil demandé, vous obtenez l’artefact cloisonné.

(cd extensions/intellij && ./gradlew buildPlugin)
node scripts/verify-onprem-artifact.mjs --composant intellij

L’archive produite se trouve dans extensions/intellij/build/distributions/. La même archive construite en profil ouvert est nettement plus lourde : le profil ouvert y ajoute deux bibliothèques d’émission entières que le profil cloisonné n’embarque pas.

Faites ensuite la contre-épreuve, comme à l’étape 5 :

(cd extensions/intellij && ./gradlew buildPlugin -PprofilDeploiement=serverless)
node scripts/verify-onprem-artifact.mjs --composant intellij

Le contrôle ne reproche pas ses symboles à cette archive : il reconnaît le profil ouvert, refuse de la juger, puis sort en erreur. Un artefact serverless est conforme à ce qui lui est demandé ; sa conformité cloisonnée n’est pas établie, et le contrôle ne prétend pas avoir établi ce qu’il n’a pas vérifié.

Ce que vous avez établi

Le profil restreint s’obtient sans le demander, et un artefact qui contiendrait un appel sortant est détecté par un contrôle qui s’exécute aussi sur chaque proposition de modification du produit.

Pour comprendre ce que ce profil recouvre, lisez Où passent les données.

Les six vérifications du livre blanc

Le livre blanc sécurité V3, section 12.1, propose six vérifications à conduire vous-même. Ce tutoriel porte sur les artefacts ; les six portent sur un déploiement, avec vos propres outils.

Vérification	Ce qu’elle confirme	Sur ce site
T01. Observer le réseau	Aucun flux hors de la matrice de la section 3.3.	Ce tutoriel établit que les artefacts ne portent pas de code d’émission ; l’observation se fait avec vos sondes.
T02. Tenter une sortie réseau depuis un bac à sable	Le confinement : le bac n’a aucune interface réseau.	Les garde-fous d’exécution
T03. Tenter une lecture hors de la copie du dépôt	Le confinement : le périmètre est la copie de travail.	Les garde-fous d’exécution
T04. Charger la SBOM et la VEX dans vos outils	La transparence sur les dépendances.	Chaîne d’approvisionnement
T05. Rejouer une session et la reconstituer depuis les journaux	La traçabilité.	Lire les actes d’une session dans l’onglet Audit
T06. Tenter une injection par le contenu sur un dépôt de test	Un contenu lu n’élargit pas les droits de la session.	Le cycle d’une session agentique