- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-05-2017 08:29 AM
For security operations module, we currently ingest QualysGuard infrastructure vulnerability data into Vulnerability Management module and that works great.
For application security testing we use Veracode for static, dynamic, and manual pen testing as part of our internal testing for SDLC.
What would be the best place to import those vulnerabilities, or is that something in roadmap (application vulnerability management versus infrastructure vulnerability management)?
Key difference here is that while infrastructure vulnerability is associated with a cmdb_ci (server, network device, etc), an application vulnerability is associated with a software build for an application.
Ideally, I would like to generate scorecards for each business unit / department showing where they stand for infrastructure remediation and application remediation. I'm half way there with Qualys data in Vulnerability Management, just need to figure out the right way to process application vulnerability findings.
Thanks,
Jason
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2019 01:04 PM
Hi Jason,
I would say Vulnerability Response is the right base module for what you have in mind. So same Vulnerability Response processes should still work, meaning
- ingesting vulnerabilities from third party system
- or create vulnerabilities using ServiceNow directly
- Generate Vulnerable Items from ingested data
- Create Vulnerability Groups to group VIT together
- Remediate
- Close VIT/VUGs
You can use existing tables for Vulnerability Entries, and Solutions. There is an existing table cmdb_ci_appl that you could use for your Application ConfigurationItem (or you can extend this table to meet your needs).
Customize the ingesting script to match look CI in this Application table, and create VIT accordingly (you can modle it after your existing Qualys import). All the rest should be streight forward.
If you decide to track Application Vulnerability via ServiceNow, you can use Vulnerablity Entry from existing table, and CI from the customized Applicaiton table, create new Vulnerable Items.
Hope this make sense.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2017 12:11 PM
Hi Jason,
This is something being tracked by ServiceNow, thanks for your feedback.
May I suggest potentially creating another app to pull in this data?
Syra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2019 05:22 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2019 01:04 PM
Hi Jason,
I would say Vulnerability Response is the right base module for what you have in mind. So same Vulnerability Response processes should still work, meaning
- ingesting vulnerabilities from third party system
- or create vulnerabilities using ServiceNow directly
- Generate Vulnerable Items from ingested data
- Create Vulnerability Groups to group VIT together
- Remediate
- Close VIT/VUGs
You can use existing tables for Vulnerability Entries, and Solutions. There is an existing table cmdb_ci_appl that you could use for your Application ConfigurationItem (or you can extend this table to meet your needs).
Customize the ingesting script to match look CI in this Application table, and create VIT accordingly (you can modle it after your existing Qualys import). All the rest should be streight forward.
If you decide to track Application Vulnerability via ServiceNow, you can use Vulnerablity Entry from existing table, and CI from the customized Applicaiton table, create new Vulnerable Items.
Hope this make sense.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-08-2021 09:14 AM
Fyi, this has been addressed with the latest release of Application Vulnerability Response, OOB.