Repository for the Automation Working Group project to develop a registry for CVE.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Repository for the Automation Working Group project to develop a registry for CNAs.

Project Charter:

Please file an Issue to track new items/problems/concerns so they can be captured.

Data storage considerations:

GDPR, California Privacy, etc.

We may want to ban PII from the CVE user registry, even with informed consent they can still revoke it, potentially years later leaving holes in our data and the relationships.

One possible method to deal with this is to encourage generic organizational contacts, e.g. cve-assign@ or security@ and generic URL's to a security page/etc.

We will also need to ensure that GPG/PGP keys and so on don't include PII in the form of personal emails/etc.

DECISION: Do we ban PII? Do we simply discourage it? Do we allow it and deal with revocation of consent later?

Data updates

We want data updates to be self service as much as possible.

Data to store and publish:

In light of how organizations are evolving and technology changes do we want to require an email address? Or do we simply require an email address AND/OR a URL that can be used to contact the CVE user in question?

Contact email

Ideally a generic email like or

Contact URL

Ideally a generic URL like

Informational URL

Ideally a generic URL like

Organization/Entity name (optional?)

We should have a name for the organization/entity, e.g. their legal name ("IBM", "IBM F-Force", etc.) but should this be required?

Member of Organization/Entity (optional?)

Should we have entities declare if they are a part of any other entity, e.g. "IBM-Force is a part of IBM")?

PGP/GnuPG key(s) identity

Since the keys quite commonly contain PII (names/etc.) it might be best to simply request the full key ID and then require they load the key into the SKS key servers (so GDPR related requests are not our problem).

Service considerations:

Forwarding of email

Some organizations and entities will be individuals and as such may not have the ability or desire to host additional email accounts. Should we investigate offering email forwarding services so an email can be sent but the end users email address be protected? How do we store this data? (E.g. do we have them enter their real email in the data, encrypted to a key used by the service?).

DECISION: Do we support an email forwarding service? Once we provide it we can never take it back until we get everyone off of it and their records updated.

Forwarding of URLs

I do not think we should support URL forwarding as there are numerous services that can be used to provide this.