I'm currently working with a client who relies heavily on Python Lambdas, and we typically use the Zip method for fast deployments. Recently, the client decided to integrate Snyk for security scanning, but I've come across concerns about whether Snyk can actually monitor Lambda zip files for vulnerable dependencies. I'm unsure about AWS Inspector as well. It seems we might have to move to the slower Docker image method for proper container analysis, which feels like a hassle. Has anyone else dealt with this situation?
3 Answers
This is a common issue with Python Lambdas, as the artifact is just a zip file in S3. Most scanners prefer having either the source code with lock files or a container image. You likely don't need to switch to Docker images for coverage. The best approach is to run Snyk during CI against the same dependencies you use to build your zip file. By scanning your requirements and built site-packages before deployment, you can catch vulnerabilities without needing Snyk to analyze the deployed zip directly.
I heard that Fossa CLI can unpack Lambda zips. It might be worth checking out if you need a different solution for scanning these files.
One option is to scan your code before zipping it up. You might also zip it and then pass it to Snyk as an artifact, unzipping it after scanning. This way, you can set up a gate to check for any vulnerabilities before deploying your infrastructure. It's worth exploring!
I get that point about implementing gates, but we usually deploy in stages and need to keep track of vulnerabilities across different accounts even after deployment. If we're sending the SBOM to Snyk, will it help us flag any necessary updates? How would Snyk know which accounts need attention?
Right now, we're only using a simple requirements.txt with basic floor pinning. However, we're considering adding lock files and possibly adopting uv. Still, I've seen that Snyk hasn't fully integrated support for uv.lock yet, which complicates things and forces us to find workarounds.