xeol-io / xeol Goto Github PK

View Code? Open in Web Editor NEW

334.0 5.0 18.0 28.78 MB

A scanner for end-of-life (EOL) software and dependencies in container images, filesystems, and SBOMs

Home Page: https://www.xeol.io/

License: Apache License 2.0

Go 88.23% Makefile 3.33% Dockerfile 0.57% Java 0.08% JavaScript 0.11% Python 0.98% Shell 6.68% Roff 0.02%

end-of-life security eol release-policy sbom compliance outdated-packages fedramp nist outdated-libraries

xeol's People

Contributors

Stargazers

Watchers

Forkers

adriens dhrumitpatel48 vaikas ashishbijlani cybernetics arcticfly step-security-bot doytsujin fossabot trend-ziv-chang qazbnm456 assaf-orca kidazy mlynchcogent milebdo austinsonger damienfernandes sunnywan59

xeol's Issues

Not finding EOL'ed versions of HAProxy

Related to #266

Database is missing purl identifiers for haproxy.

Test using container image haproxy:2.5.14

purl entry pkg:generic/haproxy fixes the issue when using SBOM from Syft v0.93.0.

ENH: `--no-color` CLI argument option to remove color for better automation/pipeline output

What would you like to be added: --no-color CLI argument option

Why is this needed: Automation/Pipeline/Terminals with no color support display garbage string \033[0m

Additional context:

[bug]Not picking up EOL springboot

What happened:
Tried scanning an older image, 3 years old, for inclusion in our own CICD pipeline, but no EOL was detected.

xeol imagename:rel-v.20220715-1358
da-01
 ✔ EOL DB                          [no update available]
 ✔ Scanned for EOL                 [1 eol matches]
NAME          VERSION  EOL         DAYS EOL  TYPE
Alpine Linux  3.12.3   2022-05-01  523       os

What you expected to happen:
We are using Springboot 2.5.2 for that image, so we believe it should detect it.
Running syft against the image, then, correctly detects the package. Therefore, we believe the problem is on the matching side.
I have not been able to see about xeol.db, so I cannot immediately tell you what the problem is.

Excerpts from the package labeling

syft imagename:rel-v.20220715-1358
da-01
 ✔ Loaded image                    imagename:rel-v.20220715-1358  
 ✔ Parsed image                     sha256:XXXX 
 ✔ Cataloged packages          [84 packages]
NAME                                VERSION      TYPE
java                                11.0.9.1+1   binary
spring-aop                          5.3.8        java-archive
spring-beans                        5.3.8        java-archive
spring-boot                         2.5.2        java-archive
spring-boot-actuator                2.5.2        java-archive
spring-boot-actuator-autoconfigure  2.5.2        java-archive
spring-boot-autoconfigure           2.5.2        java-archive
spring-boot-starter                 2.5.2        java-archive
spring-boot-starter-actuator        2.5.2        java-archive
spring-boot-starter-jdbc            2.5.2        java-archive
spring-boot-starter-json            2.5.2        java-archive
spring-boot-starter-logging         2.5.2        java-archive
spring-boot-starter-tomcat          2.5.2        java-archive
spring-boot-starter-validation      2.5.2        java-archive
spring-boot-starter-web             2.5.2        java-archive
spring-context                      5.3.8        java-archive
spring-core                         5.3.8        java-archive
spring-expression                   5.3.8        java-archive
spring-jcl                          5.3.8        java-archive
spring-jdbc                         5.3.8        java-archive
spring-tx                           5.3.8        java-archive
spring-web                          5.3.8        java-archive
spring-webmvc                       5.3.8        java-archive
tomcat-embed-core                   9.0.48       java-archive
tomcat-embed-el                     9.0.48       java-archive
tomcat-embed-websocket              9.0.48       java-archive

How to reproduce it (as minimally and precisely as possible):
I think I can reproduce it if I use an older version of springboot image

Anything else we need to know?:
We also tried an image containing springboot 2.4.2/2.5.3, but it was not detected, so we believe that the entire springboot is not matche

Environment:

Output of xeol version:

Application:         xeol
Version:             0.9.2
BuildDate:           2023-10-02T17:52:09Z
GitCommit:           902de6945ebea4191988b6d295d2cdc6522b23cc
GitDescription:      v0.9.2
Platform:            linux/amd64
GoVersion:           go1.21.1
Compiler:            gc
Syft Version:        v0.91.0
Supported DB Schema: 1

OS (e.g: cat /etc/os-release or similar):

NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

copying xeol to `/usr/local/bin` would need root privileges

Hello, I noticed that the recommended one liner script gives permission denied error while installing at /usr/local/bin which is expected. I would suggest to add sudo at the beginning (sudo sh -s -- -b /usr/local/bin) to make sure the script has sufficient permission.

Go Module Install/I can't read

What would you like to be added:
Hello again Benji!
So I am wanting to install xeol via go install or go get. I think I am probably just doing something wrong but if not just wanted to see if I could get your input.

I was getting this from go get "github.com/xeol-io/xeol/cmd/[email protected]" Also not sure on my path there if I just want the cli.

github.com/xeol-io/[email protected]/internal/xeolio/source.go:44:28: imageSource.Labels undefined (type source.StereoscopeImageSourceMetadata has no field or method Labels

Why is this needed:
This would be nice to have to install on distroless images such as chainguard, would be happy to add instructions to the readme too.

[Request] Self Hosted Option

What would you like to be added:
Can you please give the option to self host the xeol server.

Why is this needed:
Some people may want or need to self host the server themselves.

Additional context:

Automatically cleanup databases in listing.json

What would you like to be added:

When doing xeol db list, there is a long list of listings returned, it's overwhelming for human eyes. Our listing.json should only contain something like the last 3 months of databases, even though we will keep an archive of all database listings.

Why is this needed:

Bad UX

xeol MVP

👶 Better output (for noobs & newbies) when no "EOL found" 🙏

What would you like to be added:

A better message in case when no EOL found.

Why is this needed:

Hi, it would be useful to setup a nice message when no EOL found as some may intiialy thnk that beacuase ne EOL was found the report coudl not be done... while in fact.. it's a good news. Maybe a 👍 or something more explicit that says to the end user that everything is ok... and optionally (when avilable how may before EOL will occure)

🎫 Related issue

Thanks to your README, I made this PR :

Unhelpful platform command error

What happened:

When you try to run xeol on an image that is not the same as the architecture you issue the xeol command from it throws an error that is not very helpful.

1 error occurred:
	* failed to catalog: could not fetch image "xeolio.azurecr.io/dotnet:v1": unable to use DockerDaemon source: image has unexpected architecture "amd64", which differs from the user specified architecture "arm64"

What you expected to happen:

An error command that explains more about what is wrong and how to fix it. e.g use the --platform command line flag to get the correct architecture.

How to reproduce it (as minimally and precisely as possible):

Issue xeol on an image that doesn't have the architecture you're running.

Shell in Container

What would you like to be added:
I want to use xeol in a gitlab-ci pipeline.
However using an image in gitlab-ci requires it to have a shell (bash or sh). Would you be willing to provide another image that has a shell?

Additional context:

See this issue: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26501
And the documentation: https://docs.gitlab.com/runner/executors/docker.html#configure-images-and-services

The image where your job runs must have a working shell in its operating system PATH. Supported shells are:

    For Linux:
        sh
        bash
        PowerShell Core (pwsh). [Introduced in 13.9](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4021).

[bug] Method doesn't work with binary findings

What happened:

xeol redis:5.0.14 --lookahead 2y
 ✔ EOL DB                  [no update available]
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [100 packages]
 ✔ Scanned image           [1 eol]
NAME   VERSION  EOL         DAYS EOL  METHOD
redis  5.0.14   1970-01-01  19398

What you expected to happen:

Expecting to see binary under METHOD

Environment:

Output of xeol version: 0.2.3
OS (e.g: cat /etc/os-release or similar): OSX

json output not working

What happened:
When running xeol mongo:3.2 -o json, no json is shown. Instead the following error is thrown:
[0002] WARN unable to show catalog image finished event: unable to show eol report: unable to find package in collection: <nil>

What you expected to happen:
json output

How to reproduce it (as minimally and precisely as possible):
Install xeol Version 0.2.6 or newer and run xeol mongo:3.2 -o json

Anything else we need to know?:
With xeol Version 0.2.5 this is still working

Environment:

Output of xeol version:

Application: xeol
Version: 0.2.7
Syft Version: v0.77.0
GitCommit: 1059a82
Platform: linux/amd64
GoVersion: go1.18.10
Compiler: gc

Confusing warning message

What happened:
For OS releases that are not EOL a warning message is displayed.
[0000] WARN failed to match cycle for distro Alpine Linux: <nil>

This leads the user to believe there is a problem.

What you expected to happen:
A debug message distro has been found.
Something like:
[0000] DEBUG matched cycle for distro Alpine Linux:3.17.5

How to reproduce it (as minimally and precisely as possible):
Run a scan on any container image or SBOM derived from one.
This example is using an sbom from the xeol:v0.9.10 container image.

$ xeol sbom:xeol.json
 ✔ EOL DB                          [no update available]  
 ✔ Scanned for EOL                 [0 eol matches]  
[0000]  WARN failed to match cycle for distro Alpine Linux: <nil>
✅ no EOL software has been found

Anything else we need to know?:
A potential solution would be to update the log.Warnf in ByDistroCpe to something like:
log.Debugf("matched cycle for distro %s:%s", distro.Name, version)

By this point in the code the err will always be nil because any potential err has already been handled here.

This update will product the following output

$ xeol -vv sbom:xeol.json 2>&1 | grep -i alpine
[0000] DEBUG matching distro Alpine Linux with version 3.17.5
[0000] DEBUG matched cycle for distro Alpine Linux:3.17.5

Environment:

xeol version: 0.9.10

Not all EOL Packages Being Picked up

What happened:

Hello again!
I have a container and or sbom of a container that has dotnet sdk 3.1 (which is eol) not being picked up by xeol.
ex from sbom

   "name": "dotnet-sdk-3.1",
   "version": "3.1.426-1.el8_7",
   "type": "rpm",
   "foundBy": "rpm-db-cataloger",

I am wondering if there is something not right with the support for rpm packages, the other error I got was

[0000] WARN unknown package metadata type="DotnetPortableExecutableMetadata" for packageID="861efa353f20821b" form-lib=syft

What you expected to happen:
Should identify dotnet 3.1 as EOL

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

Output of xeol version: 0.6.0,
Syft Version: v0.83.1
OS (e.g: cat /etc/os-release or similar): macos

[datasource] Add support for base image deprecation

What would you like to be added:

Motivated by this LinkedIn post by Rory McCune

We should be able to identify and flag deprecated base images. There is work in the oci-spec around annotations to signal deprecation, but it's not yet completed. opencontainers/image-spec#903

An alternative would be of Dockerhub or other registries supported a deprecation flag.

brew install broken

What happened: brew install broken (no version 0.3.4 in github releases)

What you expected to happen: xeol installed by brew

How to reproduce it (as minimally and precisely as possible): brew install xeol

Anything else we need to know?:

Error: xeol: Failed to download resource "xeol"
Failure while executing; `/usr/bin/env /usr/local/Homebrew/Library/Homebrew/shims/shared/curl --disable --cookie /dev/null --globoff --show-error --user-agent Homebrew/4.0.28\ \(Macintosh\;\ Intel\ Mac\ OS\ X\ 13.2.1\)\ curl/7.86.0 --header Accept-Language:\ en --retry 3 --fail --location --silent --head --request GET https://github.com/xeol-io/xeol/releases/download/v0.3.4/xeol_0.3.4_darwin_amd64.tar.gz` exited with 22. Here's the output:
curl: (22) The requested URL returned error: 404
HTTP/2 404
server: GitHub.com
date: Sun, 09 Jul 2023 14:17:42 GMT
content-type: text/plain; charset=utf-8
vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, Accept-Encoding, Accept, X-Requested-With
cache-control: no-cache
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: no-referrer-when-downgrade
content-security-policy: default-src 'none'; base-uri 'self'; connect-src 'self'; form-action 'self'; img-src 'self' data:; script-src 'self'; style-src 'unsafe-inline'
content-length: 9
x-github-request-id: C8A0:29FE:9924018:9BD9BD3:64AAC186

Environment:

Output of xeol version: no
OS (e.g: cat /etc/os-release or similar): macos ventura 13.2.1

Defect Dojo integration

What would you like to be added:
Defect Dojo integration

Why is this needed:
For tracking issues in one place

Package should be filled in JSON output

What happened:

An example match from JSON output. The Package information should be filled and should not be blank.

  {
   "Cycle": {
    "ProductName": "Ubuntu",
    "ReleaseCycle": "16.04",
    "Eol": "2021-04-02",
    "LatestRelease": "",
    "LatestReleaseDate": "2020-08-13",
    "ReleaseDate": "2016-04-21"
   },
   "Package": {
    "ID": "",
    "Name": "",
    "Version": "",
    "Locations": {},
    "Language": "",
    "Licenses": null,
    "Type": "",
    "CPEs": null,
    "PURL": "",
    "Upstreams": null,
    "MetadataType": "",
    "Metadata": null
   },
   "artifact": {
    "name": "Ubuntu",
    "version": "16.04",
    "type": "os",
    "locations": [],
    "language": "",
    "licenses": [],
    "cpes": [],
    "purl": "",
    "upstreams": []
   }
  }
 ],

What you expected to happen:

The Package information should be filled and should not be blank.

How to reproduce it (as minimally and precisely as possible):

xeol <image> -o json on any image

Can't verify SLSA provenance with `--source-tag`

Without --source-tag, slsa-verifier works well.

$ slsa-verifier verify-artifact --provenance-path multiple.intoto.jsonl xeol_0.9.5_darwin_arm64.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_arm64.tar.gz: PASSED

PASSED: Verified SLSA provenance

But with --source-tag, slsa-verifier doesn't work well.

$ slsa-verifier verify-artifact --provenance-path multiple.intoto.jsonl xeol_0.9.5_darwin_arm64.tar.gz --source-uri=github.com/xeol-io/xeol --source-tag v0.9.5
Verified signature against tlog entry index 44906341 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77a658e74e86e03e7aedcca39eebddebf59310b4d9c463b037951109186d73a5681
Verifying artifact xeol_0.9.5_darwin_arm64.tar.gz: FAILED: expected tag 'refs/tags/v0.9.5', got '': tag used to generate the binary does not match provenance

FAILED: SLSA verification failed: expected tag 'refs/tags/v0.9.5', got '': tag used to generate the binary does not match provenance

Ideally, we should verify the version too.

I guess this is because the release workflow is triggered by not GitHub tag's push event but workflow_dispatch event.

xeol/.github/workflows/release.yaml

Lines 3 to 8 in fe937f5

 on: 

 workflow_dispatch: 

 inputs: 

 version: 

 description: tag the latest commit on main with the given version (prefixed with v) 

 required: true

$ slsa-verifier version
  ____    _       ____       _             __     __  _____   ____    ___   _____   ___   _____   ____
 / ___|  | |     / ___|     / \            \ \   / / | ____| |  _ \  |_ _| |  ___| |_ _| | ____| |  _ \
 \___ \  | |     \___ \    / _ \    _____   \ \ / /  |  _|   | |_) |  | |  | |_     | |  |  _|   | |_) |
  ___) | | |___   ___) |  / ___ \  |_____|   \ V /   | |___  |  _ <   | |  |  _|    | |  | |___  |  _ <
 |____/  |_____| |____/  /_/   \_\            \_/    |_____| |_| \_\ |___| |_|     |___| |_____| |_| \_\
