search

nautobot / nautobot-app-device-lifecycle-mgmt

Device Lifecycle Management App for Nautobot
https://docs.nautobot.com/projects/device-lifecycle/en/latest/
Other
43 stars 25 forks source link

Feature Request: Additional Fields for CVE #81

Open JimmyKip opened 2 years ago

JimmyKip commented 2 years ago

Environment

Proposed Functionality

For CVE records there are some additional details that may be better included as part of the model rather than custom fields. These aren't necessarily part of the CVE record itself but are often retrievable from vendors in their advisories.

  1. A 2nd URL field to include a link to the machine readable version of the CVE from the vendor.
  2. A text field that can be used to include any tests that can validate exposure to the CVE.

Use Case

  1. eg Cisco provide a CVRF record for their advisories, along with the CVE details (https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190925-httpserv-dos/cvrf/cisco-sa-20190925-httpserv-dos_cvrf.xml). Having this URL included with the CVE in Nautobot is handy as it can be used to pass this on to another tool.
  2. Some vendors provide additional information associated with their CVE records, using the same example above (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20190925-httpserv-dos.html), Cisco note tests that can be run to check exposure; "administrators can log in to the device and use the show running-config | include ip http server|secure-server command in the CLI to check for the presence of the ip http server command or the ip http secure-server command in the global configuration.". Including this in the CVE entry allows for automated testing to confirm exposure to a particular CVE.
joewesch commented 2 years ago

Hello, thanks for creating this issue. I see you also created #80 which is in a similar vein of adding more fields to the CVE model.

Is there a particular reason why you think these items shouldn't be custom fields? Your comment of "These aren't necessarily part of the CVE record itself" would be one of the reasons I would be hesitant on adding them. I'm not saying they aren't valid and desired fields for you and your installation, but are they valid and desired fields for all installations of this plugin?

Are you lacking some functionality with them as custom fields as opposed to the standard model fields? You mention "pass this on to another tool" so by adding these items as custom fields do you not have that ability?

JimmyKip commented 2 years ago

Re #80 that I think this is a part of the CVE record schema, there's a few different areas for metadata which can include the date for an update to the CVE record. For me I think its important to track not just when the CVE was published within the Nautobot record, but if it has been updated subsequently & when as this can then trigger further actions, eg scripted associations between CVE record & softwares.

I agree in terms of reflecting the CVE the fields mentioned here don't have the same definition in the schema so likely better as custom fields (which is what im doing to date). In effect adding them would change the CVE into a more generic model rather than one specific to the CVE structure.