bige-opsTélécharger la bêta ↗Vulnérabilités
Relier les dépôts, les routes et les composants de la stack. bige-ops repère les faiblesses, rapproche les versions des CVE et prépare une action avec son contexte : le code concerné, son exposition et une piste de correction.
Application gratuite · macOS & Linux · Sans IA obligatoire
Le parcours dans l’app
Faire défiler pour suivre chaque étape.
Partir des services déclarés et des dépôts qui leur sont reliés. Choisir la branche à analyser. Les fichiers, les composants détectés et les résultats restent rattachés au commit lu : une autre branche garde son propre état d’analyse.
La couverture dépend des langages, frameworks, fichiers accessibles et limites de scan.
Retrouver les routes détectées par langage et framework, puis remonter au fichier et au service. Distinguer l’exposition publique, privée ou encore inconnue. Cette lecture rapproche les chemins de l’API de la stack réelle, au lieu de traiter toutes les routes comme accessibles sur Internet.
TypeScript/JavaScript, Python, Go, PHP et Ruby disposent de règles de découverte ; la couverture varie selon les frameworks.
Examiner les alertes sur le code, les contrôles d’accès et les secrets détectés. Une faiblesse classée CWE conserve son emplacement et les éléments qui ont déclenché l’alerte. Ouvrir le fichier ou la route permet de comprendre le signal avant de décider quoi corriger.
Une heuristique est un signal à qualifier, pas la preuve automatique d’une exploitation.
Inspecter les paquets et images identifiés dans le périmètre. OSV aide à comparer les dépendances avec les versions affectées ; OpenCVE enrichit les composants reconnus. Conserver la version observée, la plage concernée et les informations disponibles sur une correction.
Une correspondance de nom d’image ne démontre pas que son contenu installé est vulnérable.
Rapprocher la gravité, l’applicabilité et l’exposition de la stack. Une route publique, un service privé et une exposition inconnue ne décrivent pas la même situation. Regrouper les CVE qui partagent une correction et distinguer les résultats applicables des candidats ou des éléments déjà corrigés.
Un réseau privé réduit l’exposition ; il ne corrige pas une vulnérabilité.
Depuis le résultat, créer une issue GitHub avec le dépôt, le commit, la localisation et l’action proposée. Le lien reste attaché à l’alerte. Corriger le code ou la dépendance dans le parcours de développement, puis relancer le scan et les tests sur la version obtenue.
Le scan crée des issues. Les PR de l’agent concernent les fichiers de déploiement autorisés, pas une correction automatique de toutes les CVE.
La cartographie relie la structure du projet au code effectivement analysé.
Express, Fastify, NestJS, FastAPI, Flask, Django, Gin, Laravel ou Rails : les règles reconnaissent des conventions propres aux frameworks. Les routes dynamiques ou non reconnues restent une limite de couverture.
Un contrôle détecté, absent ou inconnu fournit un point de départ pour l’audit. Le code et le chemin d’exécution déterminent la protection réelle ; le nom d’une route ne suffit pas.
Un résultat garde son dépôt, sa branche et son commit. La correction doit être rescannée sur le code obtenu, sans réutiliser comme preuve un ancien résultat d’une autre branche.
La page doit permettre de lire le résultat sans être expert des acronymes.
Une requête construite avec une entrée utilisateur, une route mal protégée ou une gestion risquée des données relève d’une famille de faiblesse. Le résultat doit conserver son fichier, sa ligne et la raison de l’alerte.
Le nom du paquet ne suffit pas. La version observée, la plage affectée et les éléments disponibles sur la correction déterminent si une vulnérabilité connue peut concerner le projet.
Une valeur sensible présente dans le code ou une exposition mal comprise demande une action différente d’une mise à jour de dépendance. Les catégories restent séparées pour préparer la bonne intervention.
Le même signal n’a pas la même priorité selon l’endroit où il apparaît.
Les routes et résultats restent liés au périmètre analysé. Revenir sur une autre branche ne doit pas mélanger ses données avec celles d’une analyse précédente.
L’arbre et le graphe permettent de remonter au service, au fichier et à la route. Une exposition Internet, privée ou inconnue est conservée comme contexte, sans transformer une incertitude en confirmation.
Comprendre l’exposition réseau ↗Les résultats applicables, candidats, corrigés ou non affectés ne sont pas présentés comme également urgents. Les filtres permettent de revoir le catalogue complet sans perdre la sélection de travail.
Les sources renforcent le contexte. Elles ne remplacent pas la preuve dans le projet.
Le scan utilise les avis disponibles pour relier les dépendances à leurs plages affectées et à des versions corrigées candidates. Un manifeste peut décrire une intention ; la version réellement résolue compte pour conclure.
Consulter OSV ↗OpenCVE apporte des informations sur les CVE liées aux images et composants. Une correspondance de catalogue reste à qualifier avec la version et le contexte de la stack.
Consulter OpenCVE ↗Les captures réelles de la page utilisent une application volontairement vulnérable. Elles montrent comment une alerte mène à une route, au code et à une action. Ce laboratoire n’est pas une preuve que tous les cas de production sont couverts.
Découvrir OWASP Juice Shop ↗Détecter ne clôt pas le problème ; il faut conserver le fil jusqu’à sa vérification.
Le brouillon rassemble la localisation, le commit, les éléments observés, l’impact et l’action proposée. Les failles qui partagent une correction peuvent être regroupées plutôt que multiplier les tickets sans contexte.
Le parcours Vulnérabilités crée une issue documentée. L’agent sait ouvrir une PR confirmée pour les fichiers de déploiement autorisés — Dockerfile, .dockerignore et .bige-ops — sur une branche dédiée. Il ne promet pas de réécrire arbitrairement le code applicatif pour résoudre chaque alerte.
Voir le périmètre de l’agent ↗Une version suggérée est une candidate. Après une modification, relancer le scan et les tests sur la version effectivement obtenue. La création d’une issue n’a pas valeur de correction.
Le Deep audit est un parcours optionnel : modèle, effort et volume de contexte sont choisis. Il complète le scan à partir des annotations et routes transmises, sans rendre l’IA obligatoire ni garantir l’absence de faux positifs.
Choisir une stack, c’est aussi vérifier les conditions d’usage de ses composants.
La licence peut compter dans une décision d’hébergement ou de distribution. Elle ne doit pas être colorée comme une vulnérabilité ni confondue avec une CVE.
Le scan de sécurité présenté ici n’est pas un audit juridique ni une certification de conformité des licences. La revue s’effectue selon les composants et l’usage envisagé.
Dans l’app
La sélection conserve le dépôt, le commit, la route et le fragment concerné. Le visiteur voit ce qu’il pourra examiner avant de préparer une correction.
Dans l’app
Le détail d’une dépendance montre les éléments nécessaires à la qualification. La capture signale aussi ce qui reste à déterminer : le catalogue seul ne décide pas de l’applicabilité.
Pour aller plus loin
La capture montre l’analyse d’une application délibérément vulnérable : une route, une faiblesse et son contexte de code. Un exemple concret du parcours, pas une certification de sécurité.
Découvrir OWASP Juice Shop ↗Les sources complètent les éléments observés dans la stack. Version installée, plage affectée et informations disponibles restent nécessaires pour juger l’applicabilité d’une CVE.
Découvrir OpenCVE ↗Les licences des composants, dont la SSPL, demandent une revue adaptée à l’usage envisagé. Elles ne sont pas des vulnérabilités. Le scan ne constitue pas une validation juridique de la stack.
Lire le périmètre de la bêta ↗Le scan de base fonctionne sans IA obligatoire. Un audit approfondi assisté peut compléter l’analyse ; il ne remplace ni les preuves du scan, ni la revue, ni les tests de correction.
Non. Les résultats distinguent ce qui est observé, applicable, candidat ou encore inconnu. Les heuristiques de code et les correspondances de catalogue exigent une qualification. L’absence d’alerte n’est pas une garantie de sécurité.
Non. Elle rassemble les éléments pour le traiter : dépôt, commit, emplacement, contexte et action proposée. L’équipe relit, corrige puis teste et relance l’analyse. Les résultats d’une correction ne sont pas déduits de la seule création d’un ticket.
Installer l’app gratuite. Commencer par une simulation, avant d’engager des ressources cloud.
Télécharger bige-ops ↗