slsa-verifier: Verify SLSA provenance for Github Actions

GitVersion:    2.0.3
GitCommit:     38829fa7d9491108bc3a86a6160fb2d53ddc3506
GitTreeState:  clean
BuildDate:     2023-03-11T03:02:01
GoVersion:     go1.18.10
Compiler:      gc
Platform:      darwin/arm64

Not finding EOL'ed version of nginx in container image

What happened:
Not finding EOL'ed versions of nginx in official container images

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):
Scan nginx:1.23.3

Anything else we need to know?:
I was able to resolve the issue by updating the normalizeSemver() function in purl.go.
The package version for nginx is listed as: 1.23.3-1~bullseye

I can resolve by adding the following:

	// Handle packages with tilde (~) characters
	// Example: 1.23.3-1~bullseye
	tildeRe := regexp.MustCompile(`^(\d+\.\d+\.\d+)-\d+~\w+`)
	version = tildeRe.ReplaceAllString(version, "$1")

Side Note
Managing a list of regex's for all potential package version strings is likely to become really tedious.
Instead of hard coding all the regex's, perhaps expose this list in config.yaml as a way to append more patterns to the list in normalizeSemver().

match:
  packages:
    regex:
      - '^(\d+\.\d+\.\d+)p\d+'
      - '^(\d+\.\d+\.\d+)-\d+~\w+'

