Container Image Vulnerability Assessment

Feature Overview

What is Container Image Vulnerability Assessment?

The container image vulnerability assessment (CVA) service is designed to continuously analyze production environment container image software vulnerability. Container images are harvested from the customer cloud configuration. Each image is analyzed for vulnerabilities utilizing IVM and Snyk vulnerability databases. Vulnerability findings are presented in the ICS platform allowing users to zoom in on riskiest assets by focusing on business segments such as deployed workload and applications.

720720

Container Vulnerability Workflow

CVA analyzes the configured Workload (Workload Definition). That is the configuration of the workload used while instantiating a new workload instance.

11521152

Workload Definition

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
  • App Runner - AWS
  • Cloud Run - GCP

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 you will need to have the following:

  • A functioning InsightCloudSec Platform installation
    • Note at this time CVA is only available for SaaS/hosted InsightCloudSec customers. If you are interested in being a SaaS customer reach out to us through Getting Support for details.
  • InsightCloud Sec 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 scanner - i.e., 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/ installed on the cluster.

Permissions

AWS Role Permissions

The role that will be associated with the InsightCloudSec Container Image Vulnerability Assessment feature will need the following AWS permissions:

ecr:Get*
ecr:List*
ecr:Describe*

Azure Role Permissions

The role that will be associated with the InsightCloudSec Container Image Vulnerability Assessment 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 Container Image Vulnerability Assessment will need the same permissions as the Storage Object Viewer role (roles/storage.objectViewer). Additional details on GCP IAM Roles

resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
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".

14501450

Viewing Permission(s) for Cloud Accounts

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.
15921592

Container Vulnerability Assessment - Missing Permissions Example

Feature Architecture

The Container Image Vulnerability 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 make sure we have the latest and greatest image pointed by the workload configuration
  • Container image metadata is processed using Rapid7's InsightVM services and the related 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 CVA

Container Vulnerability assessment is available from the main navigation in InsightCloudSec under "Security --> Vulnerability Assessment".

28742874

Vulnerabilities Assessment Landing Page

Viewing Vulnerability Findings

Vulnerability findings display on the Vulnerabilities Assessment 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 (e.g. 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

  • Risk Score: Risk score is the max risk score from all vulnerabilities associated with the workload. This score derived from IVM, is calculated in a range from 0-1000, based on an aggregation of risk.
  • 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

  • Risk Score: Risk score for the container vulnerability. This score derived from IVM, is calculated in a range from 0-1000, based on an aggregation of risk.
  • 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

  • Risk Score: Risk score for the package vulnerability. This score derived from IVM, is calculated in a range from 0-1000, based on an aggregation of risk.
  • Package Name: The name of the package
  • Version: The package version
  • Severity: Severity assigned to the package vulnerability (None, Low, Medium, High, Critical)

Vulnerabilities

  • Risk Score: Risk score for the associated Common Vulnerabilities and Exposures (CVE) database entry. This score derived from IVM, is calculated in a range from 0-1000, based on an aggregation of risk.
  • 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
24442444

Workloads - Additional Actions

Exploring Your CVA Report

The Vulnerabilities Assessment 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 Vulnerability Assessment 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 Vulnerability Assessment 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 Vulnerability Assessment 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 assessments 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.

{
 "resource_id": "divvybot:20:4615",
 "name": "test CVA",
 "description": "",
 "notes": null,
 "insight_id": null,
 "source": null,
 "insight_name": null,
 "insight_severity": null,
 "owner": "divvyuser:1:",
 "owner_name": "DivvyCloud Dev",
 "state": "PAUSED",
 "date_created": "2022-04-29 14:53:47",
 "date_modified": "2022-04-29 14:53:47",
 "category": "Security",
 "badge_scope_operator": null,
 "instructions": {
  "resource_types": [
   "ecstaskdefinition"
  ],
  "filters": [
   {
    "name": "divvy.query.workload_severity_higher_than",
    "config": {
     "severities": [
      "HIGH",
      "CRITICAL"
     ],
     "days": 100
    }
   }
  ],
  "actions": [
   {
    "name": "divvy.action.mark_non_compliant",
    "config": {},
    "run_when_result_is": true
   },
   {
    "name": "divvy.action.log_message",
    "config": {
     "message_text": "vulnerability"
    },
    "run_when_result_is": true
   }
  ],
  "groups": [],
  "badges": [],
  "hookpoints": [],
  "schedule": null,
  "schedule_description": null
 },
 "valid": true,
 "errors": [],
 "severity": "low",
 "detailed_logging": false,
 "scope": []
}

Creating a Bot From a Template

Bots can be created in one of three ways:

1. To use the templates below from your InsightCloudSec platform installation navigate to "Automation --> BotFactory".

2. To import one of the templates on the BotFactory landing page, navigate to "Templates".

24162416

Importing a Bot template

3. From the "Templates" tab under BotFactory select the "Import Template" option and paste one of the two examples featured above into the JSON window.

24322432

Import JSON template

  1. Click "Submit" to complete the creation of your new Bot.

Did this page help you?