Bugfix: make jfrog xray impact paths deterministic

[paulOsinski]

[sc-13285]

The OSS parser at dojo/tools/jfrog_xray_api_summary_artifact/parser.py picks impact_paths[0] from an unordered list returned by JFrog:

impact_paths = vulnerability.get("impact_path", [])
if len(impact_paths) > 0:
    impact_path = decode_impact_path(impact_paths[0])
...
file_path=impact_paths[0],
description=impact_path.name + ":" + impact_path.version + " -> " + vulnerability["description"],

When JFrog returns the same vulnerability's impact_path list in a different order, file_path and description shift between imports.

This can cause unexpected issues with deduplication because of drifting, unpredictable issue descriptions. This list should be ordered deterministically for consistency.

Fix
Sort impact_paths in the OSS parser so file_path and description are deterministic. Optionally list all paths in the description so developers see every location, not just one.

Change:
impact_paths = sorted(vulnerability.get("impact_path", [])) — every downstream use of impact_paths[0] (file_path, the decoded impact_path feeding unique_id, and the V3 LocationData) is now deterministic.
When more than one impact_path exists, description appends a Impact paths: list so developers see every location, not just one (which is a data model limitation)

[valentijnscholten]

Sounds like a good plan. It does mean that it might change the hash_code for many existsing findings occurring in reimports/imports leading to a one-time close/create frenzy.

[Maffooch]

Sounds like a good plan. It does mean that it might change the hash_code for many existsing findings occurring in reimports/imports leading to a one-time close/create frenzy.

Agreed with Val - description is a default hash code setting for this perser. @paulOsinski can you pleas rebase to the dev branch and add some release notes letting folks know how to rerun their hash calculations?

[valentijnscholten]

recalculating the hash won't help as the descripton is not retroactively changed.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[paulOsinski]

@Maffooch did you see Val's comment? He's right, the description will change along with the hash code so it's not like recalculating will do anything. This will still create "net new" Findings but those are being created anyway by this parser.

[Maffooch]

Okay, so I think that leaves us with two options

1. Change this parser, and findings will have go through the closed/open loop
2. Make a v2 of this parser
   It seems like findings are already doing the closed/open loop today, so option 1 may not be that bad

@valentijnscholten would you agree?

[valentijnscholten]

I think this time we'll have to accept option 1.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.