Container Vulnerability Assessment
The information on this page has moved
For the most up to date Container Vulnerability Assessment (CVA) guidance, go to Learn About Vulnerabilities.
Feature Overview
What is Container Vulnerability Assessment?
The Container Vulnerability Assessment (CVA) service (previously Container Vulnerability Assessment or CVA) is designed to continuously assess all container images specified in production workloads to detect installed packages with known vulnerabilities. Container image IDs are harvested from your configured cloud accounts and a copy is pulled from the source registry. The package inventory and vulnerabilities detected on each image are presented in the InsightCloudSec platform for review, prioritization, and response. Users can determine and evaluate the riskiest resources by focusing on business segments such as deployed workloads and applications.
CVA also analyzes the configured Workload (Workload Definition) used while instantiating a new workload instance.
Terminology
Term | Description |
---|---|
Container Registry | A container registry is a service that stores and distributes container images and related artifacts. |
Container Repository | A repository is a collection of container images or other artifacts in a registry that have the same name but different tags. For example, the following three images are in the acr-helloworld repository: - acr-helloworld:latest - acr-helloworld:v1 - acr-helloworld:v2 |
Repository Namespace | Repository names can also include namespaces. Namespaces allow you to identify related repositories and artifact ownership in your organization by using forward slash-delimited names. However, the registry manages all repositories independently, not as a hierarchy. For example: - marketing/campaign10-18/web:v2 - marketing/campaign10-18/api:v3 - marketing/campaign10-18/email-sender:v2 - product-returns/web-submission:20180604 - product-returns/legacy-integrator:20180715 Repository names can only include lowercase alphanumeric characters, periods, dashes, underscores, and forward slashes. |
Container Image/Artifact | A container image or other artifact within a registry that is associated with one or more tags, has one or more layers, and is identified by a manifest. |
Tag | The tag for an image or other artifact specifies its version. A single artifact within a repository can be assigned one or many tags and may also be untagged. That is, you can delete all tags from an image, while the image's data (its layers) remain in the registry. The repository (or repository and namespace) plus a tag defines an image's name. You can push and pull an image by specifying its name in the push or pull operation. The tag latest is used by default if you don't provide one in your Docker commands. |
Manifest | Each container image or artifact pushed to a container registry is associated with a manifest. The manifest, generated by the registry when the content is pushed, uniquely identifies the artifacts and specifies the layers. |
Manifest digest | Manifests are identified by a unique SHA-256 hash or manifest digest. Each image or artifact, whether tagged or not, is identified by its digest. The digest value is unique even if the artifact's layer data is identical to that of another artifact. This mechanism is what allows you to repeatedly push identically tagged images to a registry. For example, you can repeatedly push myimage:latest to your registry without error because each image is identified by its unique digest. You can pull an artifact from a registry by specifying its digest in the pull operation. Some systems may be configured to pull by digest because it guarantees the image version being pulled, even if an identically tagged image is pushed later to the registry. |
Container Platform | A service allowing to define and run workloads that are based on container images. |
Workload Definition | Refers to the definition of a workload. Some container platforms support defining the workload before any instance is created. For example Kubernetes allies to define a Workload Set. There are, however, container platforms, such as AWS App Runner, that do not support workload definition as a separate entity. |
Workload Instance | The running entity of a workload. For example, in Kubernetes the Pod is a workload instance of the Workload Set. |
Deployed Images | Deployed images refer to the container images referenced by the workload definition. Note that a deployed image is not necessarily running. |
Feature Coverage
Container Service Platforms
- EKS / EKS-Fargate - AWS
- GKE - GCP
- AKS - Azure
- ECS-Fargate - AWS
- ECS - AWS
Container Image Registries
- ECR - AWS
- GCR - GCP
- ACR - Azure
- DockerHub - Docker (Public Registry)
Supported Package Types
Category | What is supported |
---|---|
Operating System (OS) | "alpine" "amazon" "debian" "photon" "centos" "rocky" "alma" "fedora" "oracle" "redhat" "suse" "ubuntu" |
OS Package | "apk" "dpkg" "rpm" |
Image Config | "apk-command" |
Structured Config | "yaml" "toml" "json" "dockerfile" "hcl" "terraform" |
Programming Languages | Dependency Configuration Formats |
---|---|
Ruby | "bundler" "gemspec" |
Rust | "cargo" |
PHP | "composer" |
JAVA | "jar" |
Node.js | "npm" "node-pkg" "yarn" |
.NET | "nuget" |
Python | "python-pkg" "pip" "pipenv" "poetry" "wheel" |
Go | "gobinary" "gomod" |
Prerequisites
Before getting started with Container Vulnerability Assessment (CVA) you will need to have the following:
- A functioning InsightCloudSec Platform installation
- InsightCloudSec Admin permissions (Domain or Org Admin)
- Appropriate access to the container image registry
- Customers will need to add a role to InsightCloudSec with permissions to read from the container image registry where container images are stored
- Any image that is on an account that is not visible to InsightCloudSec will not be scanned
Harvesting Kubernetes Workloads
Kubernetes clusters are harvested by the Kubernetes Scanners for Kubernetes Security Guardrails. If you want to have the workloads deployed into a Kubernetes cluster scanned for vulnerabilities using CVA you should have Kubernetes Security Guardrails enabled and installed on the cluster.
Permissions
AWS Role Permissions
The role that will be associated with the InsightCloudSec CVA feature will need the following AWS permissions:
text
1ecr:Get*2ecr:List*3ecr:Describe*4ecr:Batch*
Azure Role Permissions
The role that will be associated with the InsightCloudSec CVA feature will need the same permissions as the Azure Reader role identified here.
GCP Role Permissions
The role that will be associated with the InsightCloudSec CVA will need the same permissions as the Storage Object Viewer role (roles/storage.objectViewer
). Additional details on GCP IAM Roles can be found here.
text
1resourcemanager.projects.get2resourcemanager.projects.list3storage.objects.get4storage.objects.list
Viewing Permission Details
For users with accounts that are set up and running, you can view missing CVA permissions through associated cloud accounts.
- Navigate to Cloud > Clouds and on the listing tab, browse to the name of the cloud account you want to review.
- Scroll to the right to view additional columns and locate the column titled Visibility.
- In the row of the cloud account you want to view, click on the status icon to display details about the target cloud account.
Accounts with a yellow warning icon will contain details in this Cloud Status about missing permissions for specific resources.
Feature Architecture
The Container Vulnerability Assessment operation is composed of the following steps:
- Workload definitions are being harvested using the default InsightCloudSec harvesting capabilities
- Container images included in each workload definition are being identified
- Container images are being pulled out of the related container image registry and are analyzed creating the container image metadata
- InsightCloudSec continuously resolves/update container images to ensure we have the latest and greatest image pointed by the workload configuration.
- Container image metadata is processed, analyzed, and vulnerabilities are identified. This process is repeated every 24 hours, any new vulnerabilities that are reported are also updated.
- The workload definition data and the container image vulnerability data are combined so that the user can obtain data that allows them to understand which vulnerabilities are associated with each workload. This provides the user with concrete actionable information related to the threat that the vulnerabilities represent to the application.
Using Container Vulnerabilities
Container Vulnerability Assessment (CVA) is available from the main navigation in InsightCloudSec under Security > Container Vulnerabilities.
Viewing Vulnerability Findings
Vulnerability findings display on the landing page/Default Report tab and include a summary of: Workloads, Containers, Packages, and Vulnerabilities.
This report (currently only one at a time) is updated every time a new element is updated (for example: a new workload definition or a new container image is added), or whenever a new vulnerability is detected. Otherwise vulnerabilities are updated every 24 hours.
Columns (most are sortable) for each report (click the tabs to view the columns available for each report):
Workload
Column | Description |
---|---|
Risk Score | Risk score is the max risk score from all vulnerabilities associated with the workload. |
Workload | Name of the workload |
Cloud | Cloud Service Provider for the workload |
Cloud Account | Cloud Account for the workload |
Cluster | Cluster for the workload |
Container Service | Container service for the workload |
Last Assessment | Date and time of last assessment for the workload |
Severity | Severity is the max severity from all vulnerabilities associated with the workload (None, Low, Medium, High, Critical) |
Containers
Column | Description |
---|---|
Risk Score | Risk score for the container vulnerability. |
Container Name | The name of the container |
Image | The full name of the image used by the container (includes the tag) |
Tag | The tag for the image used by the container |
Last Assessment | Date and time of last assessment for the container |
Severity | Severity assigned to the container vulnerability (None, Low, Medium, High, Critical) |
Packages
Column | Description |
---|---|
Risk Score | Risk score for the package vulnerability. |
Package Name | The name of the package |
Version | The package version |
Severity | Severity assigned to the package vulnerability (None, Low, Medium, High, Critical) |
Vulnerabilities
Column | Description |
---|---|
Risk Score | Risk score for the associated Common Vulnerabilities and Exposures (CVE) database entry. |
CVE Title | The title for the CVE. |
CVSS Severity | The Common Vulnerability Scoring System (CVSS) severity assigned to the vulnerability (None, Low, Medium, High, Critical) |
Package Name | The name of the package associated with the vulnerability |
Version | The version of the package associated with the vulnerability |
First Found | Date and time that the vulnerability was first recorded |
Exploring Your CVA Report
The Container Vulnerabilities report offers two main exploration capabilities: the Search and Filtering capabilities. Clicking to the right of a single workload offers options to add that workload to a filter, or See Details (as shown in the example above). The following sections outline how to search and filter for some common CVA reporting results.
Assessing the Impact of a Vulnerable Container
- From the Container Vulnerabilities page, click the Containers category at the top of the page.
- Sort either the Risk Score or Severity column in descending order to find the most vulnerable container(s).
- Hover on one of the container entries and click the filter icon ("Add Asset to Applied Filters"). Repeat as necessary.
All report categories will automatically filter to only include the selected containers.
You can now easily discern a vulnerable container's impact on workloads by clicking the Workloads category at the top of the page. This will display only the workloads that are associated with the selected containers.
In addition, the packages view and vulnerabilities view show only the associated packages and vulnerabilities based on the filter configurations selection (i.e., only packages that are part of the selected images and any associated vulnerabilities).
Assessing the Impact of a Specific Vulnerability
- From the Container Vulnerabilities page, click the Vulnerabilities category at the top of the page.
- Using the Search capability, search for a particular CVE ID or package name.
- Hover on one of the vulnerability entries and click the filter icon ("Add Asset to Applied Filters"). Repeat as necessary.
All report categories will automatically filter to only include the selected vulnerabilities.
You can now easily discern a vulnerability's impact on workloads, containers, and packages by clicking the associated category at the top of the page. This will display only the entries that are associated with the selected vulnerabilities.
In addition, the packages view and vulnerabilities view show only the associated packages and vulnerabilities based on the filter configurations selection (i.e., only packages that are part of the selected images and any associated vulnerabilities).
Assessing a Zero-Day Vulnerability
Often when a zero-day vulnerability occurs there is no CVE and the best way to determine surface area is a search by software and version. In these scenarios, you can focus on a specific package (like log4j) and see the impact of that package across the estate.
- From the Container Vulnerabilities page, click the Packages category at the top of the page.
- Using the Search capability, search for a particular CVE ID or package name.
- Hover on one of the vulnerability entries and click the filter icon (Add Asset to Applied Filters).
All report categories will automatically filter to only include the selected vulnerabilities.
The Container report will now update to show all Container images using this package and the Workloads report will show all affected workloads.
CVA & Automation (Bots)
Once InsightCloudSec has collected details and provided analysis you have the ability to build automation around notifications through our Bot capability. In the example Bot below, the configuration is scoped to provide a summary of all workloads with a severity of critical or high from the past 100 days.
json
1{2"resource_id": "divvybot:20:4615",3"name": "Container Vulnerability Assessment Summary Bot",4"description": "",5"notes": null,6"insight_id": null,7"source": null,8"insight_name": null,9"insight_severity": null,10"owner": "divvyuser:1:",11"owner_name": "Rapid7",12"state": "PAUSED",13"date_created": "2022-04-29 14:53:47",14"date_modified": "2022-04-29 14:53:47",15"category": "Security",16"badge_scope_operator": null,17"instructions": {18"resource_types": [19"ecstaskdefinition"20],21"filters": [22{23"name": "divvy.query.workload_severity_higher_than",24"config": {25"severities": [26"HIGH",27"CRITICAL"28],29"days": 10030}31}32],33"actions": [34{35"name": "divvy.action.mark_non_compliant",36"config": {},37"run_when_result_is": true38},39{40"name": "divvy.action.log_message",41"config": {42"message_text": "vulnerability"43},44"run_when_result_is": true45}46],47"groups": [],48"badges": [],49"hookpoints": [],50"schedule": null,51"schedule_description": null52},53"valid": true,54"errors": [],55"severity": "low",56"detailed_logging": false,57"scope": []58}
Creating a CVA Bot From a Template
To use the template example above
- From your InsightCloudSec platform installation, go to Automation > BotFactory.
- On the BotFactory landing page, go to Templates.
- From the Templates tab under BotFactory select the Import Template option and paste the example featured above into the JSON window.
- Click Submit to verify and store the template for future use. Review Creating Bots for more information on next steps.