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 reellement vulnerable. Salesforce ne veut pas que vous le fassiez taire, mais une justification ecrite pour chacun : le scanner et la regle, le fichier et la ligne exacts, le chemin des donnees, et le controle qui protege deja le code. Les rejets en une ligne, vagues, sont la raison la plus frequente pour laquelle un document de faux positifs revient avec des questions.

Chaque soumission a la security review AppExchange contient des rapports de scan, et aucune vraie base de code ne scanne parfaitement propre. Certains constats sont de vrais problemes que vous corrigez. D'autres signalent du code deja sur, et ceux-la, vous les documentez. Ce guide porte sur le second groupe : comment rediger des justifications de faux positifs que l'equipe de security review Salesforce accepte, et les erreurs qui les font rejeter. Pour les constats a corriger reellement, 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 prefereriez ne pas vous occuper. Un scanner signale un motif ; que ce motif soit exploitable depend d'un contexte que le scanner ne voit pas toujours. Si le code est reellement protege, vous avez un faux positif a documenter. Si vous n'etes pas sur qu'il soit protege, traitez-le comme un vrai constat et corrigez-le, car deviner ici est precisement ce qui transforme un document en rejet.

Les categories qui reviennent assez souvent pour les anticiper sont :

• Constats de controle d'acces souleves contre du code qui s'execute deja en user mode avec WITH USER_MODE ou AccessLevel.USER_MODE.
• Constats de partage sur des classes uniquement atteintes via un contexte qui a deja applique le partage.
• Constats d'injection sur des requetes qui utilisent des variables de liaison que le scanner n'a pas tracees.
• Constats de cross-site scripting sur des parametres qui n'atteignent jamais le DOM ou sont encodes avant.
• Constats de bibliotheque vulnerable correspondant a une chaine de version dans une ressource statique embarquee que le package n'execute jamais.

Le seuil differe selon le scanner

Avant de rediger une seule justification, sachez quels constats vous devez meme traiter. Le seuil n'est pas zero constat, et il change selon l'outil :

• Salesforce Code Analyzer : corrigez chaque erreur liee a la securite, et ignorez les constats non lies a la securite. 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 elements informatifs et les avertissements, et gardez une capture d'ecran prouvant que le bon endpoint a ete scanne.

Tout ce qui depasse le bruit est soit corrige, soit documente. Il n'y a pas de troisieme option consistant a l'ignorer en silence.

Ce que Salesforce demande dans le document de faux positifs

Salesforce demande un document expliquant pourquoi chaque element signale ne pose pas de risque de securite, et vous demande d'etre precis sur la maniere dont vous protegez contre la vulnerabilite indiquee par le scanner. Avoir raison ne suffit pas. Le relecteur lit le document, donc c'est le document qui doit le prouver.

A quoi ressemble une bonne entree

Donnez a chaque element signale sa propre entree plutot qu'un seul paragraphe general. Une entree solide repond, dans l'ordre :

1. Quel constat. Le nom du scanner, l'identifiant de regle ou de categorie, et la severite attribuee.
2. Ou. Le fichier et la ligne exacts, pour que le relecteur ouvre le code sans chercher.
3. Le chemin des donnees. Une phrase sur la maniere dont les donnees atteignent cette ligne, et pourquoi le motif signale ne s'y applique pas.
4. Le controle. Le mecanisme precis qui le protege, nomme concretement : la variable de liaison, l'application du user mode, l'appel d'encodage, le contexte de partage.
5. La preuve. Ou vit ce controle dans le package, et pour les constats dynamiques, la capture montrant l'endpoint reellement teste.

Redigez-la pour que quelqu'un qui n'a jamais ouvert votre code puisse suivre le chemin de l'entree jusqu'au controle et convenir qu'il est sur. C'est tout le test.

Pourquoi les documents de faux positifs sont rejetes

Les rejets que nous voyons se regroupent en quelques erreurs evitables :

• Rejets en une ligne. "Non exploitable" ou "gere ailleurs" ne donne rien a verifier au relecteur, cela revient donc en question, et les questions coutent un cycle de revue.
• Ni fichier ni ligne. Une justification que le relecteur ne peut pas localiser dans le code ne peut pas etre confirmee.
• Documenter un vrai probleme. Faire passer un vrai constat pour un faux positif erode la confiance dans tout le document, et le relecteur se remet a verifier ceux qui allaient bien.
• Preuve dynamique manquante. Un constat DAST ecarte sans capture de l'endpoint scanne se lit comme non teste, pas comme sur.
• References perimees. Des numeros de ligne qui ne correspondent plus au package soumis parce que le code a bouge apres le scan.

Comment la discipline des metadonnees rend cela reproductible

Salesforce re-audite periodiquement les packages publies, ce qui signifie que vous redigerez des justifications de faux positifs plus d'une fois. Quand les metadonnees de votre package vivent dans un controle de source, chaque permission set, sharing rule et named credential est versionne, ce qui vous permet de pointer le controle exact qui soutient une justification et de montrer qu'il n'a pas change. Les equipes qui traitent les metadonnees comme du code reutilisent le document de l'an dernier au lieu de reconstruire le raisonnement de zero.

Si vous preferez un partenaire qui a deja passe la revue pour rediger 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 depasse le seuil de bruit du scanner est soit corrige, soit explique dans le document de faux positifs. Un constat supprime sans justification se lit comme non traite.

Quel niveau de detail chaque entree exige-t-elle ?

Assez pour qu'un relecteur localise le code et confirme le controle sans vous demander. En pratique : scanner et regle, fichier et ligne, chemin des donnees, et le controle exact qui protege.

Les faux positifs dynamiques demandent-ils une preuve supplementaire ?

Oui. Joignez une capture prouvant que le bon endpoint a ete scanne, sinon le constat se lit comme non teste plutot que sur.