Can we manually create a vulnerability?

[astringer]

Is it possible to create a vulnerability manually through the UI? Not a VIT, rather an entry under "Libraries" in either NVD, CWE or third-party? Not seeing a "NEW" button out-of-the-box, or in any of the other Libraries for that matter. This is within the Vulnerability Response module, NOT the Application Vulnerability Response module. Context is below:

I am manually creating VITs based on a findings report from a penetration testing team. I wish to link a vulnerability to the VIT, but the only options are those pulled in from third-party libraries, NVD, CVE, etc. I wish to create manual vulnerabilities labeled as: 2025 Q1 Pentest: Finding #. This way, I can still populate the 'vulnerability" tab of the VIT with all the information the remediation teams need to resolve the finding. By populating a vulnerability into these manually created VITs, I can also use this information to feed the logic conditions of my vulnerability calculator rules which determine Risk Score and Risk Rating.

If anyone knows how to accomplish this, or alternatives to otherwise feed penetration test findings (non-app related) into assignable Vulnerable Items (VITs) or Remediation Tasks (VULs), please let me know.

Thank You

[Aaron Molenaar]

How we accomplished getting pen test results (and other adhoc vuln finding data sources) into VR was to create a common spreadsheet template that is imported via predefined import and transform actions that we created.

We then massage the source data - from where ever we get it - into the common upload template then import. The import process first creates all the third-party vulnerability records needed (with links like CVE, references, etc), then in a second transform creates VIT records linked to the vuln record.

Hope that gives you some ideas.

[josephmorsb]

By default the create ACL on sn_vul_entry and sn_vul_third_party_entry is "nobody".  It's designed to have automation bring those vulnerabilities into the "Library" via integrations.  You could always change that to include an appropriate role (e.g. sn_vul.vulnerability_analyst), but that opens up a can.  I'd first ask is there a reason you cannot link your Pentest finding to a specific CVE?   I'm assuming you're testing infrastructure and not applications or else you'd be using the Pentest process in Application VR?  So for example if you were to attack a web server and somehow gain an interactive shell, there's likely some formal vulnerability you exploited to accomplish that, so I'd think you'd want to document that.  There is also a Summary field that is free text on every VIT (not from the Vulnerability) you can use for some of the specific details.

Alternatively, You could also do as Aaron suggested and use an import/transform which would allow you to leave the ACLs out of the box.  It's a few extra steps, but not too bad.

[astringer]

That is correct, results in questions are from infrastructure, vice applications. Findings received in external pentest report do not always have a CVE associated to them. For example, if a user has a weak password that is easily guessed/brute forced or unnecessary ports are left open on devices. The non-vulnerability summary field may be a viable option, the issue of assigning the proper risk rating / severity still remains

[praveenhamsaraj]

Use Manual upload, there is a ServiceNow excel available in the Manual option, fill in and upload the data.