False Positives für die Salesforce Security Review dokumentieren

Kurz gesagt: Ein False Positive ist ein Scanner-Befund, der Code markiert, der gar nicht verwundbar ist. Salesforce will nicht, dass du ihn stumm schaltest, sondern eine schriftliche Begründung für jeden einzelnen: Scanner und Regel, die genaue Datei und Zeile, den Datenpfad und die Kontrolle, die den Code bereits schützt. Vage Ein-Zeilen-Abweisungen sind der häufigste Grund, warum ein False-Positive-Dokument mit Rückfragen zurückkommt.

Jede AppExchange-Security-Review-Einreichung enthält Scan-Berichte, und keine echte Codebasis scannt vollkommen sauber. Manche Befunde sind echte Probleme, die du behebst. Andere markieren Code, der bereits sicher ist, und die dokumentierst du. In diesem Leitfaden geht es um die zweite Gruppe: wie du False-Positive-Begründungen schreibst, die das Salesforce-Security-Review-Team akzeptiert, und welche Fehler zu Ablehnung führen. Zu den Befunden, die du tatsächlich beheben solltest, und der Reihenfolge dafür, siehe Salesforce Security Review Checkliste: was Sie beheben, und in welcher Reihenfolge.

Was zählt als False Positive?

Ein False Positive ist ein Befund, der für deinen Code technisch falsch ist, nicht einer, mit dem du dich lieber nicht befassen möchtest. Ein Scanner markiert ein Muster; ob dieses Muster ausnutzbar ist, hängt von Kontext ab, den der Scanner nicht immer sieht. Ist der Code wirklich geschützt, hast du ein False Positive zu dokumentieren. Bist du nicht sicher, dass er geschützt ist, behandle ihn als echten Befund und behebe ihn, denn Raten ist hier genau das, was ein Dokument in eine Ablehnung verwandelt.

Die Kategorien, die oft genug wiederkehren, um damit zu planen, sind:

• Zugriffskontroll-Befunde gegen Code, der bereits im User Mode mit WITH USER_MODE oder AccessLevel.USER_MODE läuft.
• Sharing-Befunde auf Klassen, die nur über einen Kontext betreten werden, der Sharing bereits angewandt hat.
• Injection-Befunde auf Abfragen, die Bind-Variablen nutzen, die der Scanner nicht verfolgt hat.
• Cross-Site-Scripting-Befunde auf Parametern, die nie das DOM erreichen oder vorher kodiert werden.
• Befunde zu verwundbaren Bibliotheken, die auf eine Versionsnummer in einer gebündelten statischen Ressource passen, die das Package nie ausführt.

Die Schwelle ist bei jedem Scanner anders

Bevor du eine einzige Begründung schreibst, wisse, welche Befunde du überhaupt adressieren musst. Die Schwelle ist nicht null Befunde, und sie ändert sich je nach Tool:

• Salesforce Code Analyzer: behebe jeden sicherheitsrelevanten Fehler und ignoriere Befunde, die nicht sicherheitsrelevant sind. Die Tool-Dokumentation findest du unter Salesforce Code Analyzer.
• Source-Scanner: adressiere Low-, Medium- und High-Befunde und lasse rein informative Warnungen in Ruhe.
• Dynamische (DAST) Scanner: adressiere alles außer informativen Punkten und Warnungen und behalte einen Screenshot, der beweist, dass der richtige Endpunkt gescannt wurde.

Alles oberhalb der Rauschgrenze wird entweder behoben oder dokumentiert. Es gibt keine dritte Option, es still zu ignorieren.

Was Salesforce im False-Positive-Dokument verlangt

Salesforce verlangt ein Dokument, das erklärt, warum jeder markierte Punkt kein Sicherheitsrisiko darstellt, und weist dich an, konkret zu sein, wie du gegen die vom Scanner angezeigte Schwachstelle schützt. Recht zu haben reicht nicht. Der Prüfer liest das Dokument, also muss das Dokument es beweisen.

