wolfi-dev/advisories

Security advisory data for Wolfi

advisories's Issues

Specify which distro package versions are affected in each advisory

One of the vestigial aspects of our advisory data today that lingers from our beginning with the Alpine "secfixes" approach is that we don't actually enumerate a list or range of distro package versions affected by a given vulnerability, we only record the fixed version of the distro package.

As the advisory data continues to become more full-featured, we should encode the full set of affected package versions, using either ranges or discrete sets.

This will help scanners produce more reliable results, since they won't need to guess about whether an installed version less than the noted fixed version is affected.

Schema suggestions welcome!

Add support for globally suppressing CVEs

Description

There are a lot of CVEs, such as CVE-2023-35116, where we will just want to suppress them across all packages. Presently, we have to do this in every single package we want to NAK the CVE in, but being able to do it in all packages would be helpful.

It might be worth extending the secfixes feed for this.

cgr.dev/chainguard/kube-fluentd-operator:latest

$ grype cgr.dev/chainguard/kube-fluentd-operator:latest
 ✔ Vulnerability DB                [no update available]
 ✔ Loaded image                                                                                                                                                                                                                                                                                                                                                                                                                                          cgr.dev/chainguard/kube-fluentd-operator:latest
 ✔ Parsed image                                                                                                                                                                                                                                                                                                                                                                                                                  sha256:dd308e6d3e3b063b59c3bd95cb77155b4fe03fd60c7524022ec4e0d0790c2947
 ✔ Cataloged packages              [373 packages]
 ✔ Scanned for vulnerabilities     [11 vulnerabilities]
   ├── 0 critical, 4 high, 7 medium, 0 low, 0 negligible
   └── 4 fixed
[0017]  WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none
NAME     INSTALLED  FIXED-IN  TYPE  VULNERABILITY        SEVERITY
grpc     1.52.0     1.53.0    gem   GHSA-6628-q6j9-w8vg  High
grpc     1.52.0     1.53.0    gem   GHSA-9hxf-ppjv-w6rq  Medium
grpc     1.52.0     1.53.0    gem   GHSA-cfgp-2977-2fmm  High
openssl  3.1.0                gem   CVE-2023-0464        High
openssl  3.1.0                gem   CVE-2023-0465        Medium
openssl  3.1.0                gem   CVE-2023-0466        Medium
openssl  3.1.0                gem   CVE-2023-1255        Medium
openssl  3.1.0                gem   CVE-2023-2650        High
uri      0.12.1               gem   CVE-2023-36617       Medium
uri      0.12.1     0.12.2    gem   GHSA-hww2-5g85-429m  Medium
webrick  1.8.1                gem   CVE-2008-1145        Medium

Looking at GHSA-6628-q6j9-w8vg / CVE-2023-1428

README should include "wolfictl" command to create an advisory

I hate having to figure the right incantation each time.

Reducing code duplication between advisories

Summary

Currently, we require a dedicated .yaml file for each application version, with it's own set of advisories. Often these can be more or less copy/paste between app versions.

Take for example grafana. There are (at the time of writing), three supported versions: v8, v9.5 and v10.x (latest). This would require us to create at least three advisory YAMLs (grafana-8.yaml, grafana9.5.yaml, grafana.yaml).

I believe this format is required for vulnerability feeds and scanners to parse, but perhaps there is a better way to generate these, whilst maintaining a single yaml file for each application?

Ideal outcome

A single .yaml file for each application, i.e we'd only ever have a 'grafana.yaml' with advisory data covering all releases.

How might we achieve this?

Perhaps we could introduce a 'affected_versions' parameter. By default when this is not set, the CVE advisory is only appliciable to the latest releases (or perhaps we default to being applicable to all?). Then we can use 'affected_versions' to pin an advisory to a specific version.

I guess we'd need to create some logic to then generate the individual .yamls for each release in the format the scanners are looking for? Which in itself might be challenging.

I'm sure there may be other options too, but the hope / goal would be to reduce engineering toil by having to make copies of the .yaml each time we need to produce a pinned version of an application, or update advisories in multiple files for multiple releases?

cgr.dev/chainguard/gradle:latest

I'm currently investigating CVE-2023-2976 that Grype is reporting on our image cgr.dev/chainguard/gradle:latest.

Jenkins CVE-2016-1000027

I'm looking into this CVE in the cgr.dev/chainguard/jenkins:latest image :)