Environment:
Using container image noqcks/xeol:v0.9.10

[bug] Not picking up EOL in nginx:1.21-alpine

What happened:

xeol nginx:1.21-alpine
 ✔ EOL DB                  [updated]
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [43 packages]
 ✔ Scanned image           [0 eol]

✅ no EOL software has been found

What you expected to happen:

I expect to see nginx 1.21 be EOL, since it is. It shows up as a package when doing syft output on the image. I believe the reason is because of inadequate matching in xeol. 1.21.6 is stored in the xeol database, but the version string contains an -r1 and is not matching because of this.

nginx                      1.21.6-r1         apk
nginx-module-geoip         1.21.6-r1         apk
nginx-module-image-filter  1.21.6-r1         apk
nginx-module-njs           1.21.6.0.7.3-r1   apk
nginx-module-xslt          1.21.6-r1         apk

How to reproduce it (as minimally and precisely as possible):

xeol nginx:1.21-alpine

Anything else we need to know?:

Environment:

Output of xeol version:

Application:          xeol
Version:              0.2.7
Syft Version:         v0.77.0
GitCommit:            1059a82f974122bce8498dec2adc5eefdca65100
Platform:             darwin/arm64
GoVersion:            go1.18.10
Compiler:             gc

Allow configurable tmp dir for docker image load

