How to Document False Positives for the Salesforce Security Review

TL;DR: A false positive is a scanner finding that flags code that is not actually vulnerable. Salesforce does not want you to silence it, it wants a written justification for each one: the scanner and rule, the exact file and line, the data path, and the control that already protects it. Vague, one-line dismissals are the most common reason a false-positive document comes back with questions.

Every AppExchange security review submission includes scan reports, and no real codebase scans perfectly clean. Some findings are true issues you fix. Others flag code that is already safe, and those you document. This guide is about the second group: how to write false-positive justifications the Salesforce security review team accepts, and the mistakes that get them rejected. For the failures you should actually fix, and the order to fix them in, see Salesforce Security Review Checklist: What to Fix, In Order.

What counts as a false positive?

A false positive is a finding that is technically wrong for your code, not one you would rather not deal with. A scanner flags a pattern; whether that pattern is exploitable depends on context the scanner cannot always see. If the code is genuinely protected, you have a false positive to document. If you are not sure it is protected, treat it as a real finding and fix it, because guessing here is what turns a document into a rejection.

The categories that recur often enough to plan for are:

• Access-control findings raised against code that already runs in user mode with WITH USER_MODE or AccessLevel.USER_MODE.
• Sharing findings on classes only ever entered through a context that has already applied sharing.
• Injection findings on queries that use bind variables the scanner did not trace.
• Cross-site scripting findings on parameters that never reach the DOM or are encoded before they do.
• Vulnerable-library findings matched on a version string inside a bundled static resource that the package never executes.

The bar is different for each scanner

Before you write a single justification, know which findings you even have to address. The threshold is not zero findings, and it changes by tool:

• Salesforce Code Analyzer: resolve every security-related error, and disregard findings that are not security related. Read the tool docs at Salesforce Code Analyzer.
• Source scanner: address Low, Medium and High findings, and leave purely informational warnings alone.
• Dynamic (DAST) scanners: address everything except informational items and warnings, and keep a screenshot proving the correct endpoint was scanned.

Anything above the noise line is either fixed or documented. There is no third option where you ignore it silently.

What Salesforce asks for in the false-positive document

Salesforce asks for a document explaining why each flagged item does not pose a security risk, and it tells you to be specific about how you protect against the vulnerability the scanner indicated. Being right is not enough. The document is what the reviewer reads, so the document is what has to prove it.

What a good entry looks like

Give every flagged item its own entry rather than one blanket paragraph. A strong entry answers, in order:

1. Which finding. The scanner name, the rule or category identifier, and the severity it assigned.
2. Where. The exact file and line, so the reviewer can open it without hunting.
3. The data path. One sentence on how data reaches that line, and why the flagged pattern does not apply to it.
4. The control. The specific mechanism that protects it, named concretely: the bind variable, the user-mode enforcement, the encoding call, the sharing context.
5. Proof. Where that control lives in the package, and for dynamic findings, the screenshot showing the endpoint that was actually tested.

Write it so someone who has never opened your code can follow the path from input to the control and agree it is safe. That is the whole test.

Why false-positive documents get rejected

The rejections we see cluster into a handful of avoidable mistakes:

• One-line dismissals. "Not exploitable" or "handled elsewhere" gives the reviewer nothing to verify, so it comes back as a question, and questions cost a review cycle.
• No file and line. A justification the reviewer cannot locate in the code cannot be confirmed.
• Documenting a real issue. Arguing a genuine finding is a false positive erodes trust in the entire document, and the reviewer starts re-checking the ones that were fine.
• Missing dynamic-scan evidence. A DAST finding waved away without a screenshot of the scanned endpoint reads as untested, not safe.
• Stale references. Line numbers that no longer match the submitted package because the code moved after the scan.

How metadata discipline makes this repeatable

Salesforce periodically re-audits listed packages, which means you will write false-positive justifications more than once. When your package metadata lives in source control, every permission set, sharing rule and named credential is versioned, so you can point to the exact control that backs a justification and show it has not changed. Teams that treat metadata as code reuse last year's document instead of reconstructing the reasoning from scratch.

If you would rather a partner who has cleared the review before writes these justifications with you, Tekunda builds and packages AppExchange products as a Salesforce PDO.

FAQ

Can I just suppress a finding instead of documenting it?

No. Anything above the scanner's noise threshold is either fixed or explained in the false-positive document. A suppressed finding with no justification reads as an unaddressed one.

How detailed does each entry need to be?

Detailed enough for a reviewer to locate the code and confirm the control without asking you. In practice that is scanner and rule, file and line, the data path, and the exact control that protects it.

Do dynamic-scan false positives need extra evidence?

Yes. Attach a screenshot proving the correct endpoint was scanned, otherwise the finding reads as untested rather than safe.