Service
Ingénierie de la sécurité applicative
Une décision de construction, pas une étape avant la mise en service.
Pour les équipes qui ont besoin que la sécurité soit une propriété du logiciel et non un rapport à son sujet. Nous travaillons sur les parties coûteuses à rattraper — autorisation, gestion des sessions, gestion des secrets, risque lié aux dépendances — et nous les démontrons par des tests qui cherchent à casser le système.
La décision
Quand c'est le bon choix.
Une sécurité qui arrive sous forme d'analyse deux semaines avant la mise en service trouve le bon marché et manque le coûteux. Les en-têtes manquants et les bibliothèques obsolètes sont réels mais superficiels. Le contrôle d'accès défaillant — un utilisateur qui atteint l'enregistrement d'un autre client en changeant un identifiant — est la faille grave la plus courante des logiciels métier, et aucun scanner ne la trouve de façon fiable parce qu'elle ressemble en tout point à une requête légitime.
Cette catégorie de faille est un problème d'architecture. Si l'autorisation s'applique en masquant des entrées de menu, ou par un contrôle que certaines routes pensent à appeler, la question n'est pas de savoir s'il y a un trou mais où. Réintroduire un modèle cohérent dans une application terminée est l'un des changements les plus coûteux qui soient.
C'est pourquoi nous en faisons une décision de construction : chaque requête autorisée côté serveur face à l'utilisateur qui agit, des tests qui demandent délibérément les données d'un autre client et vérifient le refus, et des secrets qui n'ont jamais été versés dans le dépôt.
Ce que vous obtenez
Ce que couvre la mission.
Autorisation par défaut
Chaque point d'entrée autorisé côté serveur face à l'utilisateur qui agit, le refus étant la règle par défaut et non l'exception.
Des tests qui attaquent
Des tests automatisés qui demandent les enregistrements d'un autre client, élèvent les rôles et rejouent des jetons expirés, en vérifiant chaque refus. Ils tournent à chaque commit.
Gestion des sessions et des jetons
Expiration, renouvellement et révocation correctement conçus, pour qu'une session expirée se termine proprement au lieu de rejouer indéfiniment.
Gestion des secrets
Identifiants hors du dépôt et hors des fichiers de configuration, rotables sans redéploiement, avec une procédure de rotation documentée.
Dépendances et chaîne d'approvisionnement
Revue automatisée des dépendances avec une règle définissant ce qui bloque une version, plus des fichiers de verrouillage et des builds reproductibles.
Transport et en-têtes
Configuration TLS, HSTS, CSP et le reste, définis à l'origine et vérifiés, y compris les réglages protocolaires qui cassent silencieusement les clients.
Stack
Avec quoi nous le construisons.
Choisis projet par projet. Rien n'est imposé par défaut ici, et l'équipe qui assurera la maintenance pèse autant que le problème.
Révision
Modélisation des menaces sur les données et les rôles, avant que la conception ne soit figée.
Tests
Tests d'autorisation en intégration continue, analyse des dépendances à chaque build et revue manuelle périodique des chemins qui comptent.
Infrastructure
Comptes de service au moindre privilège, cloisonnement réseau et sauvegardes dont la restauration a réellement été répétée.
Supervision
Alertes sur les échecs d'authentification, les refus d'autorisation et les taux d'erreur, car une simple tentative est déjà un signal.
Réponse
Une procédure écrite pour le jour où quelque chose tourne mal, convenue avant que cela n'arrive.
Comparaison
Une analyse avant la mise en service ou la sécurité comme décision de construction.
Les scanners méritent d'être lancés et trouvent de vraies choses. Ils ne trouvent simplement pas la catégorie de faille qui coûte réellement de l'argent aux entreprises.
| Critère | Analyse avant la mise en service | Intégré dès le départ |
|---|---|---|
| Contrôle d'accès défaillant | Largement manqué — une demande portant sur l'enregistrement d'un autre client ressemble en tout point à une demande légitime | Des tests qui demandent délibérément les données d'un autre client et vérifient le refus, à chaque commit |
| Dépendances obsolètes | Détecté, et c'est réellement utile | Détectées plus tôt, avec une règle définissant ce qui bloque une version |
| En-têtes manquants et réglages TLS | Détecté | Définis à l'origine et vérifiés, y compris les réglages protocolaires qui cassent silencieusement les clients |
| Secrets dans le dépôt | Détectés une fois qu'ils figurent déjà dans l'historique | Jamais versés dans le dépôt, et remplaçables sans redéploiement |
| Quand les problèmes apparaissent | Deux semaines avant la mise en service, quand l'architecture est figée | Tant que modifier la conception coûte encore peu |
| Coût de la correction | Refaire un modèle de droits après la mise en service coûte des semaines et une migration | Quelques jours au début, puis presque rien |
Comment cela se déroule
De la première conversation à la mise en ligne.
Indicatif pour un travail de cette nature. Le pilote n'est pas optionnel — rien n'est basculé tant que les utilisateurs n'ont pas dit que cela tient.
- 3 à 5 jours
Modèle de menaces
Les données, les rôles et ce qu'un attaquant voudrait réellement — avant que la conception ne soit figée.
- 2 à 3 semaines
Fondations
Autorisation côté serveur sur chaque point d'entrée, gestion des sessions et des jetons, secrets hors du dépôt avec une rotation documentée.
- 1 à 2 semaines
Tests adversariaux
Des tests automatisés qui franchissent les frontières entre clients, élèvent les rôles et rejouent des jetons expirés, câblés dans l'intégration continue pour qu'une régression fasse échouer le build.
- en continu
En continu
Politique de dépendances, alertes sur les refus d'autorisation et une procédure de réponse écrite, convenue avant d'en avoir besoin.
Après la mise en service
Ce qui change.
- La faille grave la plus courante des logiciels métier est couverte par des tests plutôt que par l'espoir.
- Une session expirée se termine proprement au lieu de rejouer une requête morte jusqu'à ce que quelque chose cède.
- Un identifiant divulgué devient une rotation, pas un redéploiement et un incident.
- Un test d'intrusion revient court, parce que les failles coûteuses ont été éliminées dès la conception.
Décrit qualitativement à dessein. Nous ne publions pas de pourcentages d'amélioration que nous ne pouvons pas rattacher à un client nommé, avec son accord.
Questions
Questions fréquentes.
Est-ce un test d'intrusion ?
Non. Un test d'intrusion est une évaluation ponctuelle réalisée par un tiers indépendant, et il faut le commander séparément — nous pouvons vous aider à le cadrer. Ceci est l'ingénierie qui fait revenir ce test avec peu de constats, et elle continue après le dépôt du rapport.
Nous avons déjà un scanner. Cela ne suffit-il pas ?
Les scanners méritent d'être lancés et trouvent de vraies choses, mais ils trouvent surtout des dépendances vulnérables connues et des en-têtes manquants. Le contrôle d'accès défaillant — la faille grave la plus courante des logiciels métier — ressemble à une requête valide et demande des tests écrits pour votre propre modèle de droits.
Pouvez-vous auditer une application que nous avons déjà ?
Oui. L'audit d'une base de code existante prend en général une à deux semaines et produit une liste priorisée argumentée, pas un export brut de scanner. Nous pouvons appliquer les correctifs ou les transmettre à votre équipe.
Cela ralentit-il le projet ?
Marginalement au début, et bien moins qu'un rattrapage ultérieur. Les tests d'autorisation et la politique de dépendances ajoutent quelques jours au départ ; refaire un modèle de droits après la mise en service coûte des semaines et une migration.
Notre équipe est petite. Est-ce proportionné ?
Le travail d'autorisation l'est, parce qu'il est peu coûteux au début et très coûteux ensuite, et parce que c'est la faille la plus susceptible d'exposer les données d'un client à un autre. Une modélisation complète des menaces et une supervision continue peuvent attendre qu'il y ait quelque chose à superviser.
Prenez-vous en charge les certifications de conformité ?
Nous faisons l'ingénierie qui rend un audit simple — contrôle d'accès, journaux d'audit, chiffrement, conservation, procédures documentées — mais nous ne sommes pas auditeurs et ne délivrons pas de certificats. Là où un référentiel particulier s'applique, faites intervenir l'auditeur tôt et nous construirons selon ce qu'il exige réellement.