False positives documenteren voor de Salesforce security review

Samengevat: Een false positive is een scannerbevinding die code markeert die niet echt kwetsbaar is. Salesforce wil niet dat je die wegdrukt, maar een schriftelijke onderbouwing voor elke bevinding: de scanner en regel, het exacte bestand en de regel, het datapad, en de controle die de code al beschermt. Vage een-regel-afwijzingen zijn de meest voorkomende reden dat een false-positive document met vragen terugkomt.

Elke AppExchange security review-inzending bevat scanrapporten, en geen echte codebase scant volledig schoon. Sommige bevindingen zijn echte problemen die je oplost. Andere markeren code die al veilig is, en die documenteer je. Deze gids gaat over de tweede groep: hoe je false-positive onderbouwingen schrijft die het Salesforce security review-team accepteert, en de fouten die ze laten afkeuren. Voor de bevindingen die je echt moet oplossen, en de volgorde daarvan, zie Salesforce security review checklist: wat je oplost, en in welke volgorde.

Wat telt als false positive?

Een false positive is een bevinding die technisch onjuist is voor jouw code, niet een die je liever niet aanpakt. Een scanner markeert een patroon; of dat patroon exploiteerbaar is hangt af van context die de scanner niet altijd ziet. Is de code echt beschermd, dan heb je een false positive om te documenteren. Weet je niet zeker of hij beschermd is, behandel hem dan als een echte bevinding en los hem op, want gokken is hier precies wat een document in een afkeuring verandert.

De categorieen die vaak genoeg terugkeren om op te plannen zijn:

• Toegangscontrolebevindingen tegen code die al in user mode draait met WITH USER_MODE of AccessLevel.USER_MODE.
• Sharing-bevindingen op klassen die alleen worden betreden via een context die sharing al heeft toegepast.
• Injectiebevindingen op queries die bind-variabelen gebruiken die de scanner niet heeft getraceerd.
• Cross-site scripting-bevindingen op parameters die nooit het DOM bereiken of ervoor worden gecodeerd.
• Bevindingen over kwetsbare libraries die matchen op een versiestring in een gebundelde static resource die het package nooit uitvoert.

De drempel verschilt per scanner

Voordat je een enkele onderbouwing schrijft, weet welke bevindingen je uberhaupt moet aanpakken. De drempel is niet nul bevindingen, en die verandert per tool:

• Salesforce Code Analyzer: los elke beveiligingsgerelateerde fout op, en negeer bevindingen die niet beveiligingsgerelateerd zijn. Lees de tooldocumentatie op Salesforce Code Analyzer.
• Source scanner: pak Low-, Medium- en High-bevindingen aan, en laat puur informatieve waarschuwingen met rust.
• Dynamische (DAST) scanners: pak alles aan behalve informatieve items en waarschuwingen, en bewaar een screenshot die bewijst dat het juiste endpoint is gescand.

Alles boven de ruisgrens wordt of opgelost of gedocumenteerd. Er is geen derde optie om het stilletjes te negeren.

Wat Salesforce vraagt in het false-positive document

Salesforce vraagt om een document dat uitlegt waarom elk gemarkeerd item geen beveiligingsrisico vormt, en het vraagt je specifiek te zijn over hoe je beschermt tegen de kwetsbaarheid die de scanner aangaf. Gelijk hebben is niet genoeg. De reviewer leest het document, dus het document moet het bewijzen.

Hoe een goede entry eruitziet

Geef elk gemarkeerd item een eigen entry in plaats van een algemene paragraaf. Een sterke entry beantwoordt, op volgorde:

1. Welke bevinding. De scannernaam, de regel- of categorie-identifier, en de toegekende ernst.
2. Waar. Het exacte bestand en de regel, zodat de reviewer het opent zonder te zoeken.
3. Het datapad. Een zin over hoe data die regel bereikt, en waarom het gemarkeerde patroon er niet op van toepassing is.
4. De controle. Het specifieke mechanisme dat het beschermt, concreet benoemd: de bind-variabele, de user-mode handhaving, de encoding-aanroep, de sharing-context.
5. Bewijs. Waar die controle in het package staat, en voor dynamische bevindingen de screenshot die het daadwerkelijk geteste endpoint toont.

Schrijf het zo dat iemand die je code nooit heeft geopend het pad van invoer naar de controle kan volgen en kan beamen dat het veilig is. Dat is de hele test.

Waarom false-positive documenten worden afgekeurd

De afkeuringen die we zien clusteren in een handvol vermijdbare fouten:

• Een-regel-afwijzingen. "Niet exploiteerbaar" of "elders afgehandeld" geeft de reviewer niets om te verifieren, dus komt het als vraag terug, en vragen kosten een reviewcyclus.
• Geen bestand en regel. Een onderbouwing die de reviewer niet in de code kan vinden, kan niet worden bevestigd.
• Een echt probleem documenteren. Een echte bevinding als false positive verkopen ondermijnt het vertrouwen in het hele document, en de reviewer gaat de goede opnieuw controleren.
• Ontbrekend DAST-bewijs. Een dynamische bevinding die zonder screenshot van het gescande endpoint wordt weggewuifd leest als ongetest, niet als veilig.
• Verouderde verwijzingen. Regelnummers die niet meer matchen met het ingezonden package omdat de code na de scan verschoof.

Hoe metadata-discipline dit herhaalbaar maakt

Salesforce audit vermelde packages periodiek opnieuw, wat betekent dat je meer dan eens false-positive onderbouwingen schrijft. Wanneer je package-metadata in source control staat, zijn elke permission set, sharing rule en named credential geversioneerd, zodat je kunt wijzen naar de exacte controle die een onderbouwing schraagt en kunt tonen dat die niet veranderde. Teams die metadata als code behandelen hergebruiken het document van vorig jaar in plaats van de redenering opnieuw op te bouwen.

Wil je liever een partner die de review eerder haalde en deze onderbouwingen met je schrijft, dan bouwt en verpakt Tekunda AppExchange-producten als Salesforce PDO.

FAQ

Kan ik een bevinding gewoon onderdrukken in plaats van documenteren?

Nee. Alles boven de ruisdrempel van de scanner wordt of opgelost of uitgelegd in het false-positive document. Een onderdrukte bevinding zonder onderbouwing leest als een onafgehandelde.

Hoe gedetailleerd moet elke entry zijn?

Gedetailleerd genoeg zodat een reviewer de code vindt en de controle bevestigt zonder het jou te vragen. In de praktijk is dat scanner en regel, bestand en regel, het datapad, en de exacte controle die beschermt.

Vergen dynamische false positives extra bewijs?

Ja. Voeg een screenshot toe die bewijst dat het juiste endpoint is gescand, anders leest de bevinding als ongetest in plaats van veilig.