Hey everyone! I'm starting to use Snyk for my AWS Lambda functions (mostly Node.js). I'm a bit confused about how it handles the deployment package.
I'm packaging my dependencies into a zip file for deployment. When I run Snyk in my CI/CD pipeline, it's scanning my `package.json` locally. But what about the actual code and modules inside the final zip? Does Snyk understand the bundled deployment package, or am I missing vulnerabilities that end up in the final artifact?
Also, if I use layers or container images for my Lambda, does the scanning approach change? Any best practices for setting this up? I want to make sure what gets deployed is actually what was scanned. 😅
That's a crucial distinction to make, and your concern is valid. Scanning the local `package.json` alone creates a potential gap, as your final zip artifact could contain modules installed from a different, or cached, registry that don't match the exact versions in your lockfile.
For the zip package itself, you need to scan the built artifact. In CI/CD, you should run `snyk test` against the *unzipped* deployment directory *after* the `npm install` step that populates `node_modules` for packaging. This ensures you're testing the actual dependencies that will be bundled. The Snyk CLI can target a directory path directly. For layers, the same principle applies, scan the layer's content directory before packaging. Container images for Lambda are a different case, where you'd use `snyk container test` on the built image.
The core best practice is to move the Snyk scan later in your pipeline, just before the final `zip` or `docker build` command, acting on the exact file system that gets packaged. This aligns the scan target with the deployment artifact, closing that loop.
Exactly. Scanning just the `package.json` creates a blind spot, because the installed modules in `node_modules` are the real artifacts that get zipped. Your CI process should mirror your local build, so the scan must happen after the dependencies are installed and before they're packaged.
For a typical Jenkins or GitHub Actions workflow, that means your sequence is: 1) `npm ci`, 2) `snyk test --all-projects` on the directory containing `node_modules`, 3) `zip -r function.zip .`. This guarantees you're testing the exact dependency tree being deployed.
Regarding layers and containers, the principle is identical: scan the filesystem of the artifact you're building. For Lambda layers, point Snyk at the layer's root directory. For container images, use `snyk container test`. The critical error I see teams make is scanning early in the pipeline and then allowing subsequent steps to modify dependencies without a secondary scan.
You're right to be suspicious. The gap between your package.json and what actually gets zipped is the whole game. I've seen pipelines where a cached node_modules folder or a slightly different npm registry source introduces a version mismatch. Snyk reports clean, but the deployed artifact has the bad code.
The advice to scan after install is correct, but there's a catch: what about your zip step pulling in files from outside the current directory? If your build script grabs modules from some other pre-baked location, you're still not scanning the real payload. You need to point Snyk at the exact directory tree that's about to be zipped, right before the zip runs.
For layers, it's the same headache. If you're building a layer from a Dockerfile, scanning the source directory is pointless. You have to scan the built layer archive or the image itself. Container images are easier, just use `snyk container test`. But for zip packages, you're basically doing forensic reconstruction of the final artifact.
Data over dogma.