internal/report: add cve title as report summary

Change-Id: I8198fcac575d59fcab9b8629ed1fe4ed2e9a52ae
Reviewed-on: https://go-review.googlesource.com/c/vulndb/+/548056
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Damien Neil <[email protected]>

internal/report/cve.go

@@ -155,9 +155,9 @@ func cve5ToReport(c *cveschema5.CVERecord, id, modulePath string) *Report {
 	}
 
 	r := &Report{
-		ID:      id,
-		Modules: modules,
-		// TODO(tatianabradley): Add CVE title as summary.
+		ID:          id,
+		Modules:     modules,
+		Summary:     Summary(cna.Title),
 		Description: description,
 		Credits:     credits,
 		References:  refs,

internal/report/cve_test.go

@@ -131,8 +131,8 @@ func TestV4V5Equivalence(t *testing.T) {
 				t.Errorf("archive filename mismatch: v4=%s, v5=%s", v4f, v5f)
 			}
 			if diff := cmp.Diff(v4report, v5report,
-				// Ignore credits because these are not handled properly in v4.
-				cmpopts.IgnoreFields(Report{}, "Credits")); diff != "" {
+				// Ignore credits and summary because these are not handled properly in v4.
+				cmpopts.IgnoreFields(Report{}, "Credits", "Summary")); diff != "" {
 				t.Errorf("mismatch (-v4, +v5):\n%s", diff)
 			}
 		})

internal/report/testdata/cve/TestCVE5ToReport/CVE-2022-39213.txtar

@@ -10,6 +10,7 @@ modules:
     - module: github.com/pandatix/go-cvss
       packages:
         - package: go-cvss
+summary: Out-of-bounds Read in go-cvss
 description: |
     go-cvss is a Go module to manipulate Common Vulnerability Scoring System (CVSS). In affected versions when a full CVSS v2.0 vector string is parsed using `ParseVector`, an Out-of-Bounds Read is possible due to a lack of tests. The Go module will then panic. The problem is patched in tag `v0.4.0`, by the commit `d9d478ff0c13b8b09ace030db9262f3c2fe031f4`. Users are advised to upgrade. Users unable to upgrade may avoid this issue by parsing only CVSS v2.0 vector strings that do not have all attributes defined (e.g. `AV:N/AC:L/Au:N/C:P/I:P/A:C/E:U/RL:OF/RC:C/CDP:MH/TD:H/CR:M/IR:M/AR:M`). As stated in [SECURITY.md](https://github.com/pandatix/go-cvss/blob/master/SECURITY.md), the CPE v2.3 to refer to this Go module is `cpe:2.3:a:pandatix:go_cvss:*:*:*:*:*:*:*:*`. The entry has already been requested to the NVD CPE dictionary.
 cves:

internal/report/testdata/cve/TestCVE5ToReport/CVE-2023-29407.txtar

@@ -10,6 +10,7 @@ modules:
     - module: golang.org/x/image
       packages:
         - package: golang.org/x/image/tiff
+summary: Excessive CPU consumption when decoding 0-height images in golang.org/x/image/tiff
 description: |
     A maliciously-crafted image can cause excessive CPU consumption in decoding. A tiled image with a height of 0 and a very large width can cause excessive CPU consumption, despite the image size (width * height) appearing to be zero.
 credits:

internal/report/testdata/cve/TestCVE5ToReport/CVE-2023-44378.txtar

@@ -10,6 +10,7 @@ modules:
     - module: github.com/Consensys/gnark
       packages:
         - package: gnark
+summary: gnark vulnerable to unsoundness in variable comparison/non-unique binary decomposition
 description: |
     gnark is a zk-SNARK library that offers a high-level API to design circuits. Prior to version 0.9.0, for some in-circuit values, it is possible to construct two valid decomposition to bits. In addition to the canonical decomposition of `a`, for small values there exists a second decomposition for `a+r` (where `r` is the modulus the values are being reduced by). The second decomposition was possible due to overflowing the field where the values are defined. Upgrading to version 0.9.0 should fix the issue without needing to change the calls to value comparison methods.
 cves:

internal/report/testdata/cve/TestCVE5ToReport/CVE-2023-45141.txtar

@@ -10,6 +10,7 @@ modules:
     - module: github.com/gofiber/fiber
       packages:
         - package: fiber
+summary: CSRF Token Validation Vulnerability in fiber
 description: |
     Fiber is an express inspired web framework written in Go. A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to obtain tokens and forge malicious requests on behalf of a user. This can lead to unauthorized actions being taken on the user's behalf, potentially compromising the security and integrity of the application. The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. This vulnerability has been addressed in version 2.50.0 and users are advised to upgrade. Users should take additional security measures like captchas or Two-Factor Authentication (2FA) and set Session cookies with SameSite=Lax or SameSite=Secure, and the Secure and HttpOnly attributes.
 cves:

internal/report/testdata/cve/TestCVE5ToReport/CVE-2023-45283.txtar

@@ -10,6 +10,7 @@ modules:
     - module: std
       packages:
         - package: path/filepath
+summary: Insecure parsing of Windows paths with a \??\ prefix in path/filepath
 description: |
     The filepath package does not recognize paths with a \??\ prefix as special. On Windows, a path beginning with \??\ is a Root Local Device path equivalent to a path beginning with \\?\. Paths with a \??\ prefix may be used to access arbitrary locations on the system. For example, the path \??\c:\x is equivalent to the more common path c:\x. Before fix, Clean could convert a rooted path such as \a\..\??\b into the root local device path \??\b. Clean will now convert this to .\??\b. Similarly, Join(\, ??, b) could convert a seemingly innocent sequence of path elements into the root local device path \??\b. Join will now convert this to \.\??\b. In addition, with fix, IsAbs now correctly reports paths beginning with \??\ as absolute, and VolumeName correctly reports the \??\ prefix as a volume name. UPDATE: Go 1.20.11 and Go 1.21.4 inadvertently changed the definition of the volume name in Windows paths starting with \?, resulting in filepath.Clean(\?\c:) returning \?\c: rather than \?\c:\ (among other effects). The previous behavior has been restored.
 references:

internal/report/testdata/cve/TestCVE5ToReport/CVE-2023-45285.txtar

@@ -10,6 +10,7 @@ modules:
     - module: std
       packages:
         - package: cmd/go
+summary: Command 'go get' may unexpectedly fallback to insecure git in cmd/go
 description: |
     Using go get to fetch a module with the ".git" suffix may unexpectedly fallback to the insecure "git://" protocol if the module is unavailable via the secure "https://" and "git+ssh://" protocols, even if GOINSECURE is not set for said module. This only affects users who are not using the module proxy and are fetching modules directly (i.e. GOPROXY=off).
 credits:

internal/report/testdata/cve/TestCVE5ToReport/CVE-2023-45286.txtar

@@ -10,6 +10,7 @@ modules:
     - module: github.com/go-resty/resty/v2
       packages:
         - package: github.com/go-resty/resty/v2
+summary: HTTP request body disclosure in github.com/go-resty/resty/v2
 description: |
     A race condition in go-resty can result in HTTP request body disclosure across requests. This condition can be triggered by calling sync.Pool.Put with the same *bytes.Buffer more than once, when request retries are enabled and a retry occurs. The call to sync.Pool.Get will then return a bytes.Buffer that hasn't had bytes.Buffer.Reset called on it. This dirty buffer will contain the HTTP request body from an unrelated request, and go-resty will append the current HTTP request body to it, sending two bodies in one request. The sync.Pool in question is defined at package level scope, so a completely unrelated server could receive the request body.
 cves: