Alert on New High Risk Vulnerability in InsightVM with Slack (Bug)

The version 2.0 of the workflow has a bug where it will fail if the CVE (such as several of the Google Chrome CVEs lately) does not actually have a defined severity score when first released. “Input” becomes blank in those instances, so it cannot process further.

My work around is, in the “Process Vulnerabilities” loop, step “Convert Severity to Float”, was to change the Input field to the following:

{{#if ["Get Vulnerability Content"].[content_result].[severity]}}
{{["Get Vulnerability Content"].[content_result].[severity]}}

Obviously, you would change your “default” score to whatever seems appropriate for the environment. Could even change that to the workflow parameter if so desired, under the assumption that if it doesn’t have a score yet, it’s to be considered “high risk.”

Other changes I made to my implementation of it included “threading” the results per asset, under a primary check which breaks the loop when the first high risk vulnerability is found, and filtering the rest of the workflow if there isn’t a chat-header timestamp value. I have the same type of error-handling in the initial Chatops step that creates the high vulnerability-per-asset thread.

(Edit) I also have a quick check to keep a blast of CVEs from taking too much processing time, which was to check if the severe or critical vulnerabilities are greater than zero. If they’re all low, it won’t process further. It also sets a max amount of high risk vulnerabilities to report, whichever is lesser, (severe+critical+1, or 50), and a max loop break at the start of the processing loop that reports there are more than 50 if necessary. When you have an asset with >100 results showing up at once, it can really take forever to send all of the alerts.


Thanks for the heads up, I am in the process of updating workflows now. I will make sure this gets added to the list and updated.

1 Like