{"id":28085981,"url":"https://github.com/noqcks/xeol","last_synced_at":"2025-05-13T11:02:00.066Z","repository":{"id":65146409,"uuid":"581609881","full_name":"xeol-io/xeol","owner":"xeol-io","description":"A scanner for end-of-life (EOL) software and dependencies in container images, filesystems, and SBOMs","archived":false,"fork":false,"pushed_at":"2025-05-01T06:35:13.000Z","size":29561,"stargazers_count":391,"open_issues_count":30,"forks_count":24,"subscribers_count":6,"default_branch":"main","last_synced_at":"2025-05-07T00:05:52.191Z","etag":null,"topics":["compliance","end-of-life","eol","fedramp","nist","outdated-dep","outdated-libraries","outdated-packages","pci-dss","release-policy","sbom","security"],"latest_commit_sha":null,"homepage":"https://www.xeol.io/","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/xeol-io.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2022-12-23T17:52:15.000Z","updated_at":"2025-04-27T16:35:33.000Z","dependencies_parsed_at":"2023-09-27T13:33:14.950Z","dependency_job_id":"89b3ad1e-a87c-4194-82fb-aabd8ce588a3","html_url":"https://github.com/xeol-io/xeol","commit_stats":{"total_commits":219,"total_committers":9,"mean_commits":"24.333333333333332","dds":0.4155251141552512,"last_synced_commit":"b24935d8b2d3d4c86ad16b803fe30ffd297e45b2"},"previous_names":["noqcks/xeol"],"tags_count":59,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xeol-io%2Fxeol","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xeol-io%2Fxeol/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xeol-io%2Fxeol/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xeol-io%2Fxeol/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/xeol-io","download_url":"https://codeload.github.com/xeol-io/xeol/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253929358,"owners_count":21985802,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["compliance","end-of-life","eol","fedramp","nist","outdated-dep","outdated-libraries","outdated-packages","pci-dss","release-policy","sbom","security"],"created_at":"2025-05-13T11:01:05.955Z","updated_at":"2025-05-13T11:02:00.004Z","avatar_url":"https://github.com/xeol-io.png","language":"Go","readme":"\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"https://s3.amazonaws.com/static.xeol.io/xeol-logo/logo-white-bg.png\" width=\"80px\" /\u003e\n  \u003ch1 align=\"center\"\u003eXeol\u003c/h1\u003e\n\n  \u003ch4 align=\"center\"\u003e\n    🔎  A scanner for end-of-life (EOL) packages in container images, filesystems, and SBOMs  🔍\n  \u003c/h4\u003e\n\n\u003ca href=\"https://img.shields.io/github/downloads/xeol-io/xeol/total.svg\"\u003e\u003cimg src=\"https://img.shields.io/github/downloads/xeol-io/xeol/total.svg\" alt=\"Github All Releases\"/\u003e\u003c/a\u003e\n\u003ca href=\"https://goreportcard.com/report/github.com/xeol-io/xeol\"\u003e\u003cimg src=\"https://goreportcard.com/badge/github.com/xeol-io/xeol\" alt=\"Go Report Card\"/\u003e\u003c/a\u003e\n\u003ca href=\"https://api.securityscorecards.dev/projects/github.com/xeol-io/xeol\"\u003e\u003cimg src=\"https://api.securityscorecards.dev/projects/github.com/xeol-io/xeol/badge\" alt=\"OpenSSF Scorecard\"/\u003e\u003c/a\u003e\n\u003ca href=\"https://github.com/xeol-io/xeol/releases/latest\"\u003e\u003cimg src=\"https://img.shields.io/github/release/xeol-io/xeol.svg\" alt=\"GitHub release\"/\u003e\u003c/a\u003e\n\u003ca href=\"https://github.com/xeol-io/xeol/blob/main/LICENSE\"\u003e\u003cimg src=\"https://img.shields.io/badge/License-Apache%202.0-blue.svg\" alt=\"License: Apache-2.0\"/\u003e\u003c/a\u003e\n\u003ca href=\"https://slsa.dev/images/gh-badge-level3.svg\"\u003e\u003cimg src=\"https://slsa.dev/images/gh-badge-level3.svg\" alt=\"SLSA\"/\u003e\u003c/a\u003e\n\n  \u003ch4 align=\"center\"\u003e\n    \u003ca href=\"https://www.xeol.io/end-of-life\"\u003e🌐 Website\u003c/a\u003e\n    \u003cspan\u003e  |  \u003c/span\u003e\n    \u003ca href=\"https://docs.xeol.io/home/home\"\u003e📑 Docs\u003c/a\u003e\n    \u003cspan\u003e  |  \u003c/span\u003e\n    \u003ca href=\"https://www.xeol.io/blog\"\u003e✍🏻 Blog\u003c/a\u003e\n  \u003c/h4\u003e\n\n  \u003cimg src=\"https://user-images.githubusercontent.com/4740147/216162986-2c3add2b-af9f-4d9d-97eb-4c1617da3a71.gif\" width=\"800px\" /\u003e\n\u003c/div\u003e\n\n## Installation\n\n### Recommended\n\n```bash\ncurl -sSfL https://raw.githubusercontent.com/xeol-io/xeol/main/install.sh | sh -s -- -b /usr/local/bin\n```\n\nCheck installation or check version of xeol\n\n```\nxeol version\n```\n\nYou 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.\n\n```\ncurl -sSfL https://raw.githubusercontent.com/xeol-io/xeol/main/install.sh | sh -s -- -b \u003cDESTINATION_DIR\u003e \u003cRELEASE_VERSION\u003e\n```\n\n### Homebrew\n\n```bash\nbrew tap xeol-io/xeol\nbrew install xeol\n```\n\n### GitHub Actions\n\nIf you're using GitHub Actions, you can simply use the [Xeol GitHub action](https://github.com/marketplace/actions/xeol-end-of-life-eol-scan) to run EOL scans on your code or container images during your CI workflows.\n\n### Verifying SLSA provenance for downloaded releases\n\nWe generate SLSA provenance for all Xeol releases starting with v0.9.5. You can verify the provenance for the release binaries like so:\n\n1. Install the [slsa-framework/slsa-verifier#installation](https://github.com/slsa-framework/slsa-verifier#installation) tool\n2. Download the signature file `multiple.intoto.jsonl` from a Xeol release\n3. Download the Xeol release binary you want to verify\n4. Run `slsa-verifier verify-artifact --provenance-path multiple.intoto.jsonl \u003crelease-binary\u003e --source-uri=github.com/xeol-io/xeol`\n\nYou should see something like this is the release binary is verified:\n\n```\n➜  ~ slsa-verifier verify-artifact --provenance-path multiple.intoto.jsonl xeol_0.9.5_darwin_amd64.tar.gz --source-uri=github.com/xeol-io/xeol\nVerified signature against tlog entry index 44906341 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77a658e74e86e03e7aedcca39eebddebf59310b4d9c463b037951109186d73a5681\nVerified 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\nVerifying artifact xeol_0.9.5_darwin_amd64.tar.gz: PASSED\n\nPASSED: Verified SLSA provenance\n```\n\n## Getting started\n\n[Install the binary](#installation), and make sure that `xeol` is available in your path. To scan for EOL packages in an image:\n\n```\nxeol \u003cimage\u003e\n```\n\nThe 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`:\n\n```\nxeol \u003cimage\u003e --scope all-layers\n```\n\nTo run xeol from a Docker container so it can scan a running container, use the following command:\n\n```sh\ndocker run --rm \\\n--volume /var/run/docker.sock:/var/run/docker.sock \\\n--name xeol noqcks/xeol:latest \\\n$(ImageName):$(ImageTag)\n```\n\n### Supported sources\n\nxeol can scan a variety of sources beyond those found in Docker.\n\n```sh\n# scan a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands)\nxeol path/to/image.tar\n\n# scan a Singularity Image Format (SIF) container\nxeol path/to/image.sif\n\n# scan a directory\nxeol dir:path/to/dir\n```\n\nSources can be explicitly provided with a scheme:\n\n```\npodman:yourrepo/yourimage:tag          use images from the Podman daemon\ndocker:yourrepo/yourimage:tag          use images from the Docker daemon\ndocker-archive:path/to/yourimage.tar   use a tarball from disk for archives created from \"docker save\"\noci-archive:path/to/yourimage.tar      use a tarball from disk for OCI archives (from Skopeo or otherwise)\noci-dir:path/to/yourimage              read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)\nsingularity:path/to/yourimage.sif      read directly from a Singularity Image Format (SIF) container on disk\ndir:path/to/yourproject                read directly from a path on disk (any directory)\nsbom:path/to/syft.json                 read Syft JSON from path on disk\nregistry:yourrepo/yourimage:tag        pull image directly from a registry (no container runtime required)\natt:attestation.json --key cosign.pub  explicitly use the input as an attestation\n```\n\nUse SBOMs for even faster EOL scanning in xeol:\n\n```sh\n# Then scan for new EOL packages as frequently as needed\nxeol sbom:./sbom.json\n\n# (You can also pipe the SBOM into xeol)\ncat ./sbom.json | xeol\n```\n\nxeol supports input of [Syft](https://github.com/xeol-io/xeol), [SPDX](https://spdx.dev/), and [CycloneDX](https://cyclonedx.org/)\nSBOM formats. If Syft has generated any of these file types, they should have the appropriate information to work properly with xeol.\n\n### Lookahead\n\nBy 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 \u003cduration\u003e`. where `\u003cduration\u003e` is like `1w`, `30d` or `1y`.\n\n### Gating on EOL packages found\n\nYou 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.\n\n```sh\nxeol \u003cimage\u003e --fail-on-eol-found\n```\n\n## What is EOL software?\n\nEnd of Life (EOL) means the vendor has decided the software in question has reached the end of its\n“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.\n\nxeol does not currently support extended support dates and only matches standard EOL support dates from vendors.\n\n## xeol's database\n\nWhen 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:\n\n- Aggregators: endoflife.date\n- Package registries: cargo, maven, npm, nuget, pypi, rubygems\n- Vendor packages: Adobe, Broadcom, IBM, Ivanti, Microsoft, Oracle, UIPath, Wireshark\n- Browsers: Chrome, Edge\n\nxeol's database is not a comprehensive list of all EOL packages. It is a curated list of commonly used software.\n\nBy 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.\n\n### How database updates work\n\nxeol'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.\n\nxeol'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:\n\n`https://data.xeol.io/xeol/databases/listing.json`\n\nThe listing file contains entries for every database that's available for download.\n\nHere's an example of an entry in the listing file:\n\n```json\n{\n  \"built\": \"2021-10-21T08:13:41Z\",\n  \"version\": 3,\n  \"url\": \"https://data.xeol.io/xeol/databases/eol-db_v3_2021-10-21T08:13:41Z.tar.gz\",\n  \"checksum\": \"sha256:8c99fb4e516f10b304f026267c2a73a474e2df878a59bf688cfb0f094bfe7a91\"\n}\n```\n\nWith 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.\n\n### Managing xeol's database\n\n\u003e **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.\n\n#### Local database cache directory\n\nBy default, the database is cached on the local filesystem in the directory `$XDG_CACHE_HOME/xeol/db/\u003cSCHEMA-VERSION\u003e/`. 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](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html).)\n\nYou can set the cache directory path using the environment variable `XEOL_DB_CACHE_DIR`.\n\n#### Data staleness\n\nxeol needs up-to-date information to provide accurate EOL matches. By default, it will fail execution if the local database was not built in the last 5 days. The data staleness check is configurable via the environment variable `XEOL_DB_MAX_ALLOWED_BUILT_AGE` and `XEOL_DB_VALIDATE_AGE` or the field `max-allowed-built-age` and `validate-age`, under `db`. It uses [golang's time duration syntax](https://pkg.go.dev/time#ParseDuration). Set `XEOL_DB_VALIDATE_AGE` or `validate-age` to `false` to disable staleness check.\n\n#### Offline and air-gapped environments\n\nBy default, xeol checks for a new database on every run, by making a network call over the Internet. You can tell xeol not to perform this check by setting the environment variable `XEOL_DB_AUTO_UPDATE` to `false`.\n\nAs long as you place xeol's `xeol.db` and `metadata.json` files in the cache directory for the expected schema version, xeol has no need to access the network. Additionally, you can get a listing of the database archives available for download from the `xeol db list` command in an online environment, download the database archive, transfer it to your offline environment, and use `xeol db import \u003cdb-archive-path\u003e` to use the given database in an offline capacity.\n\nIf you would like to distribute your own xeol databases internally without needing to use `db import` manually you can leverage xeol's DB update mechanism. To do this you can craft your own `listing.json` file similar to the one found publically (see `xeol db list -o raw` for an example of our public `listing.json` file) and change the download URL to point to an internal endpoint (e.g. a private S3 bucket, an internal file server, etc). Any internal installation of xeol can receive database updates automatically by configuring the `db.update-url` (same as the `XEOL_DB_UPDATE_URL` environment variable) to point to the hosted `listing.json` file you've crafted.\n\n#### CLI commands for database management\n\nxeol provides database-specific CLI commands for users that want to control the database from the command line. Here are some of the useful commands provided:\n\n`xeol db status` — report the current status of xeol's database (such as its location, build date, and checksum)\n\n`xeol db check` — see if updates are available for the database\n\n`xeol db update` — ensure the latest database has been downloaded to the cache directory (xeol performs this operation at the beginning of every scan by default)\n\n`xeol db list` — download the listing file configured at `db.update-url` and show databases that are available for download\n\n`xeol db import` — provide xeol with a database archive to explicitly use (useful for offline DB updates)\n\nFind complete information on xeol's database commands by running `xeol db --help`.\n\n## Shell completion\n\nxeol supplies shell completion through its CLI implementation ([cobra](https://github.com/spf13/cobra/blob/master/shell_completions.md)). Generate the completion code for your shell by running one of the following commands:\n\n- `xeol completion \u003cbash|zsh|fish\u003e`\n- `go run ./cmd/xeol completion \u003cbash|zsh|fish\u003e`\n\nThis will output a shell script to STDOUT, which can then be used as a completion script for xeol. Running one of the above commands with the\n`-h` or `--help` flags will provide instructions on how to do that for your chosen shell.\n\n## Private Registry Authentication\n\n### Local Docker Credentials\n\nWhen a container runtime is not present, xeol can still utilize credentials configured in common credential sources (such as `~/.docker/config.json`).\nIt will pull images from private registries using these credentials. The config file is where your credentials are stored when authenticating with private registries via some command like `docker login`.\nFor more information see the `go-containerregistry` [documentation](https://github.com/google/go-containerregistry/tree/main/pkg/authn).\n\nAn example `config.json` looks something like this:\n\n```json\n// config.json\n{\n  \"auths\": {\n    \"registry.example.com\": {\n      \"username\": \"AzureDiamond\",\n      \"password\": \"hunter2\"\n    }\n  }\n}\n```\n\nYou can run the following command as an example. It details the mount/environment configuration a container needs to access a private registry:\n\n`docker run -v ./config.json:/config/config.json -e \"DOCKER_CONFIG=/config\" noqcks/xeol:latest \u003cprivate_image\u003e`\n\n### Docker Credentials in Kubernetes\n\nThe below section shows a simple workflow on how to mount this config file as a secret into a container on kubernetes.\n\n1.  Create a secret. The value of `config.json` is important. It refers to the specification detailed [here](https://github.com/google/go-containerregistry/tree/main/pkg/authn#the-config-file).\n    Below this section is the `secret.yaml` file that the pod configuration will consume as a volume.\n    The key `config.json` is important. It will end up being the name of the file when mounted into the pod.\n\n    ```yaml\n    # secret.yaml\n    apiVersion: v1\n    kind: Secret\n    metadata:\n      name: registry-config\n      namespace: xeol\n    data:\n      config.json: \u003cbase64 encoded config.json\u003e\n    ```\n\n    `kubectl apply -f secret.yaml`\n\n2.  Create your pod running xeol. The env `DOCKER_CONFIG` is important because it advertises where to look for the credential file.\n    In the below example, setting `DOCKER_CONFIG=/config` informs xeol that credentials can be found at `/config/config.json`.\n    This is why we used `config.json` as the key for our secret. When mounted into containers the secrets' key is used as the filename.\n    The `volumeMounts` section mounts our secret to `/config`. The `volumes` section names our volume and leverages the secret we created in step one.\n\n    ```yaml\n    # pod.yaml\n    apiVersion: v1\n    kind: Pod\n    spec:\n      containers:\n        - image: noqcks/xeol:latest\n          name: xeol-private-registry-demo\n          env:\n            - name: DOCKER_CONFIG\n              value: /config\n          volumeMounts:\n            - mountPath: /config\n              name: registry-config\n              readOnly: true\n          args:\n            - \u003cprivate_image\u003e\n      volumes:\n        - name: registry-config\n          secret:\n            secretName: registry-config\n    ```\n\n    `kubectl apply -f pod.yaml`\n\n3.  The user can now run `kubectl logs xeol-private-registry-demo`. The logs should show the xeol analysis for the `\u003cprivate_image\u003e` provided in the pod configuration.\n\nUsing the above information, users should be able to configure private registry access without having to do so in the `xeol` or `syft` configuration files.\nThey will also not be dependent on a docker daemon, (or some other runtime software) for registry configuration and access.\n\n## Configuration\n\nConfiguration search paths:\n\n- `.xeol.yaml`\n- `.xeol/config.yaml`\n- `~/.xeol.yaml`\n- `\u003cXDG_CONFIG_HOME\u003e/xeol/config.yaml`\n\n## Pronunciation\n\nXeol is pronounced \"zee-oh-el\", like EOL but with a Z in front :-)\n\n## Help\n\nJoin our [discord](https://discord.gg/xAePvPpEx5) for help or feedback!\n","funding_links":[],"categories":["Dependency intelligence"],"sub_categories":["Vulnerability information exchange"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnoqcks%2Fxeol","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnoqcks%2Fxeol","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnoqcks%2Fxeol/lists"}