Pourquoi Repod ?¶
Le problème avec « juste utiliser un serveur de dépôt »¶
La plupart des équipes découvrent à leurs dépens qu'un dépôt APT nu n'est pas un contrôle de sécurité — c'est un serveur de fichiers. Vous pouvez dire exactement ce qu'il y a dedans, mais vous ne pouvez pas répondre aux questions que votre RSSI ou un auditeur NIS2 vous posera :
- Qui a autorisé ce paquet à entrer dans l'infrastructure ?
- Quand la CVE de cette bibliothèque a-t-elle été acceptée — et pourquoi ?
- Quels paquets contiennent en ce moment des vulnérabilités du type Log4Shell ?
- Quels composants logiciels tournent sur vos machines de production ?
Les solutions génériques (Nexus, Aptly, un simple dossier Nginx) ne répondent à aucune de ces questions par défaut.
L'approche Repod¶
Repod a été conçu autour d'une idée unique : chaque paquet doit être justifié.
Chaque .deb qui entre dans Repod passe par un pipeline automatisé en 6 étapes avant de pouvoir être servi aux clients. Si une CVE critique est détectée, le paquet n'est pas publié discrètement avec un avertissement jaune — il entre dans une file de revue RSSI où un humain doté du contexte et de l'autorité nécessaires tranche, rédige une justification, et la décision est journalisée de façon permanente.
Upload reçu
│
▼
[1] Validation du format rejet si malformé
▼
[2] Vérification de provenance SHA-256 rejet si altéré
▼
[3] Scan antivirus mise en quarantaine si infecté
▼
[4] Analyse CVE + enrichissement EPSS/KEV blocage / revue / avertissement
▼
[5] Vérification de la signature GPG rejet si invalide
▼
[6] Résolution des dépendances avertissement si dépendances manquantes
▼
Publié — ou en attente d'approbation de la revue sécurité
Principes fondamentaux¶
-
Sécurité par défaut, pas par configuration
Le pipeline s'exécute à chaque upload. Il n'existe aucun moyen de le contourner sans modifier le code source. Le scan antivirus, l'analyse CVE et la vérification GPG ne sont pas des plugins optionnels — ils font partie du cœur du système.
-
Visibilité totale, en permanence
19 types d'événements journalisés dans des fichiers JSONL en ajout seul. Chaque connexion, upload, décision CVE, changement de configuration et mise à jour antivirus est enregistré avec horodatage, utilisateur, rôle et adresse IP source.
-
Séparation des responsabilités
Les pipelines CI/CD obtiennent le rôle
uploader— ils peuvent pousser des paquets mais pas approuver les CVE. Votre RSSI obtientauditor— un accès en lecture aux files et aux journaux, sans accès en écriture. Personne n'obtient plus que ce dont il a besoin. -
Le vôtre, entièrement
Auto-hébergé, compatible air-gap, sans télémétrie, sans dépendance à un éditeur. Les données ne quittent jamais votre infrastructure. Exécutez-le sur une VM, un serveur bare-metal ou un cluster Kubernetes.
À qui s'adresse Repod¶
| Public | Problème résolu par Repod |
|---|---|
| Équipes DevOps / Plateforme | Remplacer les workflows scp + dpkg -i ad hoc par un dépôt gouverné et auditable, qui s'intègre à n'importe quel outil CI/CD |
| RSSI / Équipes sécurité | Obtenir une file de revue pour les paquets signalés par une CVE, un SBOM pour chaque artefact, et une piste d'audit immuable pour les auditeurs |
| Industries réglementées (banque, santé, défense, secteur public) | Répondre aux exigences de sécurité de la chaîne d'approvisionnement de l'article 21 de NIS2 et aux directives ANSSI SecNumCloud, sans dépendance au cloud |
| Ingénieurs plateforme construisant des plateformes développeur internes | Fournir un workflow de publication de paquets en self-service, avec une gouvernance intégrée |
Ce qui distingue Repod¶
La file de revue RSSI¶
Aucun autre gestionnaire de dépôt APT open source n'a de workflow de revue de sécurité dédié. Quand une CVE Critique ou Haute est détectée (selon votre politique), le paquet n'est pas simplement signalé — il est mis en quarantaine, une notification part vers l'équipe sécurité, et la publication est bloquée jusqu'à ce qu'un humain prenne une décision explicite avec une justification écrite.
Cette justification devient partie intégrante de l'enregistrement d'audit permanent. Si vous êtes audité 18 mois plus tard, vous pouvez prouver que oui, vous connaissiez la CVE-2024-XXXX, que vous l'avez acceptée à une date précise, pour une raison précise, revue par une personne précise.
Contexte EPSS + CISA KEV¶
Un score CVSS vous indique la sévérité. EPSS vous indique la probabilité d'exploitation dans les 30 prochains jours. CISA KEV vous indique si elle est activement exploitée en ce moment même. Repod expose les trois pour chaque CVE — donnant à votre RSSI le contexte nécessaire pour prendre des décisions informées plutôt que de deviner à partir d'un chiffre.
Le SBOM comme fonctionnalité de premier plan¶
Chaque paquet dispose d'un Software Bill of Materials. Exportez le SBOM complet du dépôt en CycloneDX 1.5 ou SPDX 2.3 en un seul appel API. Ce n'est pas une fonctionnalité rapportée après coup — la génération du SBOM fait partie du pipeline d'ingestion.
Un seul pipeline, pas un par format¶
Le même pipeline en 6 étapes — antivirus, CVE, EPSS/KEV, file de revue, SBOM — s'exécute
que l'artefact soit un .deb, un jar Maven, une wheel PyPI, un paquet npm, ou
une image de conteneur. La plupart des équipes finissent par gouverner soigneusement leurs paquets OS
tout en traitant tout le reste comme un à-côté ; Repod applique la même exigence
partout. Voir Formats de paquets.
« La plupart des dépôts APT vous disent ce qui est là. Repod vous dit qui l'y a mis, pourquoi cela a été approuvé, et quelles vulnérabilités ont été consciemment acceptées. »