Static Application Scanning (SAST) is the principle of looking for well-known security issues at compile time. it spans tools that look for common coding errors (super lints), tools that are dictionary-based (e.g. looking up CVE), and looking for well-known configuration errors.

Our practice with SAST is to run it in our CI pipeline on build. This can sometimes be a bit irritating since the build will suddenly fail due to a newly-found error. But, its better than shipping that problem to our customers.

So, lets give this a try with Angular 10. Brand shiny new.

$ ng new --defaults npm-audit-angular
$ cd npm-audit-angular
$ npm ci
$ npm audit
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ lodash                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ No patch available                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ @angular/cli [dev]                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ @angular/cli > inquirer > lodash                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1523                            │
└───────────────┴──────────────────────────────────────────────────────────────┘
...
found 281 low severity vulnerabilities in 1465 scanned packages
  281 vulnerabilities require manual review. See the full report for details.

OK, that’s not good, we have 281 issues and we haven’t even started! Worse, at this writing, there is no fix (https://github.com/lodash/lodash/pull/4759 has been merged tho).

So, the technique we can use… eyeball the error and assess whether we want to block our release. If we don’t, we can use better-npm-audit:

$ npm install --save-dev better-npm-audit
# edit package.json, insert audit script:
{
  "name": "npm-audit-angular",
  "version": "0.0.0",
  "scripts": {
 ...
    "e2e": "ng e2e",
    "audit": "node node_modules/better-npm-audit audit -i 1523"
  },
$ npm run audit

So now we can run audit, we have (temporarily) ignored 1523, pending a new release. Now, once the new release comes up, we will run into the second problem: some packages we rely on will still pin to the unfixed version. So then we will use npm-force-resolutions.

Share This

Share this post with your friends!