Xeol

<div align="center"> <img src="https://s3.amazonaws.com/static.xeol.io/xeol-logo/logo-white-bg.png" width="80px" /> <h1 align="center">Xeol</h1> <h4 align="center"> 🔎 A scanner for end-of-life (EOL) packages in container images, filesystems, and SBOMs 🔍 </h4>

<a href="https://img.shields.io/github/downloads/xeol-io/xeol/total.svg"><img src="https://img.shields.io/github/downloads/xeol-io/xeol/total.svg" alt="Github All Releases"/></a> <a href="https://goreportcard.com/report/github.com/xeol-io/xeol"><img src="https://goreportcard.com/badge/github.com/xeol-io/xeol" alt="Go Report Card"/></a> <a href="https://api.securityscorecards.dev/projects/github.com/xeol-io/xeol"><img src="https://api.securityscorecards.dev/projects/github.com/xeol-io/xeol/badge" alt="OpenSSF Scorecard"/></a> <a href="https://github.com/xeol-io/xeol/releases/latest"><img src="https://img.shields.io/github/release/xeol-io/xeol.svg" alt="GitHub release"/></a> <a href="https://github.com/xeol-io/xeol/blob/main/LICENSE"><img src="https://img.shields.io/badge/License-Apache%202.0-blue.svg" alt="License: Apache-2.0"/></a> <a href="https://slsa.dev/images/gh-badge-level3.svg"><img src="https://slsa.dev/images/gh-badge-level3.svg" alt="SLSA"/></a>

<h4 align="center"> <a href="https://www.xeol.io/end-of-life">🌐 Website</a> <span> | </span> <a href="https://docs.xeol.io/home/home">📑 Docs</a> <span> | </span> <a href="https://www.xeol.io/blog">✍🏻 Blog</a> </h4> <img src="https://user-images.githubusercontent.com/4740147/216162986-2c3add2b-af9f-4d9d-97eb-4c1617da3a71.gif" width="800px" /> </div>

Installation

Recommended

curl -sSfL https://raw.githubusercontent.com/xeol-io/xeol/main/install.sh | sh -s -- -b /usr/local/bin

Check installation or check version of xeol

xeol version

You can also choose another destination directory and release version for the installation. The destination directory doesn't need to be /usr/local/bin, it just needs to be a location found in the user's PATH and writable by the user that's installing xeol.

curl -sSfL https://raw.githubusercontent.com/xeol-io/xeol/main/install.sh | sh -s -- -b <DESTINATION_DIR> <RELEASE_VERSION>

Homebrew

brew tap xeol-io/xeol
brew install xeol

GitHub Actions

If you're using GitHub Actions, you can simply use the Xeol GitHub action to run EOL scans on your code or container images during your CI workflows.

Verifying SLSA provenance for downloaded releases

We generate SLSA provenance for all Xeol releases starting with v0.9.5. You can verify the provenance for the release binaries like so:

1. Install the slsa-framework/slsa-verifier#installation tool
2. Download the signature file multiple.intoto.jsonl from a Xeol release
3. Download the Xeol release binary you want to verify
4. Run slsa-verifier verify-artifact --provenance-path multiple.intoto.jsonl <release-binary> --source-uri=github.com/xeol-io/xeol

You should see something like this is the release binary is verified:

➜  ~ slsa-verifier verify-artifact --provenance-path multiple.intoto.jsonl xeol_0.9.5_darwin_amd64.tar.gz --source-uri=github.com/xeol-io/xeol
Verified signature against tlog entry index 44906341 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77a658e74e86e03e7aedcca39eebddebf59310b4d9c463b037951109186d73a5681
Verified build using builder "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0" at commit fdc6f5efca3f7277aacf25ef42f502355398f512
Verifying artifact xeol_0.9.5_darwin_amd64.tar.gz: PASSED

PASSED: Verified SLSA provenance

Getting started

Install the binary, and make sure that xeol is available in your path. To scan for EOL packages in an image:

xeol <image>

The above command scans for EOL packages that are visible in the container (i.e., the squashed representation of the image). To include software from all image layers in the scan, regardless of its presence in the final image, provide --scope all-layers:

xeol <image> --scope all-layers

To run xeol from a Docker container so it can scan a running container, use the following command:

docker run --rm \
--volume /var/run/docker.sock:/var/run/docker.sock \
--name xeol noqcks/xeol:latest \
$(ImageName):$(ImageTag)

Supported sources

