FrameForge est un PoC pédagogique. Seule la révision courante de la branche
main reçoit des correctifs, au mieux des capacités des mainteneurs. Aucune
garantie de maintenance ou de délai de réponse n’est fournie pour les anciennes
révisions.
N’ouvrez pas d’issue publique contenant un secret, une adresse privée, une preuve d’exploitation ou une donnée personnelle.
Utilisez en priorité le signalement privé de vulnérabilité proposé dans l’onglet Security du dépôt GitHub. Si cette fonction n’est pas disponible, contactez le mainteneur depuis son profil GitHub en demandant un canal privé, sans inclure les détails sensibles dans le premier message.
Le signalement devrait préciser, lorsque cela est possible :
- la révision concernée ;
- le composant et le scénario reproductible ;
- l’impact estimé ;
- une proposition de correction ou de mitigation ;
- si des identifiants ont pu être exposés, sans joindre leur valeur.
Le PoC doit rester sur un réseau de laboratoire privé. Il ne fournit pas les garanties attendues d’un service de production :
- aucune authentification applicative pour l’UI et l’API ;
- HTTP sans TLS de bout en bout ;
- stockage sans chiffrement au repos ;
- aucune sauvegarde hors site ni restauration automatisée ;
- un seul hôte physique et une seule instance de chaque composant de données ;
- noms
nip.iodestinés uniquement à la démonstration.
Prometheus utilise un compte de service dédié avec get sur nodes/proxy afin
de lire cAdvisor au travers de l'API Kubernetes. Ce droit donne accès à une
surface de proxy plus large qu'un seul chemin de métriques ; Trivy KSV-0047
est donc ignoré uniquement sur ce ClusterRole, avec une justification accolée
au manifeste. Aucun composant applicatif ne reçoit ce droit. Une cible de
production doit le remplacer par un plan de métriques géré ou un collecteur
isolé dont l'interface est limitée aux mesures nécessaires.
Ces limites documentées ne sont pas des vulnérabilités inconnues. Une possibilité de contourner les contrôles de réseau privé, d’extraire les Secrets Kubernetes, d’exécuter du code hors du conteneur ou d’accéder à un média sans URL signée reste en revanche pertinente à signaler.
- Ne placez jamais de secret réel dans un fichier suivi par Git, même pour un test temporaire.
- Les fichiers
.envréels, le kubeconfig, les vidéos etevidence/runtime/restent locaux et ignorés. - Si une valeur réelle est commise, révoquez-la immédiatement. Réécrire l’historique ne remplace jamais la révocation.
- La CI analyse tout l’historique Git atteignable avec Gitleaks et contrôle les dépendances, les manifestes et les images avec npm audit et Trivy.
- Les deux entrées de
.gitleaksignoresont des fingerprints liés à un commit, un chemin, une règle et une ligne précis. Elles couvrent uniquement les littéraux<S3_SECRET_ACCESS_KEY>des deux fichiers.env.example; aucune règle générale ou valeur réelle n’est autorisée. - Une publication doit être effectuée depuis un clone propre créé avec
git clone --no-local --single-branch, jamais depuis une copie du répertoire.gitde travail ou de son reflog.
Avant toute adaptation hors laboratoire, ajoutez au minimum une authentification, TLS, une gestion externe des secrets, du chiffrement au repos, des sauvegardes testées et une architecture multi-nœuds. N’exposez pas directement les Ingress du PoC sur Internet.