What would you like to be added:
Need a configurable tmp directory to load image

Why is this needed:
1 error occurred:
* failed to catalog: unable to load image: unable to use DockerDaemon source: mkdir /tmp/scope-386: no space left on device

Additional context:

[bug] match Package is empty in json output

What happened:

in the json output for matches, Package information is missing

  {
   "Cycle": {
    "ProductName": "MongoDB Server",
    "ReleaseCycle": "3.2",
    "Eol": "2018-07-31",
    "LatestRelease": "",
    "LatestReleaseDate": "2018-12-26",
    "ReleaseDate": "2015-12-04"
   },
   "Package": {
    "ID": "",
    "Name": "",
    "Version": "",
    "Locations": {},
    "Language": "",
    "Licenses": null,
    "Type": "",
    "CPEs": null,
    "PURL": "",
    "Upstreams": null,
    "MetadataType": "",
    "Metadata": null
   },
  }

What you expected to happen:

see package information

How to reproduce it (as minimally and precisely as possible):

xeol mongo:3.2 -o json

Anything else we need to know?:

Environment:

Output of xeol version:

Application:          xeol
Version:              0.2.4
Syft Version:         v0.71.0
GitCommit:            c9b3aafe76d53925c23c90f27b90c83d79107364
Platform:             darwin/arm64
GoVersion:            go1.18.10
Compiler:             gc

