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.

CVA Workflow Example

Terminology

TermDescription
Container RegistryA container registry is a service that stores and distributes container images and related artifacts.
Container RepositoryA 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 NamespaceRepository 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/ArtifactA 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.
TagThe 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.
ManifestEach 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 digestManifests 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 PlatformA service allowing to define and run workloads that are based on container images.
Workload DefinitionRefers 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 InstanceThe running entity of a workload. For example, in Kubernetes the Pod is a workload instance of the Workload Set.
Deployed ImagesDeployed 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

CategoryWhat 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 LanguagesDependency 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
1
ecr:Get*
2
ecr:List*
3
ecr:Describe*
4
ecr: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
1
resourcemanager.projects.get
2
resourcemanager.projects.list
3
storage.objects.get
4
storage.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.

  1. Navigate to Cloud > Clouds and on the listing tab, browse to the name of the cloud account you want to review.
  2. Scroll to the right to view additional columns and locate the column titled Visibility.
  3. 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:

  1. Workload definitions are being harvested using the default InsightCloudSec harvesting capabilities
  2. Container images included in each workload definition are being identified
  3. Container images are being pulled out of the related container image registry and are analyzed creating the container image metadata
  4. InsightCloudSec continuously resolves/update container images to ensure we have the latest and greatest image pointed by the workload configuration.
  5. 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.
  6. 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

ColumnDescription
Risk ScoreRisk score is the max risk score from all vulnerabilities associated with the workload.
WorkloadName of the workload
CloudCloud Service Provider for the workload
Cloud AccountCloud Account for the workload
ClusterCluster for the workload
Container ServiceContainer service for the workload
Last AssessmentDate and time of last assessment for the workload
SeveritySeverity is the max severity from all vulnerabilities associated with the workload (None, Low, Medium, High, Critical)

Containers

ColumnDescription
Risk ScoreRisk score for the container vulnerability.
Container NameThe name of the container
ImageThe full name of the image used by the container (includes the tag)
TagThe tag for the image used by the container
Last AssessmentDate and time of last assessment for the container
SeveritySeverity assigned to the container vulnerability (None, Low, Medium, High, Critical)

Packages

ColumnDescription
Risk ScoreRisk score for the package vulnerability.
Package NameThe name of the package
VersionThe package version
SeveritySeverity assigned to the package vulnerability (None, Low, Medium, High, Critical)

Vulnerabilities

ColumnDescription
Risk ScoreRisk score for the associated Common Vulnerabilities and Exposures (CVE) database entry.
CVE TitleThe title for the CVE.
CVSS SeverityThe Common Vulnerability Scoring System (CVSS) severity assigned to the vulnerability (None, Low, Medium, High, Critical)
Package NameThe name of the package associated with the vulnerability
VersionThe version of the package associated with the vulnerability
First FoundDate 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

  1. From the Container Vulnerabilities page, click the Containers category at the top of the page.
  2. Sort either the Risk Score or Severity column in descending order to find the most vulnerable container(s).
  3. 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

  1. From the Container Vulnerabilities page, click the Vulnerabilities category at the top of the page.
  2. Using the Search capability, search for a particular CVE ID or package name.
  3. 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.

  1. From the Container Vulnerabilities page, click the Packages category at the top of the page.
  2. Using the Search capability, search for a particular CVE ID or package name.
  3. 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": 100
30
}
31
}
32
],
33
"actions": [
34
{
35
"name": "divvy.action.mark_non_compliant",
36
"config": {},
37
"run_when_result_is": true
38
},
39
{
40
"name": "divvy.action.log_message",
41
"config": {
42
"message_text": "vulnerability"
43
},
44
"run_when_result_is": true
45
}
46
],
47
"groups": [],
48
"badges": [],
49
"hookpoints": [],
50
"schedule": null,
51
"schedule_description": null
52
},
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

  1. From your InsightCloudSec platform installation, go to Automation > BotFactory.
  2. On the BotFactory landing page, go to Templates.
  3. From the Templates tab under BotFactory select the Import Template option and paste the example featured above into the JSON window.
  4. Click Submit to verify and store the template for future use. Review Creating Bots for more information on next steps.