CASE STUDY
Veracode: Developer Tools Integration
Designed for
01 –
Understanding the problem
“Platform” is Veracode’s flagship product that scans software applications for security vulnerabilities and generates reports. With countless new competitors entering the industry regularly, marketplace dominance is hard to sustain. For this reason we decided to integrate our applications into our customers’ chosen development tools more tightly.
One of the challenges we found was that there were over one hundred different applications customers were using to create and maintain their custom software code. Another hurdle was making the integration process so simple and intuitive that users could fine-tune their integration settings without having to read extensive documentation every time.
CONSTRAINTS
Rolling out integration capabilities for new applications on a monthly basis across a wide variety of UIs
Creating UIs that are intuitive enough that users can quickly remember how to configure them after extended periods of non-use.
PROJECT TIMELINE
An ongoing project with new applications added to the integrations collection on a monthly basis starting with a release of a plugin for the Eclipse IDE.
02 –
Taking The Right Approach
I set up a meeting with the product manager to better understand how our plugins for the various Java integrated development environments (IDEs) would be rolled out. We decided to first focus on Eclipse for two reasons: due to its popularity at the time; and because it was a standard tool in our own organization that we could use for testing.
Integrations rollout planning document
Eclipse plugin developer forum
I wanted to better understand the limitations of Eclipse plugins in order to best determine the extent to which I could change the UI for the plugin we were creating.
I visited Eclipse developer forums and tracked down a remote developer who specialized in creating Eclipse plugins.
I secured him on a retainer for our company so he could help us develop the plugin.
I conducted one-on-one interviews with developers I found online with the goal of better understanding how and when they fix flaws.
From this, I discovered that a developer could easily spend four hours on finding and fixing each security vulnerability in their code, and that many of them didn’t run security scans nearly enough.
I decided we wanted to have a passive mode for our plugins that would scan when the developer wasn’t interacting with their IDE for a few hours.
Interview with developer
My patent application for the code difference flaw scanner
Over the course of the one-on-one interviews with the developers, it quickly came apparent that there was an opportunity for a patentable idea. The idea was that we could allow the developers to run a vulnerability scan on just the code they had changed before checking the code back in. This would allow for an extremely quick scan on only the next parts of the code, as opposed to the whole application where it could take hours to scan.
The patent committee loved the idea and it was submitted to the patent office in 2017.
Working closely with the lead developer and members of the UX team, I helped validate and iterate the designs before handing them off for implementation.
Working with the lead developer to come up with solutions
Example venn for determining next steps and planning
Worked through next steps and how we were going to approach the next two IDEs, WebStorm, and Visual Studio Code with a similar approach.
Laid out how we would integrate our flaw scanner with Jira and other development tools to increase “stickiness” with our customers.
03 –
Final Results
The initial release of the integration tools was a huge success. They became the fastest-growing products by revenue the company had ever released over the first year in the marketplace. They were also given a major mention in the company’s annual shareholder meeting and conference.
The project is still ongoing and is a fundamental part of Veracode’s continued dominance in the application security sector.
I have applied for two patents based on my research, and one was formally submitted to the patent office. The first was for a code merge gate that would scan any code different from the trunk for security flaws before merge. The second proposal was for scanning applications as they were running, then comparing the results to prior running versions and checking for inconsistencies .
Veracode plugin for Eclipse
Final integrations overview
Integration dev ops pipeline illustration
Code diff scanning patent
Jira integration interface
Auto generated Jira ticket
