In today’s digital landscape where cyber threats are constantly evolving, recurring vulnerability scanning is not only a best practice, but a strategic imperative with the aim of minimizing exposure to potential risks.
Regular vulnerability scanning helps identify weaknesses in systems, applications and infrastructures, allowing them to be addressed in a timely and strategic way before they can be exploited by malicious attackers. In this context, integrating the scanning process into your security routine is essential. This blog post focuses on application security testing using the Invicti software suite (which we’ve created an integration for) to support the already-built-in one for timely communication of findings through the Atlassian Jira ticket platform.
As briefly explained in Automate Business Processes with APIs: python-gvm, using the API provided by the services allows you to reach your goals with the additional power of programming language libraries, resulting in easier automation of processes, better optimization and fewer errors, thus increasing overall productivity.
At a high level, Invicti performs recursive web application penetration tests following six main steps:
Among the various integrations, one with Jira Service Management is supported as well. When configured properly, it creates issues for your tenant related to the project you specified in the configuration.
Given all this, why develop a custom integration to use Jira as the notification and management systems for any vulnerabilities found? The answer mainly concerns these three points:
We developed an integration that, by running according to a scheduler, manages to overcome the highlighted statements above, perfectly mapping our already-implemented vulnerability workflow.
The API documentation for the two sources can be found here for Invicti and here for Jira.
Our custom developed integration includes two modules, one for synchronization and one as a cleaning function.
After configuring the Jira integration and the notification item to trigger the configured integration, and launch a scan and once it’s completed, Invicti automatically creates Jira tickets for the tenant and project specified.
Then the two modules come into action, the synchronization one running once every day and the cleaning one running once a month.
The first module gets issues from the most recent scan, modifies the ticket titles by adding the target name, and changes the status in Vulnerable if not already done (i.e., if it’s related to a previously detected vulnerability) and if not in the Unmanageable or False Positive state. Running once a day, it also checks if the date of the last scan is today: if yes, a comment is added to notify the detection system and to update the ticket.
The second module closes out tickets to the Mitigated state if they have been in the Vulnerable state for two months (i.e. no updates have happened in the last two months).
Using this process we’ve managed to overcome the limit on Jira ticket title customization dynamically, and to map our already implemented Vulnerability Workflow, since the built-in integration using webhooks allows the reopen status to be only in the To Do or In Progress states. These features provided by Invicti are referred to at the time of publication of this article.
Looking at further development, we will add an additional check to the script that periodically runs in order to avoid running it if a scan is already in progress. Another feature concerns updating the ticket content for the same vulnerability if, for example, the mitigation version of a product changes as releases for the same product occur over time, while maintaining the history of notifications made in the ticket.
Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find cybersecurity issues interesting, maybe you could start in a cybersecurity or similar position here at Würth Phoenix.