Support for Go module pseudo-versions

[metalmatze]

Question

We depend on some Go modules that don't follow the sub-path conventions. Meaning, they don't release with a /v2 suffix, for example. Therefore, we have to use pseudo-versions of these Go modules...

module github.com/...

go 1.22.0

require (
	...
	github.com/dexidp/dex v0.0.0-20240409110506-3705207f0190
	...
)

This causes Trivy to complain:

go.mod (gomod)

Total: 4 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 3)

┌──────────────────────────┬────────────────┬──────────┬────────┬───────────────────────────────────┬─────────────────────────────┬─────────────────────────────────────────────────────────────┐
│         Library          │ Vulnerability  │ Severity │ Status │         Installed Version         │        Fixed Version        │                            Title                            │
├──────────────────────────┼────────────────┼──────────┼────────┼───────────────────────────────────┼─────────────────────────────┼─────────────────────────────────────────────────────────────┤
│ github.com/dexidp/dex    │ CVE-2020-26290 │ CRITICAL │ fixed  │ 0.0.0-20240409110506-3705207f0190 │ 2.27.0                      │ Critical security issues in XML encoding in                 │
│                          │                │          │        │                                   │                             │ github.com/dexidp/dex                                       │
│                          │                │          │        │                                   │                             │ https://avd.aquasec.com/nvd/cve-2020-26290                  │
│                          ├────────────────┤          │        │                                   │                             ├─────────────────────────────────────────────────────────────┤
│                          │ CVE-2020-27847 │          │        │                                   │                             │ dexidp/dex: authentication bypass in saml authentication    │
│                          │                │          │        │                                   │                             │ https://avd.aquasec.com/nvd/cve-2020-27847                  │
│                          ├────────────────┤          │        │                                   ├─────────────────────────────┼─────────────────────────────────────────────────────────────┤
│                          │ CVE-2022-39222 │          │        │                                   │ 2.35.0                      │ dexidp: gaining access to applications accepting that token │
│                          │                │          │        │                                   │                             │ https://avd.aquasec.com/nvd/cve-2022-39222                  │
├──────────────────────────┼────────────────┼──────────┤        ├───────────────────────────────────┼─────────────────────────────┼─────────────────────────────────────────────────────────────┤

The version we actually depend on is 3705207f0190, which in turn is https://github.com/dexidp/dex/releases/tag/v2.39.1

We are wondering how to move forward with this. Anything you recommend?

Target

Filesystem

Scanner

Vulnerability

Output Format

Table

Mode

Standalone

Operating System

Arch Linux and GitHub Actions

Version

Version: 0.50.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2024-04-22 12:11:55.012425743 +0000 UTC
  NextUpdate: 2024-04-22 18:11:55.012425233 +0000 UTC
  DownloadedAt: 2024-04-22 12:28:59.390303909 +0000 UTC

[knqyf263]

The only way is to ask for Major version suffixes to be attached to that module. If I understand correctly, it's mandatory.

Starting with major version 2, module paths must have a major version suffix like /v2 that matches the major version. For example, if a module has the path example.com/mod at v1.0.0, it must have the path example.com/mod/v2 at version v2.0.0.

https://go.dev/ref/mod#major-version-suffixes

[metalmatze]

Yes, generally speaking, that's correct. However, it's sadly not the reality.
For example, a project with v2 out is suddenly asked to break the folder structure with Go modules. Many projects don't do that...

[knqyf263]

We could add something like a version-replace feature ( v0.0.0-20240409110506-3705207f0190 => v2.39.1) to our config file and CLI flag, but then the user would have to manage the mapping between pseudo-version and the actual version.

[metalmatze]

That sounds like a plan. Unfortunately, I don't see an automated way either. 🤔