2

When using AWS inspector for ECR images, the results mentioned vulnerabilities that don't seem to be installed on the image.

This article from snyk discusses how AWS Inspector is using Snyk to help with it's detecting.

Question:

My question is does AWS inspector or Snyk include package vulnerabilities that are in yarn.lock but not installed?

Is this the convention for other package inspectors, to include vulnerabilities in packages that aren't installed but are listed as dependencies?

This doesn't make sense, why would it be a vulnerability if the package is not actually installed.

More Info:

The reason I don't think the package is installed is because when I run npm list (docs) the vulnerable package is not listed.

Also when I test locally I don't see a node_models folder with the suspected package. I do see it listed in a yarn.lock file.

(The suspected package is a devDependency of a dependency of a dependency of a package that is installed globally)

Side Notes:

When I run npm audit (docs) I don't see any security issues listed. npm audit has it's own issues with listing vulnerabilities that may not be a real issue (see here and enter link description here), but at least it's not listing packages that aren't even installed.

This question may be dependent on this question, regarding devDependencies being installed when installing a package (globally).

shmuels
  • 1,039
  • 1
  • 9
  • 22
  • 1
    Yes, in my experience it is picking up devDependencies listed in yarn.lock, even though they aren't actually installed in the docker image. – Mark B Mar 31 '22 at 19:27
  • @MarkB Am I correct in understanding that it's not a vulnerability if it's not installed? And that AWS Inspector should not include those vulnerabilities in their report? – shmuels Apr 04 '22 at 15:23
  • There is another case happening with me. Its picking vulnerability from yarn.lock files that belong to dependency (e.g. from a package inside node_modules) but that are not actually installed. Is there a way to avoid this false positives? – Diogo Melo Nov 03 '22 at 12:13

1 Answers1

1

We solved this problem by manually deleting all yarn.lock files from our docker images as the last step:

RUN yarn install --production --silent --pure-lockfile --cache-folder /usr/app/yarn-cache  \
    # get rid of all yarn.lock files as the AWS Inspector thinks they contain vulnerabilities
    && rm -rf ./yarn-cache \
    && find . -type f -name 'yarn.lock' -delete

obviously the bit about the --cache-folder may not be relevant to you, we just keep the cache around through our multistage builds to speed things up

Joey
  • 11
  • 1