[STAL-2643] Export taint analysis violations to SARIF

[jasonforal]

Notes

• Ignore the "Clean up serialization of Violation on the server." commit -- this will be merged via Clean up serialization of violations on the server. #514
• The CI failure is expected and unrelated to this PR. It will be fixed automatically when this branch is rebased on main.=

What problem are you trying to solve?

Violations from our Java taint analysis implementation are represented by a flow of taint from a source variable to a sink method (and thus it has multiple "code regions" associated with it). This is distinctly different than a "standard" static analysis violation, which only has one code region.

So while we can detect and flag taint flow violations within rules, we can't currently export the flows via SARIF.

What is your solution?

codeFlows in SARIF

This PR modifies our SARIF output to include a "codeFlows" field in an analysis result.

The codeFlows property is intended for use by analysis tools that provide execution path details that illustrate a possible problem in the code.

You can see example JSON output here.

JavaScript Violation API

As part of this, the Violation class constructor has been changed to allow for more permissive passing in of objects/parameters to be interpreted as code regions in violations.

Before, a violation had to be created like

const v = new Violation(node.start.line, node.start.col, node.end.line, node.end.col, "message here");

Now, the constructor accepts a string message and is variadic for the rest of the properties. All of the following now work (and are equivalent in terms of the resulting region):

// "old" style
const v = new Violation("message here", node.start.line, node.start.col, node.end.line, node.end.col);
// Passing in a TreeSitterNode
const v = new Violation("message here", node);
// Passing in positions
const v = new Violation("message here", node.start, { line: node.end + 1, col: node.col });

Additionally, a TaintFlow can be passed in:

const flows = ddsa.getTaintSources(node);
const flow = flows[0];
const v = new Violation("message here", flow);

Note that this doesn't affect the old stella buildError API.

Small details:

• A taint flow's fingerprint is a combination of all of the code regions it has in the flow. This uses the same methodology as our existing fingerprint.
• A taint flow is ignored if any of its regions would be ignored (regardless of which specific line has the "base" violation).

Alternatives considered

What the reviewer should know

[juli1]

reviewing the code, it seems to replace the existing mechanism to handle position to annotate and integrate this with data flow. we should have a position that is used for annotation. and if there is data flow, we add this information on top. we should not merge these two concepts.

[juli1]

Can we at least document the need for PhantomData?

[jasonforal]

Sure, I'll add intra-doc links