Container image scans

As defined by the Open Container Initiative (OCI) specifications, container images comprise a layered file system and associated metadata.

Container images often include several layers containing third-party software from:

• Operating system distributions, such as Debian, Ubuntu, or CentOS
• Application package managers, such as npm, pip, and RubyGems.

Snyk Container scans

When Snyk Container tests an image using any of the available integrations, Snyk first finds the software installed in the image, including:

• dpkg, rpm, and apk operating systems packages
• Popular unmanaged software (installed outside a package manager)
• Application packages that are based on the presence of a manifest file.

To determine the final filesystem, Snyk does not squash the layers of the container image into one. It scans for supported application package manifest files in each intermediate layer of the container image, even when those files are deleted by a subsequent layer.
Because Snyk reads the information from the file system, the container does not need to be run. This means that for a successful scan, no container or foreign code must be run.
After Snyk has the list of installed software, Snyk looks that up against the Snyk Vulnerability Database, which combines public sources with proprietary research.
Snyk supports testing OCI-compliant and Docker v2 complaint images but does not support images that combine both OCI and Docker v2 standards into a single archive.
by-snyk-container)
Snyk works directly with the security teams of the supported Linux distributions to provide the most accurate and reliable information on the affected packages (including fix availability). The specific package versions listed are those distributed by the official container source and may differ from the upstream package versions.

Unmanaged container software

Some software components from upstream providers are not installed using a package manager but are downloaded as executables from third parties. Snyk uses file fingerprinting to detect versions of the following components:

• Node.js
• OpenJDK 8 binaries

Snyk continuously discloses new vulnerabilities. Snyk can alert you to new vulnerabilities in your image as they are announced, even when your image software installed has not changed.
If you use an integration that saves a snapshot of the installed software on Snyk’s service and the image has not changed, Snyk Container automatically rescans without accessing the image, alerting you to new vulnerabilities.
If the image has changed, you must reimport your image, so that Snyk can access the updated image and its metadata before rescanning it.
Recurring scans do not detect updates to the dependencies of your applications. The recurring scans test for new vulnerabilities using a snapshot of your application dependencies at the time the application was imported. To detect changes in your application, such as updated dependencies, you must re-import your container image in Snyk.

Application vulnerability

Snyk Container detects application vulnerabilities in your container and overlaps Snyk Open Source capabilities. The results from the Snyk Container application vulnerability feature and Snyk Open Source are generally the same, especially if Snyk is building a dependency graph from the same manifest files. However, depending on the ecosystem and how the developer builds the application, results can vary significantly. An application in a container is a compiled application. So, in some ecosystems, Snyk Open Source can scan a more detailed manifest and thus build a more accurate dependency graph:

• golang - Projects for Snyk Containers: Snyk does not have access to the list of dependencies as in Snyk Open Source. Therefore, Snyk Container reverse parses binaries, and the result differs slightly from Snyk Open Source.
• npm - packages as Snyk Containers: Snyk can have access to the list of dependencies. The result is generally the same as in Snyk Open Source. Snyk container app-vuln scanning does not currently support npm-workspaces, v3 Lockfiles, or dev dependencies.
• java - applications for Snyk Containers: In Open Source, it is possible to include unmanaged jars. Thus the result is different from Snyk Container. With Snyk Container, the scan traverses all the jars Snyk finds in the image. In addition, there are multiple ways to build a jar, and this affects how Snyk Container finds the dependencies.

Detect the container base image

Detecting vulnerable base images allows you to identify the source of your vulnerabilities and fix them by updating the base image according to recommendations.

You can detect your base image after you configure a container integration such as the CLI or a container registry integration.

To identify vulnerable base images, you can use one of the following methods:

• Auto-detection - when Snyk analyses your container image, it extracts relevant metadata from the image manifest, and detects the base image. This method analyses rootfs layers from the image manifest, which can be equivalent to more than one image or image tag in DockerHub.
• Dockerfile - Snyk can also detect vulnerable base images using your Dockerfile. It can either be attached with a --file flag to your CLI snyk container test scan, linked from an SCM through your Project settings or detected and scanned when you import a Git repository. Compared to auto-detection, using your Dockerfile can be more accurate but requires an additional step. For multi-stage Dockerfiles, Snyk detects the base image included in the image introduced in the final FROM line. According to Docker's multi-stage build, this happens because using multiple FROM statements lets you "selectively copy artifacts from one stage to another, leaving behind everything you don't want in the final image."

For either method, a Project in the Snyk UI is created.

Image layer

When you scan a Docker image in Snyk, you can see the instruction in the image layer that introduces the vulnerability. You don't need to perform any action at this point.

Image layer information for Docker images

If the base image is a Snyk-supported image, the results include recommendations for upgrades to resolve some of the discovered vulnerabilities.
This allows you to see vulnerability counts in minor and major upgrades and in alternative base images, which might have fewer vulnerabilities. Based on this information, you can decide whether to upgrade your base image and which one is the best.
You can see the base image vulnerabilities in your Project among the vulnerabilities added by your instructions, sorted by their priority score.

Scan infrastructure

Feature availability IaC+ is a new version of Snyk IaC that includes more accurate results, an expanded security ruleset, and code-to-cloud capabilities. IaC+ is now in early access via Snyk Preview.

With Snyk Infrastructure as Code (IaC), you can secure cloud infrastructure configurations before and after deployment. There are two versions of Snyk IaC available today:

• Current IaC: The generally available version of Snyk IaC
• IaC+: A new version of Snyk IaC that is currently in early access

With both versions of Snyk IaC, you can:

• Write secure configurations for HashiCorp Terraform, AWS CloudFormation, Kubernetes, and Azure Resource Manager (ARM) - for IDE, SCM, CLI, and Terraform Cloud/Enterprise workflows.
• View issues and receive fix advice so you can make changes directly to the code before applications reach production.
• Detect drift and manually create resources in your cloud.
• Onboard, scan, and test deployed cloud environments for misconfigurations for AWS, Azure, and Google Cloud environments. IaC+ is built on a new engine and ruleset that also powers Snyk IaC’s cloud scanning capabilities. IaC+ enables the following improvements vs. Current IaC:
• Includes consistent support for languages - such as Azure Resource Manager - across all IaC workflows.
• Adds multi-file analysis for Terraform (support for modules and variables files).
• Utilizes an expanded security ruleset that is mapped to more than a dozen compliance standards (CIS Benchmarks, PCI, SOC 2, and more).
• Supports custom rules with Rego that are managed in the Snyk platform, and work consistently across all IaC workflows.
• Introduces projects (for SCM) that capture issues for an entire repository, instead of only for a single IaC file - in alignment with Snyk Code.
• Supports recurring (daily or weekly) scans for IaC+ SCM projects.
• Utilizes a new organization-wide Cloud Issues page for IaC+ and cloud issues that enables users to group issues by rule or resource, filter and inspect the configuration of relevant resources for a given issue, and take action on issues. IaC+ also adds support for “code to cloud” use cases that work with Snyk IaC’s ability to onboard, scan, and test deployed cloud environments:
• Fix Cloud issues directly in the IaC source code that was used to deploy the misconfigured cloud resources by linking a cloud issue to the underlying IaC template with an SCM source code link.
• Suppress false positives in IaC tests by applying context from deployed infrastructure.
• For Terraform - the same custom rule applies across the entire SDLC for all workflows (IaC to cloud).
• View an inventory of IaC and cloud resources generated from your IaC files via the resources API.

Ref: https://docs.snyk.io/scan-using-snyk/snyk-container/