La base de vulnérabilités à travers l'air gap

Une zone isolée ne peut pas joindre la base de vulnérabilités amont, et un canal parallèle pour la mettre à jour contredirait un outil dont le métier est d’être le canal (ADR-0008). La base — et, sur un hôte Linux ou Windows, le binaire de l’analyseur lui-même — voyagent donc comme des ingrédients ordinaires d’une recipe signée, tobby-system, par la même synchronisation, le même support et la même vérification que tout le reste (FR-032).

La recipe tobby-system

La chaîne de qualification du site la cuisine et la signe, comme toute autre recipe — les trust roots de la destination ignorent toute clé autre que celle du site :

apiVersion: recipe.tobby.dev/v1alpha1
kind: Recipe
metadata:
  name: tobby-system
  version: 2026.11.11            # une version par rafraîchissement de la base
spec:
  ingredients:
    - name: trivy-db             # la base de vulnérabilités, schéma 2
      kind: OCIArtifact
      ref: ghcr.io/aquasecurity/trivy-db
      version: "2"
      digest: sha256:…           # épinglé à la cuisson
      artifactType: application/vnd.aquasec.trivy.config.v1+json
    - name: trivy                # l'analyseur, pour les hôtes Linux et Windows
      kind: FileSet
      ref: ghcr.io/aquasecurity/trivy
      version: "0.76.2"
      digest: sha256:…           # l'index multi-plateforme

L’image conteneur embarque déjà l’analyseur épinglé : une instance déployée depuis elle n’a besoin que de la base. Un hôte Windows a besoin d’un FileSet portant trivy.exe à sa racine (empaqueté avec tobby fileset pack depuis l’archive de la release amont, contrôlée contre sa somme de contrôle) et référencé par scan.trivy.ref : l’amont ne publie pas d’image Windows. macOS prend trivy dans le PATH et n’a besoin que de la base.

Seule cette recipe livre : celle qui s’appelle tobby-system, admise avec sa signature vérifiée. L’analyseur et sa base décident de ce qui franchit le reste ; une recipe admise sous un périmètre de confiance assoupli — même nommée tobby-system — ou toute autre recipe ne les fournit donc jamais, quel que soit le dépôt qu’elle nomme. Le dépôt est comparé exactement (le ref relocalisé sous le préfixe de base de l’instance qui a écrit l’enregistrement), jamais par sa fin. Une telle recipe se synchronise comme les autres ; l’analyseur ne la voit simplement pas, et reste en mode dégradé jusqu’à ce que la recipe signée soit enregistrée.

Amorçage, dans l’ordre

1. Zone connectée. Placez tobby-system en premier dans le Retriever : une fois enregistrée, l’analyseur relit ses livraisons, et les recipes suivantes sont analysées dans le même run. Avant cela, toute image est signalée non analysée — et refusée sous une politique bloquante.
2. Synchronisez (miroir : tobby sync --wait). Vérifiez l’indicateur d’analyse de l’écran Retriever, ou les métriques : tobby_scan_scanner_available 1, tobby_scan_db_present 1, tobby_scan_db_age_seconds de quelques heures.
3. Transportez le support et importez-le côté isolé. La vérification et l’import du support (FR-052, FR-054) n’ont pas besoin de la base : une instance de destination qui n’en a pas vérifie et pousse quand même un support.
4. Dans la zone, chaque instance qui récupère depuis la registry de zone place tobby-system en premier dans son propre Retriever, et trouve la base même qui a traversé — même digest, même horodatage de construction, son âge dans chaque rapport.

Tant qu’aucune base n’est présente, le mode dégradé est affiché sur chaque surface (TBY-SCN-003) : bandeau, journal de démarrage, tobby_scan_db_present 0.

La garder fraîche

La base ne vaut que par son dernier transfert. Son âge se mesure depuis l’horodatage de construction qu’elle porte, pas depuis le transfert, et scan.maxDbAge (168 h par défaut) le borne : au-delà, warn signale la péremption sur le rapport, l’interface et tobby_scan_db_stale, tandis que block refuse les éléments analysés avec elle (TBY-SCN-004). Cuisinez une nouvelle version de tobby-system à la cadence qu’implique la borne — hebdomadaire par défaut — et faites-la voyager par le support suivant.

Une base dont la date de construction enregistrée est dans le futur de l’horloge de cette instance — au-delà d’une heure de décalage toléré — n’a pas d’âge qui puisse être établi : elle est traitée comme périmée, avec son propre code (TBY-SCN-008), sur le rapport, le bandeau et tobby_scan_db_stale, et refusée sous block. Vérifiez l’horloge de l’hôte.

Tobby ne garde décompressée que la base courante, dans son répertoire d’état (<state.root>/scanner, jamais sur le store transportable) ; une nouvelle livraison la remplace à la synchronisation suivante. Ce répertoire doit appartenir à l’instance : à l’utilisateur sous lequel Tobby tourne, sans droit d’écriture pour quiconque d’autre ; sinon l’analyseur le refuse et reste en mode dégradé (TBY-SCN-001 dit pourquoi). Une instance sans répertoire d’état décompresse dans un répertoire privé neuf, sous le répertoire temporaire, supprimé à l’arrêt.