please release a new version of the api module to make vulnerability scanners happy
- Dominant language
- Go
- Stars
- 30.1k
- Forks
- 4.6k
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 39
Description
This issue is a replacement for https://github.com/hashicorp/consul/issues/10597. When I filed that one, I had some misunderstandings that muddied the waters; the underlying problem is described better here.
Briefly: we've become aware that at least one vulnerability scanning tool (Black Duck)—and/or whatever vulnerability database it is using, which other similar products may also be using—identifies vulnerable versions of Consul very generally as being vulnerable versions of _any Go module in this repo with a matching version tag_. For instance, https://nvd.nist.gov/vuln/detail/CVE-2019-12291 describes a vulnerability in "Hashicorp Consul 1.4.0 and 1.5.0". It is clearly referring to the Consul agent, not the API client; the vulnerability as described is a server-side issue. Nevertheless, if my software uses v1.5.0 of `github.com/hashicorp/consul/api`, the scanner regards that dependency as being simply "Consul v1.5.0" and flags this as unacceptable.
For this and several other CVEs (see below), it is not possible to work around this problem by updating to a newer version of the `api` module that happens to match a fixed version of the root module (an update that wouldn't be fixing an actual vulnerability, but would nevertheless satisfy the scanner)... because no such version exists. For obvious reasons the `api` module is released much less frequently than the main product, and it hasn't had a release since these CVEs were fixed, so the minimum acceptable versions of "Consul" per the CVE are higher than the last patch of `api`.
This isn't exactly your problem, but it is a real problem. We can only get so far by telling our customers "these are not real vulnerabilities", and we can't count on the makers of these scanning products to make their logic more sophisticated. So unless there's some other workaround I've missed, the only options are 1. we switch to using a fork of this repo (doable, but a semi-breaking change and bad for maintainability) or 2. you release a version of `api` with no code changes, just to catch its versioning up to the root module. I hope you'll either consider this or let me know if there's another option.
The CVEs we're being flagged on are http://nvd.nist.gov/vuln/detail/CVE-2019-12291, http://nvd.nist.gov/vuln/detail/CVE-2020-7219, http://nvd.nist.gov/vuln/detail/CVE-2020-13250, http://nvd.nist.gov/vuln/detail/CVE-2020-13170, http://nvd.nist.gov/vuln/detail/CVE-2020-7955, http://nvd.nist.gov/vuln/detail/CVE-2020-12797, http://nvd.nist.gov/vuln/detail/CVE-2020-25864, and http://nvd.nist.gov/vuln/detail/CVE-2020-28053.
Contributor guide
Research direction
Read the linked replacement issue and the listed CVEs, then inspect how the Go api module is versioned and released in this repository. The work is done when a new api module version is released without code changes and scanners no longer flag the outdated matching Consul version.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, release, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100