Deployed
Any code that is deployed poses more risk to your application and business as it has an increased likelihood of being exploited.
Understanding what code is deployed and where enables you to adopt a remediation strategy focused on reducing your risk surface area from running code.
Snyk AppRisk determines that a container image is deployed by looking for a match between the running images on the Kubernetes cluster and the created Snyk Container Projects. Snyk AppRisk uses Kubernetes state information to extract Docker image identifiers that are currently being executed. The status of a Kubernetes container has image names that are being run by the Kubernetes runtime. A search is performed on the database of known Docker images to find matching names. When the image names are matched, Snyk can display this information in a graph. The graph shows the relationship between the image and the container.
Kubernetes is very specific about how images are managed. Snyk uses the same logic to map the images Snyk knows about. Whenever you scan an Image with Snyk Container, Snyk collects information about the image name and image ID. Snyk uses this information to map images against information from Kubernetes.
Snyk adheres to the defined naming standards as documented for Kubernetes and Docker images to ensure consistency with Kubernetes.
Consider the following examples:
| User-provided name in Kubernetes manifest | Name used in matching | Changed (yes/no) |
|---|---|---|
gcr.io/my-company/my-app:production | gcr.io/my-company/my-app:production | No |
gcr.io/my-company/my-app:latest | gcr.io/my-company/my-app:latest | No |
gcr.io/my-company/my-app | gcr.io/my-company/my-app:latest | Yes - latest tag appended |
my-app | docker.io/my-app/my-app:latest | Yes - defaulted to Docker public registry, latest tag appended |
The matching uses the following order of precedence, where the first step must pass for at least one Snyk Container Project, and the subsequent steps further validate the match.
Match the image name, for example,
gcr.io/my-company/my-app:latest.Match the image digest.
Group Snyk Container Projects by image digest.
Consider the examples that follow.
Example one: Using Snyk Container CLI
Result: Image successfully matched, and risk factor applied
The container image is scanned using the Snyk Container CLI only, referencing the full name of the image, including the registry. Snyk recommends doing this after the image is built and before it is deployed to your cluster.
An example scan follows:
$ snyk container monitor gcr.io/my-company/my-app:latest
The image is deployed to your Kubernetes cluster with this example manifest:
spec:
containers:
- name: my-app
image: gcr.io/my-company/my-app:latest
This enables Insights to successfully match on the image name and apply the Deployed risk factor to all issues associated with this Snyk Container Project.
Example two: Using Snyk Container CLI and a container Registry
Result: Image successfully matched, and risk factor applied
The container image is scanned referencing a partial name, omitting the container registry.
An example scan follows:
$ snyk container monitor my-app:latest
Insights is not able to match this Project as the names do not match.
The image is deployed to your Kubernetes cluster with this example manifest.
spec:
containers:
- name: my-app
image: gcr.io/my-company/my-app:latest
In addition, the same image is scanned by the container registry.
This creates a Project with the full name of the image, including the registry, enabling a match to be made.
This also includes the image digest.
Insights is then able to group all Snyk Container Projects by image digest, enabling a deployment match on the CLI Project with the partial name through the container registry Project.
This enables Insights to successfully match both Snyk Container Projects and apply the Deployed risk factor to all issues associated with those Projects.
Snyk recommends always specifying the full name of the image in your CLI command. If you are not able to do this, Snyk recommends also scanning the same image using a second integration.
Technical details for Snyk Insights Deployed risk factor
The Kubernetes Connector continuously monitors the Kubernetes events. These events are streamed to the Snyk platform continuously.
On a regular schedule, every hour, the data pipeline performs a reconciliation of the state of the cluster to create a snapshot. This snapshot is used to determine what images are being run in the cluster.
At the same interval, the data pipeline takes a snapshot of all Snyk Projects and data sources and extrapolates packages and images. This snapshot is used to determine which images and packages are known to Snyk for any given customer.
Both snapshots are then compared, and evidence graphs are generated to determine the deployed facts at that point in time.
Last updated
