invalid REJECTED records accepted in production and test (no englishLanguageDescription)

[ElectricNroff]

Recently the atlassian CNA successfully submitted (in production) about 40 CVE Records that don't comply with the CVE JSON 5.0 schema. Analogous records can be successfully submitted to cveawg-test.mitre.org. Examples:

• https://cveawg.mitre.org/api/cve/CVE-2022-43783
• https://cveawg-test.mitre.org/api/cve/CVE-2022-204207

Parts of the records look like:

"cveId":"CVE-2022-43783"
"dateRejected":"2023-01-01T00:01:21.181Z"
"assignerShortName":"atlassian"
"rejectedReasons":[{"lang":"eng","value":"To maintain compliance with CNA rules ...

Here, eng isn't valid because it doesn't match:

"englishLanguage"
...
"pattern": "^en([_-][A-Za-z]{4})?([_-]([A-Za-z]{2}|[0-9]{3}))?$"

which is required by:

"englishLanguageDescription": {
...
          "$ref": "#/definitions/englishLanguage"

as used by:

"descriptions": {
...
"contains": {
        "$ref": "#/definitions/englishLanguageDescription"

for:

"rejectedReasons": {
  ...
          "$ref": "#/definitions/descriptions"

(In other words, for the lang in rejectedReasons, there typically should be something like en or en_US, not eng.)

These seem to be accepted on the production server and the test server for different reasons.

The code for the test server seems to be doing:

cve-services/src/controller/cve.controller/cve.controller.js

Lines 477 to 480 in 6ab7600

	result = Cve.validateCveRecord(newCveObj.cve)
	if (!result) {
	return res.status(500).json(error.serverError())
	}

where

cve-services/src/model/cve.js

Lines 30 to 38 in 6ab7600

	CveSchema.statics.validateCveRecord = function (record) {
	const validateObject = {}
	validateObject.isValid = validate(record)
	if (!validateObject.isValid) {
	validateObject.errors = validate.errors
	}
	return validateObject
	}

Here, the return value, validateObject, is true even when validateObject.isValid is false.

(In https://github.com/CVEProject/cve-services/releases/tag/v2.1.1-sd for production, the reject endpoints don't call the validateCveRecord function. In the newer code, they do call the validateCveRecord function but use it incorrectly.)