snyk-labs / snyk-bulk

Collection of docker entrypoints that facilitate snyk '--all-projects'-style bulk scanning
Apache License 2.0
9 stars 12 forks source link

workaround for handling node workspaces #64

Open chris-walz opened 1 year ago

chris-walz commented 1 year ago

What does this PR do?

This checks whether each package.json file contains workspaces and if so, creates an empty node_modules directory in each one so the Snyk CLI won't error out when trying to scan it.

I added a node project under testrepos that uses a couple workspaces and it's able to scan it now (instead of returning an error that it's missing a package-lock.json).

Where should the reviewer start?

How should this be manually tested?

You can test it against the new test repository using the instructions in the README

docker run -e SNYK_TOKEN snyk-bulk:node \
  --test --target /root/testrepo/node_workspaces \
  --remote-repo-url https://github.com/snyk-tech-services/snyk-bulk --json-std-out

Any background context you want to provide?

What are the relevant tickets?

Screenshots

Additional questions

scott-es commented 1 year ago

@chris-walz currently reviewing this... I wonder why the checks dont run, maybe becuase its not set to run on PRs from forks? will look into that too.

chris-walz commented 1 year ago

@scott-es I think it's a security feature to prevent people running arbitrary things on your workflows. This says there should be an "approve and run" button somewhere on this PR (assuming you have permission to approve it) https://docs.github.com/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks

scott-es commented 1 year ago

hey @chris-walz , in reviewing this, I'm thinking that the same method used to support yarn workspaces can also be leveraged. In doing some quick testing in seems to work fine here too.

for yarn workspace, the approach was to create a sym link in the container for the root yarn.lock into each subdirectory with a package.json file. This results in snyk CLI using the package.json to know which dependencies are included for this particular project (e.g. package.json) while using the lock file to resolve the accurate version.

When testing the same approach in sym-linking the root package-lock.json into each sub-directory it seems to work fine too. This may be more accurate than creating an empty node_modules folder, I dont think it will be able to get all the correct versions of the deps.

Here is where we do it in for yarn https://github.com/snyk-labs/snyk-bulk/blob/b506eacc224643c379f62df664a475feb929a875/entrypoints/node.sh#L92

chris-walz commented 1 year ago

Thanks @scott-es ! I remember trying the trick with linking the lock file and running into problems. From what I remember the scan would complete but the list of dependencies wasn't correct for the workspace being scanned. I'll try it again to see if I can give you an example. It's also equally likely I did something wrong and it was actually working right.