The need to integrate security testing into the SDLC
Agile methodologies have become the norm in software development, allowing developers to release continuous incremental updates every 2–3 weeks. Unlike traditional waterfall models, this development process is a continuous cycle of planning, designing, developing, testing, and deployment. This leaves little to no time to order separate security testing, wait for the results, fix vulnerabilities, and retest.
Trying to combine agile development with a waterfall approach to security testing makes application security a major bottleneck. When vulnerabilities are identified, the entire streamlined process has to stop and wait until developers fix the issues. This halt causes delays in releasing new features and products, often costing the company money. The inefficiencies of bolt-on security testing can lead to security being regarded as a burden and extra cost rather than a critical asset.
Nevertheless, with data breaches and other cyberattacks now acknowledged as a major business risk, turning a blind eye to vulnerabilities is no longer a viable option. A critical vulnerability may let attackers siphon millions of dollars from a company, and such an attack can also lead to a legal investigation and result in loss of confidence among customers. As recent events have shown, cyberattacks can even have widespread economic and political consequences.
Approaches to building security into development
While code-level security testing based on static analysis (SAST) typically provides feedback directly in the developer’s IDE, delivering vulnerability reports from dynamic testing (DAST) is a bit more complicated. Developers organize their work using issue trackers, so any vulnerability that needs fixing must be turned into an actionable ticket in their existing system. If this is done manually by security engineers, managing vulnerability tickets (creating, assigning, monitoring, verifying fixes, reopening, closing, etc.) adds a lot of extra work for everyone. If tickets are created automatically, for example by a vulnerability scanner, you need two things: accurate results (so your developers are fixing real issues) and a way to integrate the scanner with the issue tracker.
For Invicti, this means integrating with a vast array of development and collaboration platforms out of the box and using Proof-Based Scanning to deliver accurate, detailed, automatically verified reports for the majority of direct-impact vulnerabilities. In the case of Jira, Invicti provides bidirectional (two-way) integration, meaning that it can both send vulnerability data to the tracker and receive developer feedback about the fixing process. This includes the option to automatically test fixes before closing a ticket and releasing code to staging or production. With minimal setup, you can embed vulnerability scanning into your Jira-based development pipeline to ensure that security issues are reported and fixed without delay.
Setting up Jira integration in Invicti Enterprise
Bidirectional integration lets your developers work on vulnerabilities reported by Invicti without leaving their familiar Jira environment. Setting this up consists of 3 simple steps:
- Integrate Invicti Enterprise with Jira
- Automate vulnerability export to Jira
- Register a webhook to synchronize the whole issue resolution process
When this is done, Invicti will automatically create Jira tickets for identified vulnerabilities (according to predefined vulnerability severities) and receive Jira notifications when developers change the status of these tickets. Let’s see how this works in practice.
Jira integration in action
To illustrate the process of reporting and remediating vulnerabilities, we set up Jira integration and ran a vulnerability scan on
php.testsparker.com – one of Invicti’s vulnerable test sites. Among other issues found during the scan, Invicti identified a programming error message vulnerability and automatically exported a Jira ticket for it. Here is the vulnerability as seen in Jira:
Once all the reported vulnerabilities have been triaged, the issue will be assigned to a specific developer, who can start fixing it. (Note that, depending on your workflow, it is also possible to automatically assign issues to specific users.) After fixing the vulnerability, the developer changes the ticket status to Done:
Thanks to bidirectional integration, Invicti Enterprise will be notified about the fix and will schedule an automatic rescan to test if the fix works:
If the vulnerability is still present after the rescan, the Jira ticket status will be changed to Reopen instead To Do or In Progress. If the vulnerability is not identified again, the Done status will remain.
For retesting, Invicti Enterprise will not run all security checks, just the security check needed to see whether the same vulnerability can be identified in the same place.
The benefits of 2-way issue tracker integration
Bidirectional integration between Invicti Enterprise and Jira is a vital part of building modern DAST into a Jira-based development workflow. Superficially, it may seem a minor convenience feature, but it actually provides major benefits that go far beyond improved ticket management.
Effective shifting left
2-way integration greatly helps with shifting security left into the development process. Security tests for new and updated features are now launched automatically to provide dynamic testing for websites and applications from the early stages of development. This not only improves security but also helps to minimize costs and delays – after all, the earlier vulnerabilities are found, the cheaper they are to fix. You can also release new features and applications on time without creating a bottleneck in late-stage security testing and provide immediate feedback to developers to help them build secure coding practices in the long run.
Faster vulnerability remediation
Invicti automatically creates a Jira ticket with all the information necessary for developers to deal with the vulnerabilities. For issues automatically confirmed with Proof-Based Scanning, developers don’t need to waste any time on double-checking vulnerabilities – they get proof of the vulnerability and can immediately deal with the issue. Invicti creates detailed tickets complete with details such as issue severity, attack payload, and remediation guidance. This can eliminate the need for any manual intervention to create the ticket, upload the necessary information, and track progress. All this translates into quicker and more effective fixes.
Better collaboration between security professionals and developers
Combined with automatic fix retesting, 2-way integration can also improve collaboration with the security team by removing the need to manually check if vulnerability fixes are valid. If Invicti finds that the vulnerability persists despite the fix, it will assign the issue back to the original developer. This closed-loop security testing process takes the burden of manual verification and ticket management off your security professionals so they can focus on analyzing more complex vulnerabilities and also act as trusted advisors on secure development practices.
Fixing vulnerabilities like any other bug
Thanks to automation and integration, Invicti perfectly fits into your software development life cycle and helps you find security issues early on in the process when they are cheaper to fix. Bidirectional integration with Jira streamlines bug fixing, saves time in dealing with vulnerabilities, and helps developers create more secure code. With Invicti and Jira, security issues can finally be reported and fixed like any other bug to improve security without complicating your workflows and introducing delays.
For detailed information about setting up Jira integration, see Integrating Invicti Enterprise with Jira.