nodejs/nodebestpractices
1
0
Fork 0
mirror of https://github.com/goldbergyoni/nodebestpractices.git synced 2025-10-28 03:25:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Scan images - First draft

Browse Source
This commit is contained in:
Yoni
2020-06-12 15:14:02 +03:00
parent 9dd5faf1b4
commit def07fa01c
2 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -1143,11 +1143,11 @@ Bear in mind that with the introduction of the new V8 engine alongside the new E
## ![✔] 8.7. Scan your image for vulnerabilities
**TL;DR:**
**TL;DR:** Besides checking code dependencies vulnerabilities, also scan the final image that is shipped to production. Docker image scanners check the code dependencies but also the OS binaries. This E2E security scan covers more ground and verifies that no bad guy injected a vulnerability during the build. Consequently, it recommended running this as the last step before deployment. There a handful of free and commercial scanners that also provide CI/CD plugins
**Otherwise:**
**Otherwise:** Your code might be entirely free from vulnerabilities. However, it might still get hacked due to vulnerable version of OS-level binaries (e.g. OpenSSL, TarBall) that commonly being used by applications
🔗 [**Read More: Scan your image for vulnerabilities**](/sections/docker/file.md)
🔗 [**Read More: Scan your image for vulnerabilities**](/sections/docker/scan-images.md)
<br /><br /><br />

2
sections/docker/scan-images.md
View File

@ -4,7 +4,7 @@
### One Paragraph Explainer
Scanning the code vunlerabilities is obviously a valuable act but it doesn't cover all potential threats. Why? Because CVEs exist also on the OS level and your code might execute a vunlerable version of Shell, Tarball or OpenSSL. In addition, vunbelerable dependencies might be injected after the code scan (i.e. supply chain attacks) hence a last comprehensive scan of the final deliberable image is in order. This resembles E2E tests - after testing the various pieces in-isolation, it's valuable to finally check the overall. There are more than a handful of tools that scans the entire Docker image, Scanners comes in 3 main flavours: Local/CI binaries with a cached vunlerabilities DB, scanners as a service in the cloud and a niche of tools who can scan during the docker build itself. The first group is the most popular and usually the faster, tools like Trivvy, Anchore and Snyk are worth exploring. Most CI vendors provide a local plugin that facilitate the interaction with these scanners. It should be noted that these type of scanners cover a lot of ground and therefore will find CVEs in almost every scan - consider setting a high threshold bar to avoid getting overwhelmed
Scanning the code for vulnerabilities is a valuable act, but it doesn't cover all the potential threats. Why? Because vulnerabilities also exist on the OS level and the app might execute those binaries like Shell, Tarball, OpenSSL. Also, vulnerable dependencies might be injected after the code scan (i.e. supply chain attacks) - hence scanning the final image just before production is in order. This idea resembles E2E tests - after testing the various pieces in-isolation, it's valuable to finally check the assmebled deliverable. There are 3 main scanner families: Local/CI binaries with a cached vulnerabilities DB, scanners as a service in the cloud and a niche of tools which scan during the docker build itself. The first group is the most popular and usually the fastest - Tools like [Trivvy](https://github.com/aquasecurity/trivy), [Anchore](https://github.com/anchore/anchore) and [Snyk](https://support.snyk.io/hc/en-us/articles/360003946897-Container-security-overview) are worth exploring. Most CI vendors provide a local plugin that facilitates the interaction with these scanners. It should be noted that these scanners cover a lot of ground and therefore will show findings in almost every scan - consider setting a high threshold bar to avoid getting overwhelmed
<br/><br/>