OS (e.g: cat /etc/os-release or similar):

--lookahead doesn't seem to work

What happened:
NodeJS version 21 is going EOL in about 7 months at the time of writing.
Nevertheless, xeol doesn't pick it up when passing --lookahead 1y.

$ xeol --lookahead='1y' node:21-alpine
 ✔ EOL DB                          [no update available]  
 ✔ Scanned for EOL                 [0 eol matches]  
[0001]  WARN failed to match cycle for distro Alpine Linux: <nil>
✅ no EOL software has been found

What you expected to happen:
I'd expect that xeol reports NodeJS 21 going EOL within one year.

How to reproduce it (as minimally and precisely as possible):
xeol --lookahead='1y' node:21-alpine

Anything else we need to know?:
Scanning NodeJS images that include already EOL versions works fine, so the actual package detection seems to work fine.

$ xeol node:16-alpine
 ✔ EOL DB                          [no update available]  
 ✔ Scanned for EOL                 [1 eol matches]  
[0001]  WARN failed to match cycle for distro Alpine Linux: <nil>
NAME  VERSION  EOL         DAYS EOL  TYPE   
node  16.20.2  2023-09-11  60        binary

Environment:

Output of xeol version: xeol 0.9.8
OS (e.g: cat /etc/os-release or similar):

NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux

Xeol should only use git url when necessary

What happened: when execute xeol in a git directory, xeol always tried to get the remote git URL no matter what command is given.

What you expected to happen: Ignore remote git URL if it is not intended for scanning.

How to reproduce it (as minimally and precisely as possible):