Require setting the aliases of the CVEs when available

Description

I'd suggest to add the aliases to the CVE advisory data when available to avoid situations such as the issue commented here: https://chainguard-dev.slack.com/archives/C05GYUBM07Q/p1698059647569109.

Composer seems missing

Description

See https://github.com/wolfi-dev/os/pull/21715/files and
https://blog.packagist.com/composer-2-7-7/

Shouldn't that be listed here 🤔

Prevent advisory creation for packages that don't exist in the repo

Context

Today, there's nothing preventing a contributor from adding new advisories to the repo for packages that don't exist in Wolfi.

These additions are usually a mistake, such as when:

1. The package name is misspelled (including mistakes in the version stream suffix)
2. The package used to exist in the distro but has since been removed or moved to another distro, and thus the advisory should instead be created in the correct advisories repo.
3. The package never existed in this distro but does exist in another distro (e.g. it's an enterprise package).

In other scenarios, it's not a mistake (it's intentional), such as when:

1. The package is being created for the first time, so corresponding advisories are created immediately to maintain our coverage in the advisory data set. (In these cases, the CVE scan in Wolfi's CI won't pass until there's advisory data that accounts for the package's vulnerabilities.)
2. The advisory was introduced back when the package did exist in the distro. At the time of writing, we have not decided to remove or adjust advisory documents for this scenario (this is its own discussion with tradeoffs), so they would still exist in the repo when new PRs are opened.

Proposal

Add functionality to the advisories repo's CI to fail whenever an advisory document's .package.name isn't found in Wolfi.

Concerns

This solution doesn't account for the scenarios listed in the "not a mistake" category above. We'll need to figure out how to account for those scenarios.

Technical considerations

We should clarify the definition of when a package "exists in the distro". There are two relevant sets: (A) packages currently defined in the distro repo (e.g. in https://github.com/wolfi-dev/os on main), and (B) found in the APKINDEX for the distro.

Thus, there are several possibilities for how we define "exists in the distro" using these sets, such as:

1. A ∪ B
2. A ∩ B
3. etc.

Support for virtual packages (i.e. sets of version streams)

Context

Similar to the example problem mentioned in #277, version streams can be the reason advisory data becomes unlinked from relevant distro packages in various contexts. #277 showed one example of this, where converting an existing distro package to a version stream results in a name change that breaks the link between distro package and advisory data. (And package names can change, and have changed, for other reasons unrelated to version streams.)

However, version streams are an interesting case — more generally than what's accounted for in #277 — because they typically imply we'll keep making more of them. For example, right now for the go "virtual package", we have the version streams go-1.19, go-1.20, and go-1.21. In the case of Go, new minor releases come out roughly every February and August, so in a few more months we'll have go-1.22, and so on into the future.

The separation of a distro package into various version streams is a Wolfi-ism — the upstream project typically doesn't reflect this same splitting of a package's identity. Moreover, it's common for vulnerability data and the analysis we encode in advisory data to relate more to the (virtual) package on the whole, rather than to one or two individual version streams.

In these cases, keeping up with new version streams can quickly become tedious and error-prone. We might have advisory data for existing version streams of a virtual package that applies to all future version streams as well. Today, we need to realize when new version streams are being created and remember to perform the necessary copies to new advisory documents. Doing so creates redundancy, and forgetting to do so creates gaps in the data that quickly affects downstream users and vulnerability scan results.

Proposal

We could add a new field to the advisory document schema that the .package.name field is referring to a virtual package, not a literal package name.

For example, in the case of Go, instead of:

schema-version: "2"

package:
  name: go-1.19

advisories:
  - id: CVE-2020-29509
  # ...

and

schema-version: "2"

package:
  name: go-1.20

advisories:
  - id: CVE-2020-29509
  # ...

and

schema-version: "2"

package:
  name: go-1.21

advisories:
  - id: CVE-2020-29509
  # ...

... we could just have:

schema-version: 2.0.1

package:
  name: go
  virtual: true

advisories:
  - id: CVE-2020-29509
  # ...

Then, this data, in combination with data taken from distro package definitions, could result in downstream artifacts where our concise advisory data representation gets "inflated" to instead describe all literal packages when needed. For example, in the Go example above, we could still produce a secdb with entries for each of go-1.19, go-1.20, and go-1.21.

An alternative implementation is that we wouldn't need a new field, but instead we'd leverage the APK semantics of package search, where a .package.name value of go would link to matching packages that provided go=....

Support for historical/alternative package names

Context

Every once in a while, a distro package's name changes. One reason for this is that we create a version stream for that package, such as in this PR when we renamed php to php-8.2.

Advisory documents reference packages by their name (in .package.name). So one problem that can arise is if a distro package Melange file changes the package name without updating the corresponding advisory document, the link is broken. In this case, no distro package can be found for the given advisory document.

A more user-visible problem with this scenario is that vulnerability scanners will no longer know to apply security data derived from our advisory document when analyzing the installed distro package. This can result in false positives and false negatives, depending on the scanner matching strategy being used.

One last consideration: it's also possible that simply updating the package name in both the Melange file and the advisory document causes a problem. Although we've updated the distro package name, the former package name has been used in published APKs and still exists "in the wild". If we update the package name in the advisory data, scans of installations of these former versions of the APK will can become less accurate, since relevant data is not being leveraged by the scanner.

Proposal

We could add a new field to the advisory document schema where we can list historical/alternative names for the package described in the given advisory document.

For example, in the above PHP example, we might have an advisory document that now looks like this:

schema-version: 2.0.1

package:
  name: php-8.2
  alternative-names:
    - php

advisories:
# ...

Intended benefits of this change

1. Downstream data artifacts avoid missing this data link. For example, the secdb could include copies of this advisory data listed under both "php-8.2" and "php", ensuring that scanners are never in a place to miss out on this data.
2. Our advisory tooling is able to link to additional related APKs or entries in the APKINDEX when needed.

gradle-8: Investigate CVE-2022-46751

A new CVE is being reported on our gradle-8:

├── 📄 /usr/share/java/gradle/lib/plugins/ivy-2.3.0.jar
│       📦 ivy 2.3.0 (java-archive)
│           High CVE-2022-37866
│           Medium CVE-2022-46751 GHSA-2jc4-r94c-rp7h fixed in 2.5.2
│           High CVE-2022-37866 GHSA-wv7w-rj2x-556x fixed in 2.5.1

We need to investigate the status of this CVE!

@stormqueen1990 would you be able to take this on next week? Given you became very familiar with gradle :)

