(feat): Add support for scanning openEuler images

[wjunLu]

Support for openEuler

This commit aims to support scanning openEuler docker images.

I have tested it, the result looks good for me

• scan openeuler/openeuler:22.03-lts-sp1: 3 vulnerabilities

 ✔ Loaded image                                                                               openeuler/openeuler:22.03-lts-sp1
 ✔ Parsed image                                         sha256:b81151a8664ab5c1d48ec0e7fea6a84ec19fad7a147caf216c43261c842174f6
 ✔ Cataloged contents                                          77178e2cf1578002e2496679b1fcb278b239716bd36aed4e16d276830d2ebfea
   ├── ✔ Packages                        [139 packages]
   ├── ✔ Executables                     [941 executables]
   ├── ✔ File metadata                   [8,257 locations]
   └── ✔ File digests                    [8,257 files]
 ✔ Scanned for vulnerabilities     [3 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 0 medium, 3 low, 0 negligible
   └── by status:   3 fixed, 0 not-fixed, 0 ignored
NAME     INSTALLED            FIXED IN             TYPE  VULNERABILITY   SEVERITY  EPSS  RISK
curl     7.79.1-33.oe2203sp1  7.79.1-36.oe2203sp1  rpm   CVE-2024-11053  Low       N/A   N/A
libcurl  7.79.1-33.oe2203sp1  7.79.1-36.oe2203sp1  rpm   CVE-2024-11053  Low       N/A   N/A
python3  3.9.9-35.oe2203sp1   3.9.9-37.oe2203sp1   rpm   CVE-2024-11168  Low       N/A   N/A

• scan openeuler/openeuler:24.03-lts-sp2: 0 vulnerability

 ✔ Loaded image                                                                               openeuler/openeuler:24.03-lts-sp2
 ✔ Parsed image                                         sha256:306b48db5881a1242090e49655210733fcb4c5a193f3670d96d3f72c9e3fa6ff
 ✔ Cataloged contents                                          4f6b3a5ad150f2c7bb85cc167d1e18f05eea05b06ba4f9afbf2e855cb1573712
   ├── ✔ Packages                        [138 packages]
   ├── ✔ Executables                     [915 executables]
   ├── ✔ File metadata                   [7,653 locations]
   └── ✔ File digests                    [7,653 files]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored
No vulnerabilities found

Relatived Issue

anchore/grype#2747

[wjunLu]

@ALL!
Could anyone help review this feature?

[wjunLu]

Hi, @ALL!

Could any committers or maintainers help see this PR?

[willmurphyscode]

Hi @wjunLu! I will try to take a look.

Please be advised that @ALL does not notify anyone who is a maintainer on this repo, but rather notifies whoever got the github username all.

[willmurphyscode]

Hi @wjunLu I noticed that https://repo.openeuler.org/security/data/csaf/cve/ doesn't host any sort of archive. Red Hat and SUSE (and others) for their CSAF data have a distribution schema like this (you can see Red Hat's example at https://security.access.redhat.com/data/csaf/v2/vex/ )

1. There's a file that's the current archive, something like csaf_vex_2026-01-24.tar.zst that contains basically all the data
2. There's a file called changes.csv that contains paths within the archive and when they changed
3. There 's a file called deletions.csv that contains paths within the archive that have been deleted.

This means a vunnel provider can:

1. Download and unpack the archive in a single request
2. Download from changes.csv everything that changed since the archive date
3. Remove everything that's listed as removed in deletions.csv.

In this way, we have one big download, and then a small handful of small downloads (whatever changed since the archive was compiled, say one week worth of new data). This significantly reduces the network round trips and makes the vunnel provider much, much faster. Can you request to openEuler that they adopt something like this? Can you tell me where I can file such a reqeust?

[wjunLu]

Hi @wjunLu I noticed that https://repo.openeuler.org/security/data/csaf/cve/ doesn't host any sort of archive. Red Hat and SUSE (and others) for their CSAF data have a distribution schema like this (you can see Red Hat's example at https://security.access.redhat.com/data/csaf/v2/vex/ )

1. There's a file that's the current archive, something like csaf_vex_2026-01-24.tar.zst that contains basically all the data
2. There's a file called changes.csv that contains paths within the archive and when they changed
3. There 's a file called deletions.csv that contains paths within the archive that have been deleted.

This means a vunnel provider can:

1. Download and unpack the archive in a single request
2. Download from changes.csv everything that changed since the archive date
3. Remove everything that's listed as removed in deletions.csv.

In this way, we have one big download, and then a small handful of small downloads (whatever changed since the archive was compiled, say one week worth of new data). This significantly reduces the network round trips and makes the vunnel provider much, much faster. Can you request to openEuler that they adopt something like this? Can you tell me where I can file such a reqeust?

Thank you very much!

I will let openEuler community know your request and try to push openEuler community provide those files as Redhat.

[willmurphyscode]

Thank you @wjunLu ! I believe that Red Hat is following https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#7-distributing-csaf-documents and additionally providing a tar.zstd archive for efficiently starting a new download. There's some client implementation here: https://github.com/gocsaf/csaf . There's some SUSE CSAF stuff under https://ftp.suse.com/pub/projects/security/, though it's not as easy to consume as Red Hat's.

[westonsteimel]

Also, there is the https://osv.dev bulk data dump of the openEuler vulnerability data in OSV json format at https://osv-vulnerabilities.storage.googleapis.com/openEuler/all.zip. We do prefer going upstream for the data, but if there are any serious issues with fetching the individual files that could potentially be an option.

[willmurphyscode]

@wjunLu I just learned of https://repo.openeuler.org/security/data/osv/all.json which seems like it will have all the info we need for now. I'll update to use that and start working to get this PR in. Thanks for the contribution!

Edit: all.json is just a list of URLs to OSV files; I think the only path forward for this provider is to download the zip files from OSV.dev, since https://repo.openeuler.org/security/data/csaf/cve/ doesn't have any reasonable archive to download.