Resolved Issues
Not all vulnerabilities and issues you discover with Sandworm are addressable by code alone. You may want to mark an issue as resolved when:
- A fix has already been started
- There is no bandwidth to work on a fix right now
- The risk is tolerable for the project
- The issue is inaccurate or incorrect
- The vulnerable code is not actually used
When running an audit, Sandworm looks for a
resolved-issues.json
file in the root directory of the app being audited. The resolved issues file should contain a json array of objects, each object describing a resolved issue.A resolved issue is described by the following attributes:
id
- the GitHub advisory id or the Sandworm issue idpaths
- the current dependency tree paths to affected package versionsnotes
- resolution notes
Here's an example resolved issues file:
resolved-issues.json
1
[
2
{
3
"id": "GHSA-36jr-mh4h-2g58",
4
"paths": [
5
"d3-node>d3>d3-brush>d3-interpolate>d3-color",
6
"d3-node>d3>d3-brush>d3-transition>d3-color",
7
"d3-node>d3>d3-brush>d3-transition>d3-interpolate>d3-color",
8
"d3-node>d3>d3-color",
9
"d3-node>d3>d3-interpolate>d3-color",
10
"d3-node>d3>d3-scale>d3-interpolate>d3-color",
11
"d3-node>d3>d3-scale-chromatic>d3-color",
12
"d3-node>d3>d3-scale-chromatic>d3-interpolate>d3-color",
13
"d3-node>d3>d3-transition>d3-color",
14
"d3-node>d3>d3-transition>d3-interpolate>d3-color",
15
"d3-node>d3>d3-zoom>d3-interpolate>d3-color",
16
"d3-node>d3>d3-zoom>d3-transition>d3-color",
17
"d3-node>d3>d3-zoom>d3-transition>d3-interpolate>d3-color"
18
],
19
"notes": "Vulnerable code not actually used"
20
}
21
]
Commit the
resolved-issues.json
file to your repository for full historical visibility into who resolved what & when.For longer resolution notes, we suggest creating a markdown file in a dedicated directory in your repository, and pointing to that file in the resolution note.
Paths help segment the packages affected by an issue into multiple categories. Paths are used to provide granular resolutions, and also help identify potentially new uses of vulnerable package versions.
Let's say your app depends on
packageA
and packageB
, who both depend on packageC
. A vulnerability is identified in packageC
. After analysis, you conclude that:packageA
doesn't use thepackageC
functions exposing the vulnerability;packageB
does use a vulnerable function inpackageC
, but properly escapes user input so the vulnerability is avoided.
You'll want to create two resolutions: one for path
packageA>packageC
and one for path packageB>packageC
:resolved-issues.json
1
[
2
{
3
"id": "GHSA-one",
4
"paths": [
5
"packageA>packageC",
6
],
7
"notes": "Vulnerable code not actually used"
8
},
9
{
10
"id": "GHSA-one",
11
"paths": [
12
"packageB>packageC",
13
],
14
"notes": "User input is properly escaped by `packageB` in `src/generate.js`"
15
}
16
]
Now let's say you install
packageD
, and that too turns out to depend on a vulnerable version of packageC
. Sandworm's audit would label this as a new issue, since there's no resolved path that matches the new packageD>packageC
. To mark this as fixed, either:- Add the
packageD>packageC
path to one of the existing resolutions, if the same notes apply to the new situation; - Or, create a new resolution, specific for the
packageD>packageC
path.

Running Sandworm Audit
Instead of manually managing the
resolved-issues.json
file, you can use sandworm resolve [issueId]
. The command-line tool makes a number of validations, and walks you through creating a new resolution or attaching a new path to an existing resolution.The output of
sandworm audit
includes issue ids that you can resolve
:
After running
sandworm resolve [issueID]
on one of the detected issues, you specify one or more paths to address:
If any existing resolutions share the same issue id,
resolve
prompts you to either create a new resolution, or attach the new paths to an existing one:
Last modified 4d ago