Adjust Cve-Id document schema to support deleting user accounts

[wizedkyle]

Problem Statement

Currently cve-services doesn't support deleting users because when a CVE ID is reserved by an organisation (there could be more actions) the user UUID that reserved it is added to the CVE ID document.

Extra information can be found in this PR

Example Cve Id document:

{
    "_id": {
        "$oid": "617b751d5899b358b943a78e"
    },
    "requested_by": {
        "cna": "4b087520-e2be-4095-ba27-65859c467701",
        "user": "c326b9f0-dfd8-4ab2-9185-191428cd2253"
    },
    "time": {
        "created": {
            "$date": "2019-04-11T00:00:00.000Z"
        },
        "modified": {
            "$date": "2021-05-11T15:07:17.093Z"
        }
    },
    "cve_id": "CVE-1999-0001",
    "cve_year": "1999",
    "state": "REJECTED",
    "owning_cna": "4b087520-e2be-4095-ba27-65859c467701",
    "reserved": {
        "$date": "2019-04-11T00:00:00.000Z"
    },
    "__v": 0
}

Potential Idea

Instead of including the user UUID in the requested_by field in the Cve Id document an alternate approach could be to have an audit collection which would have documents that detail any changes that are made and provide the necessary details. Then add an audit field to the Cve Id document that references the relevant document in the audit collection essentially maintaining an audit of any actions against the Cve Id.

A key part of the audit collection document would be to have the user who made the change referenced by the username rather than the UUID that way if the user is deleted the record of the change is still intact.

This approach could be implemented across all data sets that need to be audited assuming there isn't already an audit process built in to the system.

For example: a Cve Id document could be adjusted to have an audit field and the subsequent audit document,

{
    "_id": {
        "$oid": "617b751d5899b358b943a78e"
    },
    "audit": [
        {
        "id": "af2e3637-2755-4c9a-a516-1060b2b9f9f9",
        "time": "2019-04-11T00:00:00.000Z"
        }
    ],
    "requested_by": {
        "cna": "4b087520-e2be-4095-ba27-65859c467701",
    },
    "time": {
        "created": {
            "$date": "2019-04-11T00:00:00.000Z"
        },
        "modified": {
            "$date": "2021-05-11T15:07:17.093Z"
        }
    },
    "cve_id": "CVE-1999-0001",
    "cve_year": "1999",
    "state": "REJECTED",
    "owning_cna": "4b087520-e2be-4095-ba27-65859c467701",
    "reserved": {
        "$date": "2019-04-11T00:00:00.000Z"
    },
    "__v": 0
}

{
    "action": {
        "cna": "<cna UUID/name/shortname>",
        "api_call": "reserve cve id etc",
        "username": "[email protected]"
    }
    "UUID": "af2e3637-2755-4c9a-a516-1060b2b9f9f9",
    "time": "2019-04-11T00:00:00.000Z"
}

Questions (assuming this could be a valid approach)

Is this even possible?

If this is possible (and thats a big if) Is it feasible to make this adjustment or is there a lot tied to the user UUID in the requested_by field?

Would there be limitations to the amount of documents that could be stored in an audit collection?

How would the integrity of the audit documents be verified/maintained etc?