Containers help developers create, test, and deploy applications in a consistent environment. Container images include standalone or executable files encompassing files, libraries, and dependencies needed to run a container. They include many open-source software, making them vulnerable to open-source risks.
Gaining visibility into container images is essential to identify and prioritize risks or maintain compliance obligations.
Endor Labs container scan detects and reports known vulnerabilities and other risks in:
- Operating system packages: Identifies packages installed through the container’s base operating system package manager.
- Programming language packages: Identifies packages installed through language-specific package managers.
- Libraries and dependencies: Identifies static and dynamic libraries, and runtime dependencies required by the application.
Additionally, it generates an SBOM (Software Bill of Materials) that details all components, their versions, and associated metadata, providing a complete inventory of the container’s contents.
Important
Upgrade to endorctl version 1.6.734 or higher to ensure accurate container scan results. Container scans performed with older endorctl versions may yield different or no results in some cases.Verify access to container registries
If the container image is in a private Docker registry, you must authenticate the container client before the scan.
Here are a few commands to authenticate the container client.
docker login <host> -u <user_name> -p <password>
For more information, see [Docker documentation](https://docs.docker.com/reference/cli/docker/login/).
podman login -u myusername -p mypassword myregistry.example.com
For more information, see [Scanning podman built container images](../../troubleshooting/podman/) and [Podman documentation](https://docs.podman.io/en/v4.4/markdown/podman-login.1.html).
You must configure the containerd config file to authenticate with the container registry. For more information, see the [containerd documentation](https://github.com/containerd/containerd/blob/main/docs/cri/registry.md).
Perform the endorctl scan
Use the following options to scan containers using endorctl CLI.
- To scan a container image from the registry, run the following command specifying the project’s name in the
–project-name
argument, and the container image name and tag in the–container
argument.
endorctl scan --project-name=<endor_project_name> --container=<image_name:tag>
- To scan a container image in a particular path, run the following command specifying the project’s path in the
–path
argument and the container image name in the–container
argument. This will associate the container with the Git repository and branch of the project.
endorctl scan --path=users/janedoe/endorlabs/npm/exampleproject --container=<image_name:tag>
- To keep multiple versions of a container image in a project, use
–container-as-ref
endorctl scan --path=users/janedoe/enodorlabs/npm/exampleproject --container=<image_name:tag> --container-as-ref
Important
To associate a container scan with an existing SCA scan for a project, you must use the--path
argument specifying the same project path used for the SCA scan. You cannot associate a container scan with an SCA scan for a project using the --project-name
parameter.
Perform container scan in CI pipelines
You can integrate container scanning into CI pipelines to automatically detect vulnerabilities and ensure the security of container images during the build and deployment process.
To perform container scanning in CI pipelines using GitHub Actions include the following command in the GitHub Actions script. You must also set the scan_container
parameter to true
.
endorctl scan --project-name=<endor_project_name> --container=<image_name:tag>
or
endorctl scan --path=users/janedoe/endorlabs/npm/exampleproject --container=<image_name:tag>
See Performing scans in CI/CD pipelines for more information.
Understand container scan
Endor Labs fetches the container image from a container registry or loads it from a local file to scan containers. It then proceeds to extract the layers of the container image. It traverses the filesystem of each layer to identify files and directories. It looks for known package manager and metadata files to gather information about installed packages and their versions. It identifies various components and dependencies within the image and presents the findings in CLI and the Endor Labs user interface.
Discover base images of containers
A container image is often built upon a base image that is a foundational layer including an operating system and other essential components. It’s crucial to understand what’s in the base image for a thorough security assessment.
You can distinguish the base image related vulnerabilities from the application layer using any of the following methods:
- Scan Sequence - First, scan the base image. Then, scan any subsequent images built on that base image to distinguish vulnerabilities specific to the base image from those introduced by the other layers.
- Docker file label - Set the label directly in your Dockerfile with a command such as
LABEL org.opencontainers.image.base.name="openjdk:17-slim"
. - Build time label - Include the base image label during the build process with the
--label
flag, specifying both the base image and, optionally, its exact version via SHA256 hash. For example:
docker build -t tictactoe:latest --label "org.opencontainers.image.base.name=openjdk@sha256:eddacbc7e24bf8799a4ed3cdcfa50d4b88a323695ad80f317b6629883b2c2a78" .
Important
Endor Labs’ container scanning results rely on OVAL feeds from distributions, which provide accurate, vetted vulnerability data, excluding disputed or irrelevant entries. OS dependency results are based on data from distribution developers, while for language package dependencies, we complement published data with our proprietary research.Create finding policies for containers
Container base images from untrusted sources may lack proper security audits or fail to comply with organizational standards, increasing the risk of vulnerabilities being exploited. To address this, you can configure a finding policy to detect unauthorised base images and raise a critical finding.
For example, to allow only base images that start with gcp
or ghcr
, use the Container policy template and Specify Base Image Name Regex as ^gcp
, ^ghcr
.
See also Create a finding policy from template.
Supported languages and package managers
The dependencies associated with the following list of components are identified in the endorctl scan:
OS/Language | Package Manager/Packaging |
---|---|
Alpine | apk |
Debian | dpkg |
Ubuntu | dpkg |
RedHat | RPM |
Fedora | RPM |
Amazon Linux | RPM |
Oracle Linux | RPM |
.NET | deps.json |
Objective-C | CocoaPods |
Go | go.mod, Go binaries |
Java | jar, ear, war, native-image, pom.xml |
JavaScript | npm, Yarn |
PHP | Composer |
Python | wheel, egg, Poetry, requirements.txt |
Ruby | gem |
Rust | Cargo |
Swift | CocoaPods |
View findings
To view findings from the scan,
- Select Projects from the left sidebar.
- Locate your project and select to view its findings.
4. To view and filter dependencies based on the container images, click Container Layers and select to view All Layers, Base Image Layers, or Application Layers only.
Limitations
- Scanning Windows containers is not supported.
- Docker file scans are not currently supported.
- Container registry direct integrations are not currently supported.
- Scanning binary files inside a container is not currently supported.
- Scanning container images packaged in the tarball format is not currently supported.
- Endor scores are not calculated for findings reported in the container scan.