How it works
VulnIQ automatically aggregates data from various sources,
that you can configure yourself, and
make them available through unified APIs.
You can use VulnIQ APIs to integrate VulnIQ data into your
existing applications and processes.
Even if data formats at their sources change VulnIQ APIs will continue to work in a backwards
compatible way so that you will not have to update your integrations everytime a data source or format
Example use case:
- You want to integrate vulnerability and advisory information into your JIRA workflows
- You want to utilize data from NVD CVE feeds, Red Hat advisories,
data from github repositories of the open source libraries you use
and email messages from an internal google group.
You also think that it would be great to see relevant tweets easily but that would be too
maybe you can develop some code that will parse NVD feeds and
add CVE data to your JIRA workflows.
Even a single integration will require a significant amount of time and resources.
But for all others, everyone working on a security issue will
open a browser window and try to find relevant information manually.
- You will configure VulnIQ to collect data from the sources listed above
- You will add a custom panel to JIRA that calls VulnIQ REST APIs to query information.
Or you can simply add a link to your VulnIQ instance
where all users can access the same information
easily, without running manual searches in multiple applications.
Supported Input Data Formats
VulnIQ includes many data processors that can automatically download and process
certain data formats.
Even when running your private instance, all data will be updated automatically.
CVE : NVD CVE Feeds
Vendor feeds : With built-in connectors for
Oracle, Red Hat, Suse, Cisco and Microsoft CVRF feeds.
CWE, CAPEC, CPE, OVAL
Your own data sources/feeds compatible with any of the supported data types. For example if you have a
system that generates CVRF data then you can connect your own CVRF data source to VulnIQ.
VulnIQ can monitor an email address and process email messages.
Email messages will be indexed and correlated with other data.
For example when someone mentions a certain issue in a monitored
internal or external mailing list, the email message
will be added to VulnIQ data set.
Twitter : VulnIQ can monitor twitter accounts and link tweets
to other data. E.g if someone mentions CVE-2018-8589 in a tweet
then VulnIQ will list the tweet in the list of items related to CVE-2018-8589.
(The SaaS version uses Twitter's embed widget and will not provide full tweet texts in API
responses to avoid violating Twitter's terms.)
Git repositories :
VulnIQ can monitor git repositories and link commits to other data.
For example when someone mentions CVE-2018-8589 in a commit message
or source, VulnIQ will link the commit to the CVE entry.
: VulnIQ can fetch, index and generate screenshots of
URLs referenced from other data.
E.g CVE references, urls mentioned in twitter messages etc.
RSS Feeds: VulnIQ can automatically process RSS feeds and process content linked from
Security tool data such as scanner plugins, IPS rules and similar.
You can query and get all data using the API.
For example, https://vulniq.example.com/api/data/CVE-2018-6307/relations will return
a list of data correlated with CVE-2018-6307.
Similarly https://vulniq-local.com/api/data/CVE-2017-7865/tags will return tags
for this data(which actually returns 'buffer overflow', 'ffmpeg', 'heap'...).
API endpoints for generating data statistics are also available.
As the web UI is also built using the APIs, data for all charts available in the web UI
is generated by API endpoints.
For example https://vulniq.example.com/api/vulnerability/stats?groupBy=date&startDate=2019-01-01
will return the number of vulnerabilities created in January 2019, grouped by date.
will return the number of git commits created in January 2019, grouped by date.
All administrative functions such as creating or updating data sources can be performed
using the API.
The web UI also uses the same APIs.
Direct data store access
When running your private instances, as they will be your own servers/databases etc,
you can query data stores directly.
But this is not a recommended method as it may cause data integrity and performance problems.
Direct data store access should be considered only as a last resort.