xeol can scan a variety of sources beyond those found in Docker.

# scan a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands)
xeol path/to/image.tar

# scan a Singularity Image Format (SIF) container
xeol path/to/image.sif

# scan a directory
xeol dir:path/to/dir

Sources can be explicitly provided with a scheme:

podman:yourrepo/yourimage:tag          use images from the Podman daemon
docker:yourrepo/yourimage:tag          use images from the Docker daemon
docker-archive:path/to/yourimage.tar   use a tarball from disk for archives created from "docker save"
oci-archive:path/to/yourimage.tar      use a tarball from disk for OCI archives (from Skopeo or otherwise)
oci-dir:path/to/yourimage              read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
singularity:path/to/yourimage.sif      read directly from a Singularity Image Format (SIF) container on disk
dir:path/to/yourproject                read directly from a path on disk (any directory)
sbom:path/to/syft.json                 read Syft JSON from path on disk
registry:yourrepo/yourimage:tag        pull image directly from a registry (no container runtime required)
att:attestation.json --key cosign.pub  explicitly use the input as an attestation

Use SBOMs for even faster EOL scanning in xeol:

# Then scan for new EOL packages as frequently as needed
xeol sbom:./sbom.json

# (You can also pipe the SBOM into xeol)
cat ./sbom.json | xeol

xeol supports input of Syft, SPDX, and CycloneDX SBOM formats. If Syft has generated any of these file types, they should have the appropriate information to work properly with xeol.

Lookahead

By default, xeol will match any package that has an EOL date that is less than the current date + 30d. In order to set a custom lookahead matching time, you can use --lookahead <duration>. where <duration> is like 1w, 30d or 1y.

Gating on EOL packages found

You can have xeol exit with an error if it finds any EOL packages. This is useful for CI/CD pipelines. To do this, use the --fail-on-eol-found CLI flag.

xeol <image> --fail-on-eol-found

What is EOL software?

End of Life (EOL) means the vendor has decided the software in question has reached the end of its “useful lifespan.” After this particular date, the manufacturer no longer markets, sells, provides technical support, sustains, enhances, or fixes the product. Note that End of Life (EOL) and End of Support (EOS) are being treated as the same by xeol, even though various vendors may use these terms differently. EOL Software is a security risk because it is no longer being maintained and receiving security updates.

xeol does not currently support extended support dates and only matches standard EOL support dates from vendors.

xeol's database

When xeol performs a scan for EOL packages, it does so using a database that's stored on your local filesystem, which is constructed by pulling data from several sources:

• Aggregators: endoflife.date
• Package registries: cargo, maven, npm, nuget, pypi, rubygems
• Vendor packages: Adobe, Broadcom, IBM, Ivanti, Microsoft, Oracle, UIPath, Wireshark
• Browsers: Chrome, Edge

xeol's database is not a comprehensive list of all EOL packages. It is a curated list of commonly used software.

By default, xeol automatically manages this database for you. xeol checks for new updates to the database to make sure that every scan uses up-to-date EOL information. This behavior is configurable. For more information, see the Managing xeeol's database section.

How database updates work

xeol's eol database is a SQLite file, named xeol.db. Updates to the database are atomic: the entire database is replaced and then treated as "readonly" by xeol.

xeol's first step in a database update is discovering databases that are available for retrieval. xeol does this by requesting a "listing file" from a public endpoint:

https://data.xeol.io/xeol/databases/listing.json

The listing file contains entries for every database that's available for download.

Here's an example of an entry in the listing file:

{
  "built": "2021-10-21T08:13:41Z",
  "version": 3,
  "url": "https://data.xeol.io/xeol/databases/eol-db_v3_2021-10-21T08:13:41Z.tar.gz",
  "checksum": "sha256:8c99fb4e516f10b304f026267c2a73a474e2df878a59bf688cfb0f094bfe7a91"
}

With this information, xeol can select the correct database (the most recently built database with the current schema version), download the database, and verify the database's integrity using the listed checksum value.

Managing xeol's database

Note: During normal usage, there is no need for users to manage xeol's database! xeol manages its database behind the scenes. However, for users that need more control, xeol provides options to manage the database more explicitly.

Local database cache directory

By default, the database is cached on the local filesystem in the directory $XDG_CACHE_HOME/xeol/db/<SCHEMA-VERSION>/. For example, on macOS, the database would be stored in ~/Library/Caches/xeol/db/3/. (For more information on XDG paths, refer to the XDG Base Directory Specification.)