← Accueil · Toute la doc · Catalogue de prix

Stacks et langages sur Outscale

Next.js et NestJS, Django, Rails, Laravel, Go, Spring Boot sur Kubernetes, Quarkus, Jakarta EE, .NET, une stack IA avec GPU : les architectures que les équipes font vraiment tourner, posées sur Outscale par bige-ops. Pour chacune, le coût mensuel calculé au catalogue public, les versions à épingler, l’exposition réseau et les failles connues suivies avec OpenCVE.

Startups : livrer vite, sur une base saine

Des stacks très répandues chez les équipes produit, posées en multi-VM derrière un LBU ou sur OKS, avec bases en subnet privé et backups dans OOS.

Grandes entreprises : les architectures du SI

Microservices JVM sur Kubernetes, serveurs Jakarta EE, .NET, Kafka, Keycloak, recherche et IA : des architectures de production, avec control plane haute disponibilité sur OKS et la Région SecNumCloud cloudgouv-eu-west-1 à disposition (régions).

Sur OKS, chaque Service exposé crée un LBU, compté à part à 21,90 € HT par mois l’unité : le tableau donne les deux montants.

Sites et temps réel

Langages et frameworks

Ce que bige-ops vérifie, pour toutes les stacks

Des failles, il y en aura toujours : l’important est de voir d’abord celles qui sont exposées. Voici comment bige-ops les cherche, sans rien cacher de la méthode.

1. Il lit le code de tes dépôts, sur ton poste. Les dépôts de ta stack sont copiés sur ta machine et relus là, sans clé ni IA : c’est le « mode direct ». Langages lus : JavaScript, TypeScript, Python, Go, PHP et Ruby ; les tests et les suites e2e sont écartés pour éviter les fausses alertes.
2. Il repère les pages et les API que ton app expose, avec un module par framework (Express, Fastify, Hono, Koa, LoopBack, NestJS, Next.js, tRPC, Django, FastAPI, Flask, net/http, Gin, Laravel, WordPress, Rails), et regarde si chacune demande une connexion : session, jeton, middleware ou décorateur d’authentification juste à côté. Une route marquée publique, ou une page sensible (admin, compte, paiement…) sans aucune vérification visible, ressort comme « page ou API accessible sans être connecté ».
3. Il cherche les erreurs classiques dans le code : mots de passe ou clés écrits en clair dans le code, requête à la base construite avec ce que tape l’utilisateur (injection SQL), exécution de commandes construites avec des données externes, code injecté qui s’exécute dans le navigateur de tes utilisateurs (XSS), API ouverte à n’importe quel site, vérification des certificats HTTPS désactivée.
4. Il compare tes bibliothèques (npm, PyPI, modules Go et Packagist) à la base publique des failles connues des bibliothèques open source (OSV).
5. Avec ta clé OpenCVE, il compare ta stack au registre mondial des vulnérabilités (CVE) : les composants de ta simulation et les images de tes Dockerfile et docker-compose (détail ci-dessous).
6. Il classe tout par urgence : ce qui est exposé à Internet d’abord.

En mode direct, ton code ne quitte pas ton poste : vers OSV et OpenCVE ne partent que des noms de bibliothèques et de composants (avec leur version, pour OSV). Pourquoi le refaire toi-même ? C’est chez toi, sur ton poste, et c’est gratuit.

Pour Java, .NET, Kotlin, Scala, Rust, Elixir et OCaml, la lecture du code arrive ; leurs stacks sont déjà couvertes : composants et images comparés aux failles connues avec OpenCVE, exposition et coût.

La stack, avec OpenCVE. Les composants de ta simulation sont rapprochés automatiquement de leur fiche OpenCVE quand bige-ops les reconnaît : PostgreSQL, MySQL, MariaDB, MongoDB, Redis, nginx, Node.js, Python, Go, Kubernetes, Docker. Les autres briques (Kafka, Keycloak, RabbitMQ, NATS, OpenSearch, frameworks…) ont leurs fiches de référence sur chaque page.

Avec ta clé API OpenCVE (Settings), l’onglet Vulnérabilités lit ta simulation : chaque composant reconnu, image Docker ou paquet installé, est rapproché de sa fiche éditeur / produit, à raison d’une requête par produit. Les failles connues qui remontent sont classées par risque :

• Gravité : chaque faille a une note sur 10 (CVSS) ; critique dès 9, haute dès 7, moyenne dès 4. Une faille déjà exploitée par des attaquants (elle figure sur la liste KEV de la CISA, l’agence américaine de cybersécurité) compte au moins comme haute.
• Exposition dans ta simulation : un composant joignable depuis Internet, directement ou derrière le LBU, garde sa gravité ; un composant en subnet privé descend d’un cran, sauf si la faille est déjà exploitée.
• Départage : à risque égal, les failles déjà exploitées d’abord, puis la note sur 10, puis la probabilité d’être exploitée prochainement (EPSS). Le filtre « important » ne garde que les failles déjà exploitées ou notées 7 et plus.

Le rapprochement se fait au niveau du produit, pas de la version : à toi de recouper avec la version que tu as épinglée. Une image en latest ressort en plus comme « version non épinglée ». Le résultat est mis en cache dans la simulation et se rafraîchit à la demande.

L’audit approfondi, en option. bige-ops advanced, avec ta propre clé d’IA, relit plus en profondeur les pistes repérées : il confirme les vraies failles, écarte les fausses alertes et classe chacune par type de faille, selon le catalogue de référence (CWE), avec un ticket GitHub (issue) prêt à ouvrir. Seuls des extraits ciblés de ton code partent, avec ta clé, chez le fournisseur d’IA que tu choisis. L’audit approfondi en détail.

OpenCVE, la source des failles connues

Pour savoir quelles failles connues touchent les briques de ta stack, bige-ops s’appuie sur OpenCVE. OpenCVE rassemble les failles publiées dans le registre mondial des vulnérabilités (CVE) et ses sources officielles (NVD, MITRE, liste KEV des failles déjà exploitées tenue par la CISA, l’agence américaine de cybersécurité…), donne à chacune sa note de gravité sur 10 (CVSS) et sa probabilité d’être exploitée (EPSS), et les range par éditeur et par produit, consultables dans son explorateur. Le projet est open source : son code, ses issues et les contributions de sa communauté vivent sur GitHub, et il s’installe aussi chez toi. Merci à ses mainteneurs et à tous ceux qui font vivre ce référentiel : c’est grâce à eux que chaque composant de ta simulation a sa fiche de failles à jour.

D’où viennent les chiffres

Pour chaque page, un projet bige-ops a été construit avec le bâtisseur de layouts (bige-ops add layout custom …), ajusté (images épinglées, backups, NAT, VMs dédiées), validé par bige-ops validate, puis chiffré par bige-ops estimate --json. Les lignes viennent telles quelles de la CLI : vCPU et RAM des types Tina, disques BSU (io1 à 3 000 IOPS pour les bases), LBU, NAT, IP publiques (la première est offerte), OKS (control plane et nœuds), OOS, GPU. Estimation indicative sur la grille publique ; le détail du calcul est sur catalogue de prix.

Pour aller plus loin : layouts & topologies, VMs, OKS, volumes BSU, OOS, LBU, réseau, régions, bases de données, catalogue de prix.