Sécurité applicative : intégrer la sécurité dès la conception, jusqu’à la production

Qu’est-ce que la sécurité applicative ?

La sécurité applicative, ou AppSec, regroupe les pratiques visant à réduire les risques dans la conception, le développement, les dépendances, les interfaces, les pipelines de livraison et l’exploitation d’un logiciel.

Elle couvre contrôles d’accès, authentification, validation des données, logique métier, cryptographie, secrets, dépendances tierces, API, journalisation et déploiement. Elle ne se limite ni à un scanner, ni à un pentest, ni au seul OWASP Top 10.

Expertise AppSec, audit ou pentest : quelle différence ?

Sécurité applicative : l’essentiel

• Concevoir les contrôles tôt.
• Développer avec des règles adaptées à la stack et aux scénarios.
• Maîtriser dépendances et chaîne d’approvisionnement.
• Sécuriser CI/CD, secrets et droits de livraison.
• Tester code, composants, application, API et logique métier.
• Prioriser selon exploitabilité et impact.
• Observer en production avec des logs utiles.

Quels risques applicatifs faut-il traiter en priorité ?

Que couvre réellement l’OWASP Top 10 en 2025 ?

L’OWASP Top 10:2025 comprend Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging & Alerting Failures et Mishandling of Exceptional Conditions.

Cette édition montre que l’AppSec ne se limite plus aux vulnérabilités de code classiques : conception, supply chain, intégrité, configuration et détection font aussi partie du problème.

Source primaire : OWASP Top 10:2025

Comment interpréter les 10 catégories OWASP Top 10:2025 ?

Chaque catégorie correspond à une famille de risques, pas à une vulnérabilité unique. L’intérêt est de relier ces familles aux choix d’architecture, de développement, de configuration et d’exploitation.

Source primaire : OWASP Top 10:2025

L’OWASP Top 10 suffit-il pour sécuriser une application ?

Non. Il s’agit avant tout d’un document de sensibilisation aux grandes catégories de risques, pas d’un standard complet de vérification.

L’OWASP ASVS fournit un ensemble plus structuré d’exigences permettant d’évaluer le niveau de confiance dans la sécurité d’une application web. OWASP indique ASVS 5.0.0 comme version stable actuelle.

Source primaire : OWASP ASVS 5.0

OWASP Top 10 et CWE Top 25 : quelle différence ?

Les deux ressources sont complémentaires. L’OWASP Top 10 structure des catégories de risques applicatifs destinées notamment à la sensibilisation et à l’AppSec. Le CWE Top 25 classe des faiblesses logicielles fréquentes et impactantes observées derrière des vulnérabilités réelles.

Dans l’édition CWE Top 25 2025, les premières positions incluent notamment Cross-site Scripting (CWE-79), SQL Injection (CWE-89), Cross-Site Request Forgery (CWE-352) et Missing Authorization (CWE-862). Cette liste aide à raisonner sur les causes techniques récurrentes, sans remplacer une analyse propre à l’application.

Source primaire : CWE — Top 25 Most Dangerous Software Weaknesses

Pourquoi commencer par la conception plutôt que par le scanner ?

Un scanner peut identifier certaines vulnérabilités, mais comprend difficilement règles métier, relations de confiance, scénarios d’abus ou conséquences d’une décision d’architecture.

• actifs et données à protéger ;
• rôles utilisateurs et systèmes ;
• opérations sensibles ;
• frontières de confiance ;
• scénarios d’abus à empêcher ou détecter ;
• comportement en cas d’erreur ou dépendance indisponible.

Le threat modeling et les revues d’architecture permettent de traiter ces questions tôt.

Secure coding : quelles pratiques comptent réellement ?

Le secure coding ne se résume pas à valider les entrées. Il doit être adapté au langage, au framework, aux données et au modèle d’autorisation.

• contrôles d’accès côté serveur ;
• traitement sûr des données non fiables ;
• gestion robuste des erreurs ;
• cryptographie appropriée ;
• sessions et authentification ;
• protection des secrets ;
• journalisation pertinente ;
• revue des dépendances.

DevSecOps : intégrer la sécurité sans transformer le pipeline en barrage

Le DevSecOps intègre des contrôles de sécurité dans le développement et l’exploitation plutôt que de créer une étape séparée uniquement en fin de projet.

Le NIST Secure Software Development Framework (SSDF) propose des pratiques intégrables au cycle de développement afin notamment de réduire les vulnérabilités livrées, limiter l’impact de celles qui subsistent et traiter leurs causes racines.

Source primaire : NIST SP 800-218 — SSDF 1.1

DevOps et DevSecOps : quelle différence ?

DevSecOps ne signifie pas « mettre un scanner dans Jenkins ou GitLab ». L’automatisation est utile pour les contrôles répétables, mais elle ne remplace pas l’analyse de conception, la logique métier, la revue des autorisations ou les arbitrages de risque.

CI/CD sécurisé : que faut-il protéger ?

Le pipeline dispose souvent d’accès puissants au code, secrets, registres, artefacts, environnements et parfois production. Sa compromission peut affecter le logiciel livré sans attaquer directement l’application en production.

• droits sur dépôts et pipelines ;
• branches et changements sensibles ;
• secrets et jetons ;
• provenance des dépendances ;
• séparation des environnements ;
• intégrité et traçabilité des artefacts ;
• droits de déploiement.

SAST, DAST, SCA et pentest : quelles différences ?

Ces approches sont complémentaires. Les multiplier sans stratégie produit surtout du bruit.

Que tester, et à quel moment du cycle de développement ?

