Outil CASA pour votre évaluation de sécurité

Le déclencheur est le type d'autorisation OAuth demandé aux utilisateurs Google, pas la taille de l'éditeur. Une application qui sollicite des champs d'application sensibles passe par la vérification OAuth ; celle qui demande des champs restreints, ceux qui touchent aux contenus les plus protégés comme la messagerie ou les fichiers, doit en outre démontrer son niveau de sécurité applicative via CASA. Une application réservée aux comptes de votre propre organisation échappe à cette vérification. Le périmètre s'apprécie donc application par application.

CASA est gradué. Au plus léger, une auto-évaluation appuyée sur des preuves et sur l'analyse automatisée de l'application ; au plus exigeant, une évaluation conduite par un laboratoire agréé, qui ajoute ses propres tests et une revue documentaire. Le niveau attendu n'est pas choisi par l'éditeur : il découle de la vérification demandée par Google et du risque porté par les données auxquelles l'application accède. Le travail de préparation reste le même, seule change l'exigence de preuve.

Pas au sens d'une ISO 27001 : il n'existe ni schéma accrédité, ni certificat de conformité générale de l'organisation. CASA est le cadre de l'App Defense Alliance que Google utilise dans sa vérification OAuth ; une évaluation conduite par un laboratoire agréé aboutit à une lettre de validation, attachée à une application et aux autorisations qu'elle demande, que vous transmettez à Google. Elle n'est pas acquise une fois pour toutes : tant que l'application conserve des champs restreints, l'évaluation est à refaire chaque année, et modifier les champs demandés relance la vérification.

L'ASVS est le référentiel de vérification de la sécurité applicative publié par l'OWASP, sur lequel CASA fonde ses exigences. On y retrouve l'authentification et la gestion des sessions, le contrôle d'accès, la validation des entrées, la cryptographie et la gestion des secrets, la journalisation, la gestion des dépendances et la sécurité du cycle de développement. La logique est celle de la preuve : pour chaque exigence, montrer non pas une intention mais un contrôle en place et vérifiable.

Non. Une certification ISO/IEC 27001 porte sur un système de management de la sécurité de l'information, à l'échelle de l'organisation ; CASA regarde une application et son code. L'une ne se substitue pas à l'autre. En revanche, une grande partie des preuves déjà produites pour votre SMSI, un rapport SOC 2 ou un test d'intrusion récent alimente directement le dossier CASA. L'erreur fréquente consiste à repartir de zéro alors que la matière existe, dispersée entre plusieurs équipes.

Les écarts constatés doivent être corrigés puis présentés à nouveau : une évaluation n'est pas un examen à passage unique. Le risque réel n'est pas l'échec ponctuel, c'est le calendrier. Tant que le dossier n'est pas validé, Google peut restreindre l'accès de l'application aux champs concernés, ce qui casse la fonctionnalité côté utilisateurs. D'où l'intérêt de traiter la remédiation en continu plutôt que de découvrir les écarts quelques semaines avant l'échéance.

Parce qu'un dossier CASA n'est pas une liste de cases cochées mais un ensemble de liens : quelle exigence, quel contrôle la couvre, quelle preuve l'atteste, qui en répond et quand elle a été revue. Un tableur perd ces liens d'un cycle à l'autre, et le travail est à refaire à l'identique l'année suivante. Une plateforme les conserve, signale les preuves périmées entre deux évaluations et réutilise ce qui reste valable, y compris pour vos autres référentiels.