Security review sample "False positive document"

Question

We are submitting our app for security review. We have an ASP.Net web application that consumes few Salesforce APIs. The Burp scanner raised few OS, Ruby, Python and PHP injection errors. But we don't have ruby, python or php installed on the server on which our application is running. We are also not executing any OS level commands in our code. We want to flag these as false positives. There's 1 false positive in the Force.com scan report also. But I am not sure of the format of this document and what all information is required by the review team. Does anyone have any sample false positive documents which they submitted to Salesforce?

Answer 1

There is no specific temple/format as such.

You should just make sure you address following points.

1. Issue details
2. why do you think its not issue
3. If you have any other mechanism to handle issue then you should mentioned that in detail with all the code reference.
4. Relevant Screen shots

I had created my own temple but can not share due to IP restriction.

Salesforce security review team is really smart and they will understand your point quickly if you provide valid explanation with details.

Answer 2

There is an updated documentation on ISV Security guide on how to document the false positives .

Check the documentation here .

Answer 3

We add code comments within the Apex that say "//NOPMD See False Positives Doc: SOQL CRUD/FLS - Cannot Grant CRUD to System Objects" And within the false positives doc, we explain in a paragraph why that elevation is necessary.

For example:

    Organization org = [ // NOPMD.ApexCRUDViolation - False positive: Refer to "SOQL CRUD/FLS - Cannot Grant CRUD to System Objects" in the False Positives document
        SELECT OrganizationType FROM Organization
    ];

Then, within the False Positives doc, we have a heading that matches the above message like so:

SOQL CRUD/FLS - Cannot Grant CRUD to System Objects

There are numerous cases where we need to run a SOQL query for system objects such as Email Template, Organization, Org Wide Email Address, etc. In these cases, the queries must be executed without the “WITH SECURITY_ENFORCED” clause to allow access. These queries are annotated with comments like this:

// NOPMD.ApexCRUDViolation - False positive: Refer to "SOQL CRUD/FLS - Cannot Grant CRUD to System Objects" in the False Positives document

Another common example:

SOQL CRUD/FLS - Data Access from Trigger Context

Apex invoked via Trigger must run in system context because it updates records that the user should not have direct CRUD/FLS access to. This is done to protect data integrity as allowing a user to directly manipulate these SObjects would lead to corruption of the data model. These queries are executed without the “WITH SECURITY_ENFORCED” clause to ensure access.

The security review team has never taken issue with that approach. Additionally, it helps address issues that the Checkmarx report DOESN'T report but get picked up in manual review. And since line numbers change over time, using the spreadsheet approach with each finding mapped back to a line number is unmaintainable, IMO