Le but n’est pas de tout tester à chaque livraison, mais de placer chaque contrôle là où il apporte le plus d’information utile au meilleur coût.

Sécurité des API : pourquoi une approche spécifique ?

Les API exposent directement objets, fonctions, flux métier et parfois données sensibles. Elles nécessitent une attention particulière sur autorisation, authentification, inventaire, consommation de ressources et relations avec des services tiers.

L’OWASP API Security Top 10 2023 place Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption et Broken Function Level Authorization parmi ses cinq premiers risques ; trois concernent directement l’autorisation.

Source primaire : OWASP API Security Top 10 — 2023

API security : authentification et rate limiting suffisent-ils ?

Non. Une API peut authentifier correctement un utilisateur tout en lui permettant d’accéder à un objet ou une fonction non autorisée. L’autorisation doit être vérifiée pour chaque opération sensible.

Le rate limiting peut réduire certains abus, mais OWASP distingue aussi flux métier sensibles, mauvaises configurations, inventaires incomplets et consommation non sûre d’API tierces.

Un WAF peut-il corriger une application vulnérable ?

Non. Un WAF peut apporter une couche de protection et bloquer certains motifs ou comportements, mais il ne corrige pas la logique métier, les autorisations défaillantes, une mauvaise conception ou le code vulnérable.

Comment protéger les secrets applicatifs et CI/CD ?

• identifier où les secrets sont stockés ;
• limiter qui peut les lire ;
• éviter leur présence dans code et logs ;
• organiser rotation et révocation ;
• séparer les secrets selon les environnements ;
• journaliser les accès sensibles lorsque pertinent.

Comment prioriser les vulnérabilités sans corriger uniquement le CVSS le plus élevé ?

Le score technique est utile mais ne décrit pas seul le risque réel. La priorité doit aussi considérer exposition, exploitabilité dans l’architecture réelle, privilèges nécessaires, actifs accessibles, données concernées, contrôles compensatoires et conséquences métier.

Comment construire une démarche AppSec pragmatique ?

1. Cadrer applications, données, utilisateurs et flux critiques.
2. Modéliser scénarios de menace et exigences.
3. Intégrer les pratiques dans développement, dépendances et CI/CD.
4. Tester avec les approches adaptées.
5. Prioriser et corriger selon exploitabilité et impact.
6. Mesurer et améliorer via vulnérabilités, incidents et retours développeurs.

Cette expertise peut être mobilisée dans un audit cybersécurité ou applicatif formalisé avec constats et livrables, un pentest lorsque l’objectif est de rechercher des failles exploitables, ou une mission de conseil pour agir sur la conception et les pratiques.

Quelles erreurs fragilisent le plus souvent la sécurité applicative ?

• faire de la sécurité uniquement avant la production ;
• confondre OWASP Top 10 et sécurité complète ;
• accumuler les scanners sans capacité de correction ;
• négliger logique métier et autorisations ;
• laisser secrets ou jetons dans code, logs ou pipelines ;
• ignorer dépendances et supply chain ;
• prioriser uniquement au CVSS ;
• sécuriser l’application mais oublier le pipeline qui la construit.

Que faire après avoir identifié une faiblesse applicative ?

Ce que cette expertise ne signifie pas

Connaître OWASP, SAST, DAST, SCA ou DevSecOps ne signifie pas recommander tous les outils disponibles ni promettre une application sans vulnérabilité. La bonne combinaison dépend de la stack, du cycle de livraison, des risques et de la capacité des équipes à exploiter les résultats.

Une expertise applicative reliée au risque et au business

Gérard Levicki intervient directement dans les missions Mobhitech avec une approche reliant applications, architecture, identités, données, risque, gouvernance et conséquences métier. Son parcours dans les métiers de la cybersécurité s’étend sur plus de 25 ans.

Learn about his career · LinkedIn Profile

Autres domaines d’expertise

Systèmes · Réseau · Cloud · Données · Industrie & IoT

Questions fréquentes

Quelle différence entre AppSec et pentest ?

L’AppSec couvre le cycle de conception, développement, livraison et exploitation. Le pentest cherche des failles exploitables dans un périmètre et à un moment définis.

L’OWASP Top 10 suffit-il ?

Non. C’est un document de sensibilisation, pas un standard exhaustif de vérification.

Quelle différence entre SAST et DAST ?

Le SAST analyse le code ou une représentation statique ; le DAST observe une application en fonctionnement depuis l’extérieur.

Un WAF remplace-t-il une correction de code ?

Non. Il peut compléter ou compenser temporairement certains contrôles, mais ne corrige pas la cause applicative.

Pourquoi les API nécessitent-elles des contrôles spécifiques ?

Parce qu’elles exposent directement objets, fonctions et flux métier ; l’autorisation doit être vérifiée au bon niveau pour chaque opération sensible.

DevSecOps signifie-t-il automatiser tous les contrôles ?

Non. L’automatisation est utile pour certains contrôles répétables, mais conception, logique métier, arbitrage et analyse humaine restent nécessaires.

OWASP Top 10 et ASVS sont-ils interchangeables ?

Non. Le Top 10 est principalement un document de sensibilisation aux catégories de risques ; ASVS fournit des exigences de vérification plus structurées pour la sécurité applicative.

Quand faut-il réaliser un pentest applicatif ?

Lorsque l’objectif est d’évaluer l’exploitabilité réelle d’un périmètre défini, notamment avant une mise en production importante, après une évolution majeure ou sur une application à fort enjeu. Il ne remplace pas les contrôles continus du cycle de développement.