23. 12. 2024 Beatrice Dall'Omo Red Team, SEC4U

Developing Integrations for Greater Efficiency: Jira and Invicti

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.

The Built-in Integration

At a high level, Invicti performs recursive web application penetration tests following six main steps:

  1. Discover and crawl: to gain complete visibility into all your applications and APIs
  2. Assess Risk: to prioritize testing with AI-backed risk predictions
  3. Detect: by combining DAST and IAST scanning, Invicti has more coverage of vulnerabilities, meaning less risk
  4. Resolve: Invicti allows you to fix vulnerabilities with less manual effort by reducing false positives with Proof-Based Scanning, as well as by providing detailed documentation
  5. Integrate: Invicti builds security into development by integrating security into the tools and workflows developers use daily (e.g., PingIdentity, Jira, AWS, GitHub, Slack …)
  6. Continuously Secure: to provide security with ongoing scanning and security checks with automatic notifications to keep your risk to a minimum

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:

  • Limits on the Jira ticket title customization
  • Mapped Jira ticket status cannot be customized
  • Both Invicti and Jira support APIs are well documented

API: Custom Developed Integration 

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. 

Fig. 1: 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.

Fig. 2: Notifications view on Invicti
Fig. 3: Integrations view on Invicti

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).

Conclusion and Possible Further Development

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.

These Solutions are Engineered by Humans

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.

Beatrice Dall'Omo

Beatrice Dall'Omo

Red Team & Offensive Security Specialist | Cybersecurity Team | Würth Phoenix

Author

Beatrice Dall'Omo

Red Team & Offensive Security Specialist | Cybersecurity Team | Würth Phoenix

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive