Les implémentations peuvent utiliser instrumentation, agents, bibliothèques, hooks d'exécution ou intégration au framework. L'étiquette ne définit ni une architecture, ni une méthode de détection, ni un périmètre d'application, ni un niveau d'assurance unique.
Parce qu'un contrôle RASP peut observer l'exécution de l'application, il peut relier une requête à des chemins de code, des requêtes de base de données, un traitement de données, des identités ou des exceptions qu'un contrôle externe ne peut voir. Produits et implémentations diffèrent entre supervision, blocage et réponse propre à l'application.
Points clés
Placement et périmètreDocumenter runtimes, applications, chemins de code, entrées, classes d'attaque, modes de fonctionnement pris en charge et tout comportement que le contrôle ne peut inspecter ni interrompre en sécurité.
Exploitation sûreTester détection et blocage contre un trafic représentatif, mesurer latence et usage de ressources, protéger politique et accès de gestion, déployer l'application par étapes et définir le comportement fail-open, fail-closed, de retour arrière et de traitement des indices.
ValidationConfirmer les détections revendiquées avec des tests reproductibles, superviser faux positifs et faux négatifs, réévaluer après les changements de l'application ou du runtime, et s'assurer que les alertes atteignent un processus de réponse responsable.
Limite importanteLe RASP ne répare pas le code vulnérable ni ne rend l'application sûre. Il peut être contourné, mal configuré ou diminué par des chemins non pris en charge, et l'instrumentation à l'exécution peut affecter performance ou stabilité.