gosu vulnerabilities and usage of End-of-Life Version of GO

In December there was an issue to move to newer version of gosu to address vulnerabilities, however, that move to newer gosu had minimal impact on CVE reduction.

gosu is being flagged by industry vulnerability scanners with GO vulnerabilities associated with the version of GO being used by gosu. (53 CVEs at the time of this issue) Also, security auditors flag gosu for using an EOL version of GO. Multiple issues have been logged to the gosu project over time by many dependent projects, or users of the software. The gosu maintainer refuses to update and his feedback is gosu itself is not vulnerable due to GO as gosu does not use the affected GO modules or execution paths, and he has no plans to update GO even though the version used is EOL. This leaves individuals or companies in a bad state due to vulnerability management requirements dictatating the clearance of CVEs in a timely fashion (whether potential False Positives or not) along with no usage of EOL software.

The Cassandra Docker Image is affected by the gosu issue. As to potential solutions, assuming the gosu maintainers continues the refusal position, would be Cassandra rebuild gosu with newer version of GO and include in the Image or replace gosu with alternate approach. Alternatively, the consumers of the Cassandra Image could create a derived Image and implement their alternatives on their own.

Thoughts on how to proceed? Is this something the project would address or adopt proposed PR fixes to this issue?

Start by reviewing how the Cassandra Docker Image includes gosu and the reported Go version, then examine the proposed options: rebuilding gosu with a newer Go version or replacing gosu. Done means agreeing on and implementing a project-supported approach that addresses the reported vulnerability-scanner findings and EOL Go usage.