Wie ein guter Eintrag aussieht

Gib jedem markierten Punkt einen eigenen Eintrag statt eines pauschalen Absatzes. Ein starker Eintrag beantwortet der Reihe nach:

1. Welcher Befund. Der Scanner-Name, die Regel- oder Kategorie-Kennung und der zugewiesene Schweregrad.
2. Wo. Die genaue Datei und Zeile, damit der Prüfer sie ohne Suche öffnen kann.
3. Der Datenpfad. Ein Satz dazu, wie Daten diese Zeile erreichen und warum das markierte Muster darauf nicht zutrifft.
4. Die Kontrolle. Der konkrete Mechanismus, der sie schützt, konkret benannt: die Bind-Variable, die User-Mode-Durchsetzung, der Kodierungsaufruf, der Sharing-Kontext.
5. Nachweis. Wo diese Kontrolle im Package liegt, und bei dynamischen Befunden der Screenshot, der den tatsächlich getesteten Endpunkt zeigt.

Schreibe es so, dass jemand, der deinen Code nie gesehen hat, dem Pfad von der Eingabe bis zur Kontrolle folgen und zustimmen kann, dass er sicher ist. Das ist der ganze Test.

Warum False-Positive-Dokumente abgelehnt werden

Die Ablehnungen, die wir sehen, gruppieren sich in eine Handvoll vermeidbarer Fehler:

• Ein-Zeilen-Abweisungen. "Nicht ausnutzbar" oder "anderswo behandelt" gibt dem Prüfer nichts zum Nachprüfen, kommt also als Frage zurück, und Fragen kosten einen Review-Zyklus.
• Keine Datei und Zeile. Eine Begründung, die der Prüfer im Code nicht findet, lässt sich nicht bestätigen.
• Ein echtes Problem dokumentieren. Einen echten Befund als False Positive auszugeben, untergräbt das Vertrauen in das ganze Dokument, und der Prüfer beginnt, die korrekten erneut zu prüfen.
• Fehlender DAST-Nachweis. Ein dynamischer Befund, der ohne Screenshot des gescannten Endpunkts abgetan wird, liest sich als ungetestet, nicht als sicher.
• Veraltete Verweise. Zeilennummern, die nicht mehr zum eingereichten Package passen, weil sich der Code nach dem Scan verschoben hat.

Wie Metadaten-Disziplin das wiederholbar macht

Salesforce auditiert gelistete Packages periodisch neu, was bedeutet, dass du False-Positive-Begründungen mehr als einmal schreibst. Wenn deine Package-Metadaten in der Versionskontrolle liegen, sind jede Permission Set, Sharing Rule und Named Credential versioniert, sodass du auf die genaue Kontrolle zeigen kannst, die eine Begründung stützt, und belegst, dass sie sich nicht geändert hat. Teams, die Metadaten als Code behandeln, verwenden das Dokument vom letzten Jahr wieder, statt die Begründung neu zu rekonstruieren.

Wenn du lieber einen Partner hättest, der die Review schon bestanden hat und diese Begründungen mit dir schreibt: Tekunda baut und verpackt AppExchange-Produkte als Salesforce PDO.

FAQ

Kann ich einen Befund einfach unterdrücken, statt ihn zu dokumentieren?

Nein. Alles oberhalb der Rauschschwelle des Scanners wird entweder behoben oder im False-Positive-Dokument erklärt. Ein unterdrückter Befund ohne Begründung liest sich als unbearbeitet.

Wie detailliert muss jeder Eintrag sein?

Detailliert genug, damit ein Prüfer den Code findet und die Kontrolle bestätigt, ohne dich zu fragen. In der Praxis sind das Scanner und Regel, Datei und Zeile, der Datenpfad und die genaue Kontrolle, die schützt.

Brauchen dynamische False Positives zusätzlichen Nachweis?

Ja. Hänge einen Screenshot an, der beweist, dass der richtige Endpunkt gescannt wurde, sonst liest sich der Befund als ungetestet statt sicher.