False Positives fuer 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 Begruendung fuer jeden einzelnen: Scanner und Regel, die genaue Datei und Zeile, den Datenpfad und die Kontrolle, die den Code bereits schuetzt. Vage Ein-Zeilen-Abweisungen sind der haeufigste Grund, warum ein False-Positive-Dokument mit Rueckfragen zurueckkommt.

Jede AppExchange-Security-Review-Einreichung enthaelt 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-Begruendungen schreibst, die das Salesforce-Security-Review-Team akzeptiert, und welche Fehler zu Ablehnung fuehren. Zu den Befunden, die du tatsaechlich beheben solltest, und der Reihenfolge dafuer, siehe Salesforce Security Review Checkliste: was Sie beheben, und in welcher Reihenfolge.

Was zaehlt als False Positive?

Ein False Positive ist ein Befund, der fuer deinen Code technisch falsch ist, nicht einer, mit dem du dich lieber nicht befassen moechtest. Ein Scanner markiert ein Muster; ob dieses Muster ausnutzbar ist, haengt von Kontext ab, den der Scanner nicht immer sieht. Ist der Code wirklich geschuetzt, hast du ein False Positive zu dokumentieren. Bist du nicht sicher, dass er geschuetzt 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 laeuft.
• Sharing-Befunde auf Klassen, die nur ueber 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 gebuendelten statischen Ressource passen, die das Package nie ausfuehrt.

Die Schwelle ist bei jedem Scanner anders

Bevor du eine einzige Begruendung schreibst, wisse, welche Befunde du ueberhaupt adressieren musst. Die Schwelle ist nicht null Befunde, und sie aendert 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 ausser 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 erklaert, warum jeder markierte Punkt kein Sicherheitsrisiko darstellt, und weist dich an, konkret zu sein, wie du gegen die vom Scanner angezeigte Schwachstelle schuetzt. Recht zu haben reicht nicht. Der Pruefer 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 Pruefer sie ohne Suche oeffnen 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 schuetzt, 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 tatsaechlich 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 Pruefer nichts zum Nachpruefen, kommt also als Frage zurueck, und Fragen kosten einen Review-Zyklus.
• Keine Datei und Zeile. Eine Begruendung, die der Pruefer im Code nicht findet, laesst sich nicht bestaetigen.
• Ein echtes Problem dokumentieren. Einen echten Befund als False Positive auszugeben, untergraebt das Vertrauen in das ganze Dokument, und der Pruefer beginnt, die korrekten erneut zu pruefen.
• 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-Begruendungen 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 Begruendung stuetzt, und belegst, dass sie sich nicht geaendert hat. Teams, die Metadaten als Code behandeln, verwenden das Dokument vom letzten Jahr wieder, statt die Begruendung neu zu rekonstruieren.

Wenn du lieber einen Partner haettest, der die Review schon bestanden hat und diese Begruendungen mit dir schreibt: Tekunda baut und verpackt AppExchange-Produkte als Salesforce PDO.

FAQ

Kann ich einen Befund einfach unterdruecken, statt ihn zu dokumentieren?

Nein. Alles oberhalb der Rauschschwelle des Scanners wird entweder behoben oder im False-Positive-Dokument erklaert. Ein unterdrueckter Befund ohne Begruendung liest sich als unbearbeitet.

Wie detailliert muss jeder Eintrag sein?

Detailliert genug, damit ein Pruefer den Code findet und die Kontrolle bestaetigt, ohne dich zu fragen. In der Praxis sind das Scanner und Regel, Datei und Zeile, der Datenpfad und die genaue Kontrolle, die schuetzt.

Brauchen dynamische False Positives zusaetzlichen Nachweis?

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