Documenter les faux positifs pour la security review Salesforce

En bref : Un faux positif est un constat de scanner qui signale du code qui n'est pas réellement vulnérable. Salesforce ne veut pas que vous le fassiez taire, mais une justification écrite pour chacun : le scanner et la règle, le fichier et la ligne exacts, le chemin des données, et le contrôle qui protège déjà le code. Les rejets en une ligne, vagues, sont la raison la plus fréquente pour laquelle un document de faux positifs revient avec des questions.

Chaque soumission à la security review AppExchange contient des rapports de scan, et aucune vraie base de code ne scanne parfaitement propre. Certains constats sont de vrais problèmes que vous corrigez. D'autres signalent du code déjà sûr, et ceux-là, vous les documentez. Ce guide porte sur le second groupe : comment rédiger des justifications de faux positifs que l'équipe de security review Salesforce accepte, et les erreurs qui les font rejeter. Pour les constats à corriger réellement, et l'ordre pour le faire, voir Checklist de la security review Salesforce : quoi corriger, et dans quel ordre.

Qu'est-ce qui compte comme faux positif ?

Un faux positif est un constat techniquement faux pour votre code, pas un constat dont vous préféreriez ne pas vous occuper. Un scanner signale un motif ; que ce motif soit exploitable dépend d'un contexte que le scanner ne voit pas toujours. Si le code est réellement protégé, vous avez un faux positif à documenter. Si vous n'êtes pas sûr qu'il soit protégé, traitez-le comme un vrai constat et corrigez-le, car deviner ici est précisément ce qui transforme un document en rejet.

Les catégories qui reviennent assez souvent pour les anticiper sont :

• Constats de contrôle d'accès soulevés contre du code qui s'exécute déjà en user mode avec WITH USER_MODE ou AccessLevel.USER_MODE.
• Constats de partage sur des classes uniquement atteintes via un contexte qui a déjà appliqué le partage.
• Constats d'injection sur des requêtes qui utilisent des variables de liaison que le scanner n'a pas tracées.
• Constats de cross-site scripting sur des paramètres qui n'atteignent jamais le DOM ou sont encodés avant.
• Constats de bibliothèque vulnérable correspondant à une chaîne de version dans une ressource statique embarquée que le package n'exécute jamais.

Le seuil diffère selon le scanner

Avant de rédiger une seule justification, sachez quels constats vous devez même traiter. Le seuil n'est pas zéro constat, et il change selon l'outil :

• Salesforce Code Analyzer : corrigez chaque erreur liée à la sécurité, et ignorez les constats non liés à la sécurité. Consultez la documentation de l'outil sur Salesforce Code Analyzer.
• Scanner de source : traitez les constats Low, Medium et High, et laissez les avertissements purement informatifs.
• Scanners dynamiques (DAST) : traitez tout sauf les éléments informatifs et les avertissements, et gardez une capture d'écran prouvant que le bon endpoint a été scanné.

Tout ce qui dépasse le bruit est soit corrigé, soit documenté. Il n'y a pas de troisième option consistant à l'ignorer en silence.

Ce que Salesforce demande dans le document de faux positifs

Salesforce demande un document expliquant pourquoi chaque élément signalé ne pose pas de risque de sécurité, et vous demande d'être précis sur la manière dont vous protégez contre la vulnérabilité indiquée par le scanner. Avoir raison ne suffit pas. Le relecteur lit le document, donc c'est le document qui doit le prouver.

À quoi ressemble une bonne entrée

Donnez à chaque élément signalé sa propre entrée plutôt qu'un seul paragraphe général. Une entrée solide répond, dans l'ordre :

1. Quel constat. Le nom du scanner, l'identifiant de règle ou de catégorie, et la sévérité attribuée.
2. Où. Le fichier et la ligne exacts, pour que le relecteur ouvre le code sans chercher.
3. Le chemin des données. Une phrase sur la manière dont les données atteignent cette ligne, et pourquoi le motif signalé ne s'y applique pas.
4. Le contrôle. Le mécanisme précis qui le protège, nommé concrètement : la variable de liaison, l'application du user mode, l'appel d'encodage, le contexte de partage.
5. La preuve. Où vit ce contrôle dans le package, et pour les constats dynamiques, la capture montrant l'endpoint réellement testé.

Rédigez-la pour que quelqu'un qui n'a jamais ouvert votre code puisse suivre le chemin de l'entrée jusqu'au contrôle et convenir qu'il est sûr. C'est tout le test.

Pourquoi les documents de faux positifs sont rejetés

Les rejets que nous voyons se regroupent en quelques erreurs évitables :

• Rejets en une ligne. "Non exploitable" ou "géré ailleurs" ne donne rien à vérifier au relecteur, cela revient donc en question, et les questions coûtent un cycle de revue.
• Ni fichier ni ligne. Une justification que le relecteur ne peut pas localiser dans le code ne peut pas être confirmée.
• Documenter un vrai problème. Faire passer un vrai constat pour un faux positif érode la confiance dans tout le document, et le relecteur se remet à vérifier ceux qui allaient bien.
• Preuve dynamique manquante. Un constat DAST écarté sans capture de l'endpoint scanné se lit comme non testé, pas comme sûr.
• Références périmées. Des numéros de ligne qui ne correspondent plus au package soumis parce que le code a bougé après le scan.

Comment la discipline des métadonnées rend cela reproductible

Salesforce re-audite périodiquement les packages publiés, ce qui signifie que vous rédigerez des justifications de faux positifs plus d'une fois. Quand les métadonnées de votre package vivent dans un contrôle de source, chaque permission set, sharing rule et named credential est versionné, ce qui vous permet de pointer le contrôle exact qui soutient une justification et de montrer qu'il n'a pas changé. Les équipes qui traitent les métadonnées comme du code réutilisent le document de l'an dernier au lieu de reconstruire le raisonnement de zéro.

Si vous préférez un partenaire qui a déjà passé la revue pour rédiger ces justifications avec vous, Tekunda construit et empaquette des produits AppExchange en tant que PDO Salesforce.

FAQ

Puis-je simplement supprimer un constat au lieu de le documenter ?

Non. Tout ce qui dépasse le seuil de bruit du scanner est soit corrigé, soit expliqué dans le document de faux positifs. Un constat supprimé sans justification se lit comme non traité.

Quel niveau de détail chaque entrée exige-t-elle ?

Assez pour qu'un relecteur localise le code et confirme le contrôle sans vous demander. En pratique : scanner et règle, fichier et ligne, chemin des données, et le contrôle exact qui protège.

Les faux positifs dynamiques demandent-ils une preuve supplémentaire ?

Oui. Joignez une capture prouvant que le bon endpoint a été scanné, sinon le constat se lit comme non testé plutôt que sûr.