Interpret scan results

Support API docs Product updates Sign up for free
Search…
The Projects page will contain an inventory of all projects added and a high level summary of findings. You can expand on a particular project to learn more about vulnerabilities that may have been found and guidance on how to fix these or optimizations. Let's walk through some examples.
The figure below shows the two workloads we imported in the previous section. These have been expanded to show that the results are including two key areas: Kubernetes configuration and container image scan results. Clicking on each of these will present you with additional insights.
Let's begin with examining our Kubernetes configuration by click on each respective workload.
The results above yield some interesting findings. From this view, we are able to see a summary of Vulnerabilities, number of Dependencies, and our Security configuration. Let's take a closer look and interpret what these results mean.
If we examine the azure-vote.yaml manifest we applied to our Kubernetes cluster, we can see that we defined some parameters such as cpu and memory limits. As a result, these were not flagged during the scan.
1
resources:
2
  requests:
3
    cpu: 100m
4
    memory: 128Mi
5
  limits:
6
    cpu: 250m
7
    memory: 256Mi
Copied!
However, our manifest did not set securityContext parameters such as readOnlyRootFilesystem, runAsNonRoot, allowPrivilegeEscalation, and capabilities. As a result, we see this in our findings with the FAIL flag.
Run as non-root: Whether any containers in the workload have container.securityContext.runAsNonRoot set to false or unset.
Read-only root file system: Whether any containers in the workload have container.securityContext.readOnlyFilesystem set to false or unset.
Drop capabilities: Whether all capabilities are dropped and CAP_SYS_ADMIN is not added.
Next, let's take a closer look at our container image results:
Here we are immediately advised that a Dockerfile is missing. We know this to be true, because our deployment consisted of a manifest file that is pulling an image from a public registry. In the case of our vote-back and vote-front applications we are pulling the image from redis and microsoft/azure-vote-front:v1 respectively.
A best practice here would be to include a Dockerfile in our Git repo and pull the image from our private registry. That way we can resolve any issues with our base images and also scan & monitor those through Snyk's integrations to Azure Repos and Azure Container Registry (ACR).
We will dive into these in a later workshop.
Add Kubernetes workloads
Fix issues
Last modified 8d ago
Export as PDF
Copy link
Edit on GitHub