Risk factor: Deployed
Last updated
Was this helpful?
Last updated
Was this helpful?
The Deployed risk factor is available only for Snyk AppRisk users.
Any deployed code increases the risk of exploitation of your application and business.
Understanding what code is deployed and where enables you to adopt a remediation strategy that reduces your risk surface area from running code.
The Deployed risk factor works with the Kubernetes Connector, the Snyk Runtime Sensor, and third-party integrations.
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 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:
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.
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 the image name and apply the Deployed risk factor to all issues associated with this Snyk Container Project.
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.
The Snyk Runtime Sensor applies the Deployed risk factor by constantly monitoring the active containers within a Kubernetes cluster. It does this by capturing real-time Kubernetes events and taking hourly snapshots of the cluster's state. These real-time data and snapshots help identify which images are currently being deployed. By comparing this information with Snyk Projects and known vulnerabilities, the Snyk Runtime Sensor accurately assesses deployed risks. This ensures that security insights are up-to-date and reflect the current deployment environment.
The Deployed risk factor is extended to third-party integrations through real-time monitoring of Kubernetes clusters, along with data from external sources. This enables a comprehensive assessment of deployed risks across diverse environments. By integrating with third-party tools, Snyk can cross-reference vulnerabilities from various sources, ensuring that the deployed risk factor reflects the most accurate and current threat landscape. This holistic approach allows Snyk to provide actionable insights and maintain robust security postures across all integrated platforms.
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.
