Not finding EOL software in container images

[bisbell-ngc]

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.

[noqcks]

hey @bisbell-ngc thanks for opening this issue!

This is because endoflife.date didn't have identifiers for mysql yet, I've added them in this PR https://github.com/endoflife-date/endoflife.date/pull/4424

Once the PR is merged then the xeol database should be updated within 24 hours and it will detect mysql.

[bisbell-ngc]

Thank you. In the future should I submit these requests directly to endoflife-data as issues? I have a feeling we're going to run across a lot of these in container images; I don't see many entries in the database for generic or binary purls.

[noqcks]

You can submit them here, since it could actually be the case that it's not just endoflife.date that was the problem.

In this case there were actually two problems

1. endoflife.date didn't contain the right purls
2. the version of syft we're using didn't pick up binary mysql (added in https://github.com/anchore/syft/pull/2316)

Im working on the second one right now.

[noqcks]

mysql is now detected in v0.9.11

$ xeol mysql:5.5.42
 ✔ EOL DB                          [no update available]
 ✔ Scanned for EOL                 [2 eol matches]
NAME              VERSION  EOL         DAYS EOL  TYPE
Debian GNU/Linux  7        2016-04-25  2815      os
mysql             5.5.42   2018-12-31  1835      binary

[noqcks]

Thanks again for opening all these issues @bisbell-ngc and making the tool better for everyone 🙏