nVisium's Code Remediation Service
Three years ago, Jack (our CEO) and I sat at a local coffee shop and contemplated what was next for nVisium. We wanted to have a meaningful impact on our clients’ security programs. We wanted to equip our clients with services that made sure their security programs mitigated risk and demonstrated value.
When I joined nVisium, I had recently left my job working in one of, if not the largest Ruby on Rails “shops” in the US which also happened to be a Continuous Deployment (CD) environment. I was part of a two-person team assigned with keeping all of that code safe.
Just think about that for a second.
Dozens of business-critical applications, somewhere between twenty to forty changes pushed to production a day, and all of two people to manage everything. If you think this is abnormal, you’re probably right. But not for the reason you may think. We were lucky to have two people dedicated solely to code security. This is where the first challenge lies; there are rarely enough qualified people to find vulnerabilities, let alone track the resolutions for those found.
This leads me to our second challenge, the process of issue resolution. We used the same issue and project tracking software our developers used in order to assimilate to their flow. We automated the tracking and alerting process. We fostered relationships with the product managers responsible for assigning issues. I’d personally taken just about every reasonable step you could think of to speed up issue resolution.
These tactics were, at best, okay. The only thing that seemed to really help? Submitting code. Yes, submitting the actual code fixes.
The first time I did this, one of the developers told me, “I’ve never seen a security person do this, I wish everyone did it this way.” Well, from that point forward, we continued providing remediated code for vulnerabilities we needed fixed quickly.
And it worked. Resolution occurred in a MUCH more timely fashion.
The code developed by our security team was always tweaked by the developers in order for it to work more efficiently, but it gave those same developers a foundation. This, as it turned out, was critical. We focused on the fixes, not the vulnerabilities.
One might think that because we focused on solutions rather than demonstrating exploit steps or explaining business impact, this would lead to vulnerabilities being reintroduced and a whack-a-vuln scenario. Instead, sharing our code fixes with the developers became a form of training and issue prevention itself. Plus, we took it a step further and incorporated the discovered vulnerabilities into a periodic training regimen. This kept the training specific, actionable, and based in real-world lessons.
So as Jack and I sat in the coffee shop and pondered what we could do and what would be meaningful for our clients, we came back to this real-life experience of mine. In our opinion, it’s not enough to hand a report full of vulnerabilities to a client and just hope the organization understands the problem.
Not only do they need to understand the problem, they need to understand it well enough to prioritize and fix the problem. If that client is stuck with a pile of vulnerabilities, we should help the client remediate them.
This is why we built our Code Remediation offering. We knew that building this service wouldn’t be simple, and we knew the process would need to be refined. We also knew we would have to hire and train the right people.
We started with several handpicked clients. While we have since added to that client list, we have purposefully avoided performing this service for more than a few clients at one time.
We provided this service for the first time in July of 2013; and after two years of hard work, process refinement, training, and hiring, we are proud to announce that it is now available to a wider audience. If you are interested in learning more about our Code Remediation service, contact us (firstname.lastname@example.org) and we will be happy to speak with you.