git clone git@self_hosted_git_repo project
cd project
xeol sbom:./sbom.json
# unsupported git url: [email protected]
xeol version
# unsupported git url: [email protected]
xeol -h
# unsupported git url: [email protected]

Anything else we need to know?:

Environment:

Output of xeol version:

Application:         xeol
Version:             0.9.10
BuildDate:           2023-11-14T16:39:11Z
GitCommit:           807e52bcdc5a97d73a523bbf9fa019c932174867
GitDescription:      v0.9.10
Platform:            linux/amd64
GoVersion:           go1.21.3
Compiler:            gc
Syft Version:        v0.92.0
Supported DB Schema: 1

OS (e.g: cat /etc/os-release or similar):

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

xeol fails if sbom.xml is missing some xml tags

What happened:
I have a sbom.xml generated by checkov library and it's missing <components> xml tag.
This command fails with such sbom.xml:

xeol --fail-on-eol-found --lookahead 1m sbom.xml -vv
[0000]  INFO xeol version: 0.9.15
[0000] DEBUG config:
  log:
      quiet: false
      level: debug
      file: ""
  dev:
      profile: none
  output: []
  file: ""
  distro: ""
  check-for-app-update: true
  platform: ""
  search:
      scope: Squashed
      unindexed-archives: false
      indexed-archives: true
  db:
      cache-dir: /home/dwnukowski/.cache/xeol/db
      update-url: https://data.xeol.io/xeol/databases/listing.json
      ca-cert: ""
      auto-update: true
      validate-by-hash-on-start: false
      validate-age: true
      max-allowed-built-age: 120h0m0s
  lookahead: 1m
  fail-on-eol-found: true
  api-key: ""
  project-name: ""
  image-path: Dockerfile
  commit-hash: ""
  match:
      packages:
          using-purls: true
      distro:
          using-cpes: true
  registry:
      insecure-skip-tls-verify: false
      insecure-use-http: false
      auth: []
      ca-cert: ""
  name: ""
  default-image-pull-source: ""
