opendatacube / datacube-wps

Web Processing Service running on opendatacube
Other
7 stars 3 forks source link

CVE alert (ansi-regex js) #134

Open benjimin opened 2 years ago

benjimin commented 2 years ago

Currently the automatic vulnerability checker is issuing an alert regarding ansi-regex < 5.0.1.

This is a node package (more motivation for #128); canvas requires gauge, and at present the latest version of gauge indirectly requires a vulnerable version of ansi-regex. Attempted running npm audit fix to no avail. Presumably need to wait for this to be fixed upstream: https://github.com/npm/gauge/issues/135

Not expecting any security impact, because our use of node is to render an image from data generated by the application (not supplied by the untrusted end client).

$ npm list ansi-regex  # check what versions currently installed
code@ /code
├─┬ canvas@2.8.0
│ └─┬ @mapbox/node-pre-gyp@1.0.6
│   └─┬ npmlog@5.0.1
│     └─┬ gauge@3.0.1
│       └─┬ strip-ansi@4.0.0
│         └── ansi-regex@3.0.0
├─┬ vega-cli@5.21.0
│ └─┬ yargs@17.2.1
│   ├─┬ cliui@7.0.4
│   │ ├─┬ strip-ansi@6.0.1
│   │ │ └── ansi-regex@5.0.1
│   │ └─┬ wrap-ansi@7.0.0
│   │   └─┬ strip-ansi@6.0.1
│   │     └── ansi-regex@5.0.1
│   └─┬ string-width@4.2.3
│     └─┬ strip-ansi@6.0.1
│       └── ansi-regex@5.0.1
└─┬ vega-lite@5.1.1
  └─┬ yargs@17.1.1
    └─┬ string-width@4.2.3
      └─┬ strip-ansi@6.0.1
        └── ansi-regex@5.0.1

$ npm view gauge version  # check if newer version exists yet
3.0.1
$ npm view strip-ansi version
7.0.1
benjimin commented 2 years ago

Seems to have been fixed upstream (with a major/breaking release of gauge, but whatevs). Our image presently contains only version 5.0.1 of ansi-regex, so npm audit is now happy.

benjimin commented 2 years ago

But, looks like CVE scanner continuing to fail because of docker cache (integrated into github action) continuing to reuse old version. (This is why --no-cache is important..)

benjimin commented 2 years ago

Updated scan to pull latest image, rather than build from scratch. I think this is more appropriate (regularly scan the deployed image, which may drift from a fresh re-build) and faster.

Still failing scan because: