Work with Salesforce Graph Engine

Before you learn about Salesforce Graph Engine, review how code paths are structured with data flow analysis. Each code path typically consists of these elements.

• Entry Point: The starting code location of the path of execution from an external interaction.
• Source: The code location where data can originate from. When data is passed into an entry point, then the entry point is the source for that data. Data can also be produced or read other than getting passed into the entry point, making it possible for the data source to also be in the middle of a code path.
• Sink: The ending code location where data can be consumed or modified.
• Sanitizer: The check that happens between the source and sink to ensure that an appropriate action happens or an inappropriate action doesn't happen.

One of the primary checks that Salesforce Graph Engine performs is that each code path containing a source and a sink of data also contains a sanitizer in between the source and the sink. When the sanitizer is missing, Graph Engine returns a violation. To avoid violations, ensure that each path created from any source to sink is sanitized.

A source can lead to multiple sinks. Also, a sink can be reached through multiple sources. There can be multiple paths between the same source and sink.

The Salesforce Graph Engine uses the same results output schema that other engines use; see Interpret the Run Results for information about human-readable output, and the Output Schema Reference for details about machine-readable outputs, such as JSON and XML.

Graph Engine results always have at least two locations: the first location is the entry point and the last location is the sink. Here's sample output that shows the entry point and sink associated with an ApexFlsViolation violation.

The Flow Scanner engine's results provide slightly different code paths from the Salesforce Graph Engine results. The Flow Scanner engine's code paths start from the data source whereas the Salesforce Graph Engine's code paths always start from the entry point, which aren't always the same as the data source.

Like all security tools, Graph Engine can create false negatives or false positives. For example, the engine can fail to create a violation where the code is insecure, which is a false negative. Or it can create a violation even though the code is secure, a false positive.

If you determine that Graph Engine created a false positive, add engine directives to your code so that Graph Engine doesn’t throw that violation anymore.

Graph Engine understands three levels of engine directives.

• Disable Next Line
• Disable Method
• Disable Line

To disable just the sink from Graph Engine’s analysis, use disable-next-line in your code. For example:

To disable all the analyses of the sink operations in paths passing through this method, use disable-stack. As with the other engine directives, make sure that you add it in the line immediately before the method declaration. For example:

To disable all the analyses of the sink operations that occur in the class, use disable. As with other engine directives, add it in the line immediately before the class declaration. For example:

If your Graph Engine analysis is intentionally blocked, it’s because Graph Engine identified something incorrect in your code. You must modify your code to unblock the analysis. Depending on the situation, you see one of these messages.

This code example produces multiple actions, such as a throw statement followed by a return statement.

A Graph Engine analysis attempt on this code results in the entire analysis being blocked and the User Action message is returned: Remove unreachable code to proceed with the analysis.

This code example reuses a variable, String input, in the same scope of a method.

A Graph Engine analysis attempt on this code path results in a User Action Violation on this path. Analysis on other paths can proceed. Sometimes other violations are returned. This message is returned: Rename or delete this reused variable to proceed with the analysis.

Graph Engine has these limitations.

• Error logs shown as Internal error. Work in progress. Please ignore indicate that the entry point’s analysis didn’t complete successfully. We’re working on fixing this issue. In the meantime, you must verify the validity of this error manually.
• Graph Engine handles unique class names. If the source code has two distinctly different files that have classes with duplicate names, Graph Engine fails with an error message: <example_class> is defined in multiple files. In cases like these, provide a --workspace subpath to the source directory that has only one of the file names, set --target to the second file name, then rerun the code-analyzer run command.
• Graph Engine doesn’t handle anonymous Apex script. Provide the class directory path as the --workspace that doesn’t include any anonymous Apex script.
• Graph Engine doesn’t handle namespace placeholders. Leave the namespace placeholder blank.
• Graph Engine supports Apex property chains with a depth of 2 or fewer. For example, Graph Engine supports Object.x but not Object.x.y.
• Graph Engine doesn’t scan Apex triggers.