[0000] DEBUG no new xeol update available
[0000] DEBUG gathering packages
[0000] DEBUG Fetching organization policies
[0000] DEBUG loading DB
[0000] DEBUG looking for updates on eol database
[0000] DEBUG checking for available database updates
[0000] DEBUG found database update candidate: Listing(url=https://data.xeol.io/xeol/databases/xeol-db_v1_2024-05-10T03:51:15.748131Z.tar.gz)
[0000] DEBUG existing database is already up to date
[0000] DEBUG no database update available
1 error occurred:
        * failed to catalog: unable to decode sbom: unable to identify format

even though sbom schema says it's optional, so the sbom should be valid and parsed properly:
https://github.com/CycloneDX/specification/blob/8e131b1688ccfe41e1bfdd4b3280f33dcc06d04c/schema/bom-1.4.xsd#L369

What you expected to happen:
xeol not ending with decoding error when a valid sbom.xml is provided

How to reproduce it (as minimally and precisely as possible):
Use command specified above on this sbom file:

<bom xmlns="http://cyclonedx.org/schema/bom/1.4" serialNumber="urn:uuid:5c6fb934-a145-4b58-b779-567374571b13"
     version="1">
    <metadata>
        <timestamp>2024-05-10T10:03:40.878180+00:00</timestamp>
        <tools>
            <tool>
                <vendor>CycloneDX</vendor>
                <name>cyclonedx-python-lib</name>
                <version>6.4.1</version>
                <externalReferences>
                    <reference type="build-system">
                        <url>https://github.com/CycloneDX/cyclonedx-python-lib/actions</url>
                    </reference>
                    <reference type="distribution">
                        <url>https://pypi.org/project/cyclonedx-python-lib/</url>
                    </reference>
                    <reference type="documentation">
                        <url>https://cyclonedx-python-library.readthedocs.io/</url>
                    </reference>
                    <reference type="issue-tracker">
                        <url>https://github.com/CycloneDX/cyclonedx-python-lib/issues</url>
                    </reference>
                    <reference type="license">
                        <url>https://github.com/CycloneDX/cyclonedx-python-lib/blob/main/LICENSE</url>
                    </reference>
                    <reference type="release-notes">
                        <url>https://github.com/CycloneDX/cyclonedx-python-lib/blob/main/CHANGELOG.md</url>
                    </reference>
                    <reference type="vcs">
                        <url>https://github.com/CycloneDX/cyclonedx-python-lib</url>
                    </reference>
                    <reference type="website">
                        <url>https://github.com/CycloneDX/cyclonedx-python-lib/#readme</url>
                    </reference>
                </externalReferences>
            </tool>
            <tool>
                <vendor>bridgecrew</vendor>
                <name>checkov</name>
                <version>UNKNOWN</version>
                <externalReferences>
                    <reference type="build-system">
                        <url>https://github.com/bridgecrewio/checkov/actions</url>
                    </reference>
                    <reference type="distribution">
                        <url>https://pypi.org/project/checkov/</url>
                    </reference>
                    <reference type="documentation">
                        <url>https://www.checkov.io/1.Welcome/What%20is%20Checkov.html</url>
                    </reference>
                    <reference type="issue-tracker">
                        <url>https://github.com/bridgecrewio/checkov/issues</url>
                    </reference>
                    <reference type="license">
                        <url>https://github.com/bridgecrewio/checkov/blob/master/LICENSE</url>
                    </reference>
                    <reference type="social">
                        <url>https://twitter.com/bridgecrewio</url>
                    </reference>
                    <reference type="vcs">
                        <url>https://github.com/bridgecrewio/checkov</url>
                    </reference>
                    <reference type="website">
                        <url>https://www.checkov.io/</url>
                    </reference>
                </externalReferences>
            </tool>
        </tools>
    </metadata>
</bom>

Anything else we need to know?:
That's all I think.
Environment:

Output of xeol version: 0.9.15
OS (e.g: cat /etc/os-release or similar): Fedora running on WSL:

cat /etc/os-release
NAME="Fedora Linux"
VERSION="39 (Container Image)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39 (Container Image)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f39/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=39
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=39
SUPPORT_END=2024-11-12
VARIANT="Container Image"
VARIANT_ID=container

Handle OS `SUPPORT_END` instead of EOL dates from endoflife.date

What would you like to be added:

SUPPORT_END is an optional field in /etc/os-release. When this field exists, we should use it instead of trying to match EOL dates from endoflife.date

Why is this needed:

This will improve the accuracy for EOL dates for OS.

Additional context:

Add a pronunciation section to README for xeol

What would you like to be added:
Add a pronunciation section to README for how to pronounce "xeol".

Why is this needed:
Since it's not clear how to say "xeol", this would help anyone wanting to (a) create a video about how to use xeol or (b) talk about it on a podcast, etc. A few examples of how this is done in other repos:

Ruby 2 is EOL but not reported

What happened:
Running xeol on ruby 2 docker image does not report Ruby EOL

What you expected to happen:
Ruby 2 EOL should appear

How to reproduce it (as minimally and precisely as possible):
xeol ruby:2 --scope all-layers

Anything else we need to know?:

Environment:

Output of xeol version:
Application: xeol
Version: 0.4.9
Syft Version: v0.83.1
GitCommit: 1042076
Platform: darwin/arm64
GoVersion: go1.18.10
Compiler: gc
OS (e.g: cat /etc/os-release or similar):

Allow configurable regex normalization

What would you like to be added:

Related to #269

Managing a list of regex's for all potential package version strings is likely to become really tedious.
Instead of hard coding all the regex's, perhaps expose this list in config.yaml as a way to append more patterns to the list in normalizeSemver().

match:
  packages:
    regex:
      - '^(\d+\.\d+\.\d+)p\d+'
      - '^(\d+\.\d+\.\d+)-\d+~\w+'

DB import cmd seems to be missing from cli

What happened:
Attempted to run xeol db import

What you expected to happen:
It to be imported based on the readme https://github.com/xeol-io/xeol#:~:text=xeol%20db%20import%20%E2%80%94%20provide%20xeol%20with%20a%20database%20archive%20to%20explicitly%20use%20(useful%20for%20offline%20DB%20updates)

How to reproduce it (as minimally and precisely as possible):
xeol db import
Anything else we need to know?:

Environment:

Output of xeol version: 0.5.0
OS (e.g: cat /etc/os-release or similar): macos/alpine

Unexisting recommended option --add-cpes-if-none ?

Before anything:
I just discovered this tool, thanks a lot for your work !

What happened:
In my first tests I scanned a SBOM that uses purl specifications and not CPEs, and got the following message :

[0000]  WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none

So I tried to add it, but the option is not recognized....

$ cat my-sbom.json | xeol --add-cpes-if-none
unknown flag: --add-cpes-if-none

What you expected to happen:
Well, either the option does not exist and you don't recommend to use it, or you implement the option :)

How to reproduce it (as minimally and precisely as possible):
Remove CPEs from a SBOM and run the analysis using cat my-sbom.json | xeol --add-cpes-if-none

Environment:

Output of xeol version:

Application:          xeol
Version:              0.4.6
Syft Version:         v0.83.1
GitCommit:            4453938de9bf10780da6c9244201720ef6b6cf8b
Platform:             linux/amd64
GoVersion:            go1.18.10
Compiler:             gc

OS (e.g: cat /etc/os-release or similar):

PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
VERSION="2023.1"
VERSION_ID="2023.1"
VERSION_CODENAME="kali-rolling"
ID=kali
ID_LIKE=debian
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
ANSI_COLOR="1;31"

Can't make it work

Hi there!

I'm running it like this xeol docker.io/postgres:9 but it shows zero issue.
I took it from your test suite.

What I'm doing wrong?

UPDATE:

BTW, Example from readme also fails: xeol mongo:3.2. It should be replaced by xeol mongo:3.4, which actually works!
So any idea why postgres does not work?

Thanks!

Not finding EOL software in container images

What happened: Not reporting on EOL'ed software in container images.

What you expected to happen: EOL'ed software in container images will be reported.

How to reproduce it (as minimally and precisely as possible):

1: Pull container image with EOL'ed software, and save as tar ball

$ docker pull mysql:5.5.42
$ docker save mysql:5.5.42 > mysql_5.5.42.tar

2: Generate SBOM using syft-json output.

$ docker run --rm -v $(pwd):/tmp anchore/syft:v0.99.0 mysql_5.5.42.tar -o syft-json > mysql.json

3: Run xeol on SBOM. Expectation is that it would include MySQL 5.5 as an EOL'ed product.

$ docker run --rm -v $(pwd):/tmp noqcks/xeol:v0.9.10 sbom:mysql.json
NAME              VERSION  EOL         DAYS EOL  TYPE 
Debian GNU/Linux  7        2016-04-25  2811      os

Anything else we need to know?:

Increasing verbosity shows that it is finding MySQL, but the package type is binary.

$ docker run --rm -v $(pwd):/tmp noqcks/xeol:v0.9.10 -vv sbom:mysql.json 2>&1 | grep mysql
[0001] DEBUG searching for eol matches for pkg=Pkg(type=binary, name=mysql, version=5.5.42, upstreams=0)

Other test I have run.

Using cyclonedx-json output from Syft.
Scanning the container image tar file instead of the SBOM.

Other container images I have tested. All software versions are listed as EOL'ed on endoflife.date / xeol.db.

nginx:1.23.3
haproxy:2.5.14

MySQL 5.5 EOL on 2018-12-31

$ sqlite3 xeol.db "select cycles.* from products join cycles on products.id=cycles.product_id where products.name = 'MySQL' AND cycles.release_cycle = '5.5'"
1629|0|5.5|2018-12-31|||2018-12-21|2010-12-03|2015-12-31|154

nginx 1.23 EOL on 2023-05-23

$ sqlite3 xeol.db "select cycles.* from products join cycles on products.id=cycles.product_id where products.name = 'nginx' AND cycles.release_cycle = '1.23'"
1670|0|1.23|2023-05-23|||2023-03-28|2022-06-21|0|160

Environment:
All versions of tools are based on container tags.

Handle ELTS configuration

What would you like to be added:

Right now xeol only handles EOL dates for standard support on products, but some products like Red Hat may have extended support dates. (In fact, Red Hat has multiple levels of extended support).

There should be some way to specify that a product has ELTS.

Why is this needed:

If this isn't implemented, organizations with ELTS on products will have inaccurate results.

	on:
	workflow_dispatch:
	inputs:
	version:
	description: tag the latest commit on main with the given version (prefixed with v)
	required: true

xeol-io / xeol Goto Github PK

xeol's People

Contributors

Stargazers

Watchers

Forkers

xeol's Issues

🎫 Related issue

Recommend Projects

Recommend Topics

Recommend Org