APP / APP-02
Revue de code source et vérification de la sécurité des applications
Analyser le code applicatif et la configuration pour identifier les failles de sécurité et comprendre leurs causes. Les outils automatisés aident à cibler l'examen, mais les résultats doivent être validés et liés à l'utilisation.
QUAND C'EST UTILE
Une réponse ciblée
à un besoin défini.
Application stratégique développée en interne, prise de contrôle du code, problèmes récurrents malgré les tests de pénétration ou fonctions sensibles nécessitant une validation avant la mise en production.
EN UN COUP D'ŒIL
Famille
Sécurité des applications
Engagement
Conseil et mise en œuvre
Référence
APP-02
PORTÉE ET RÉSULTATS
Ce que couvre la mission.
Portée
- Répertoires et versions agréés
- authentification/autorisation
- Traitement des données
- secrets
- erreurs
- cryptographie
- Analyse statique
- Revision manuelle ciblée
- Recommandations de remise en état
Livrables
- Rapport contextuel
- Les fichiers et zones concernés
- preuves non destructives
- Priorités
- Recommandations des développeurs
- carnet de commandes
- Débriefing technique
- examen de suivi facultatif
Preuve de réception
Les conclusions sont valables ; le champ d’application examiné est bien précis ; les recommandations sont compréhensibles pour les développeurs ; les faux positifs sont signalés séparément ; les conclusions concernent la version examinée.
LIVRAISON
Comment le travail est structuré.
Approche
Comprendre l’architecture ; sélectionner les risques et les exigences ; intégrer ou vérifier les contrôles ; tester ; les transmettre aux équipes et planifier des contrôles de régression.
Prérequis et responsabilités
Client : code, architecture, développeurs, environnement de test et accès au pipeline. Fournisseur : expertise et contrôles ; correction du code uniquement lorsqu'elle est incluse.
Facteurs de portée
Applications, langages, référentiels, dépendances, rôles, pipelines, volume et profondeur. Séparer les licences d'outils, le développement de remédiation et la maintenance.
Questions à clarifier
Quelles langues et volumes de code ? Les dépendances et les environnements sont-ils reproductibles ? Quelles fonctions gèrent les données ou les opérations les plus sensibles ?
LIMITES IMPORTANTES
L’analyse dépend du code fourni et de l’effort consacré. Un résultat d’un SAST n’est pas automatiquement exploitable ; l’absence d’alertes ne prouve pas la sécurité.
Les contrôles s'appliquent aux versions et au périmètre convenus. Aucun scanner, SBOM ou framework ne garantit à lui seul la sécurité du logiciel livré.
EN PRATIQUE
Situations illustratives.
Ces exemples décrivent des engagements possibles et des résultats cibles. Il ne s'agit pas de références clients ni de résultats obtenus.
Scénario 01
Une application facture plusieurs clients. Problème : examen des autorisations et des chemins d’accès aux documents. Objectif : identifier les causes d’isolement des failles et proposer des corrections ciblées, avec des tests de régression pour les valider.
Scénario 02
Un acquéreur reçoit le logiciel sans assurance qualité. Projet : examen ciblé des composants et secrets critiques. Résultats visés : les risques d’acquisition deviennent visibles ; le rapport identifie des zones non vérifiées au lieu de certifier l’ensemble du produit.
Contexte technologique et de référence
Exemples : outils SAST et de détection de secrets adaptés à la langue ; OWASP ASVS comme base de référence pour les exigences à choisir.
L'ensemble final des technologies est convenu lors du cadrage, sur la base de l'interopérabilité, des licences, des droits d'accès et des exigences opérationnelles.
SERVICES CONNECTÉS
Construisez l'étape suivante.
Ces services peuvent compléter la mission. Ils ne sont pas inclus automatiquement.
Commencer une conversation
Clarifiez la portée.
Nous clarifierons l'objectif, les dépendances et les responsabilités de ce service avant de proposer la livraison.