Improvements to data validation in CI

Over the past several months, we've identified a handful of specific expectations we have for the data quality in this repo that we've been checking manually during PR reviews. Several of these expectations could instead be asserted by CI. Doing so would reduce toil in advisory PR reviews and increase confidence in the repository's data quality.

This issue tracks progress on our short-term data validation goals.

Standard validation

• All known aliases have been captured (for any new/modified documents in the PR)
• All referenced packages are currently defined in Melange files in Wolfi (link to existing issue)
• All referenced package versions can be found in Wolfi's APKINDEXes
• Advisory fixed events don't refer to the first published version of a package

Diff validation

• Existing advisory events haven't been modified
• Existing advisory events haven't been deleted
• New advisory events' timestamps are "recent" (< 3 days old for now)

Automated discovery event PRs can have conflicts when working with subpackages

We have automation that automatically created CVE detection events which is great! Some packages that have subpackages have related advisory PRs created but also have merge conflicts.

Some examples:
#788
#786
#781
#756
#755

Should the status on python CVE-2007-4559 be adjusted now?

Description

CVE-2007-4559 is currently marked as not_affected for all versions of python provided by Wolfi, which made sense at the time since upstream had rejected calls to make changes to the behaviour in the past; however, due to more recent attention around it they have decided to make changes to address this - PEP-706 and python/cpython#73974 (comment).

I had spoken to @luhring about this one previously but never captured anywhere and thought it was worth bringing up for discussion.

I'm not sure what the status on the Wolfi advisory should be now, but I do think that the impact should at least be updated to reflect the new stance

I also wondered if there was any interest in patching the existing wolfi python distributions to bring forward the default behaviour that would be introduced in python 3.14 to completely resolve CVE-2007-4559?

telegraf-1.26: Investigate CVE-2023-34231

We detected CVE-2023-34231 in our telegraf-1.26 package. This CVE is associated with the github.com/snowflakedb/gosnowflake package.

The Go vulnerability DB group indicated this CVE is likely not a vulnerability: golang/vulndb#1846

The fix isn't fixing anything. We need to investigate further to identity the next steps here.