Application development and secure code development.
Application development and secure code development.
We do automated scanning, so we use it as part of our development cycle. We do both automated security scanning as well as our own automated testing. We run the two in parallel and treat both outputs of, let's say, a sales functionality test. A security vulnerability is just a defect that needs to be resolved before we release the product.
We do an automated upload to the Veracode platform for all of our applications - we have about 35 applications. For all of them, it's automatically done, pre-configured, pre-compiled, based on scripts that we worked out with Veracode. And then on a scheduled basis, the upload and scanning is done, in some cases, twice a month. In some of our applications, two to three times a week, we just constantly scan and look for exposures, and continue to feed that back to the development team and make sure that they don't release product that's not ready for market.
We have found that our developers have become a lot more knowledgeable about how to develop secure code, and that was very important to us. We also became more knowledgeable about vulnerabilities in the market, which are the most critical to address. You could say it helped us to apply the right investment in the right place.
In terms of best practices and guidance, we do quarterly reviews with Veracode, where they're analyzing our information alongside of us and providing feedback to our executive team to suggest strategic changes in certain approaches. We've also done benchmarks with them, where we've compared our maturity model to the industry's model, as far as security practices go and best practices for security and such. In some cases, we've made adjustments to improve, and in some cases we are confident we're ahead.
Regarding our customers, for one, they can move to market faster, we can move to production faster. Also, we discuss our security program and the software development life cycle with them in pre-sales discussions, post-sales discussions, implementation approaches. What it does is, it gives them the confidence to move ahead in a more direct fashion, with one less headache for them to worry about.
It's really hard to criticize something that has become somewhat seamless for us. If they wanted to expand their capabilities into other areas of security, that would be fine. They're a very knowledgeable group of people. We do meetings with them on a pretty regular basis. We gain insights from their perspectives.
To me, if they just broadened their footprint into the areas that their feet feel comfortable going into, we'd have no problem pursuing that.
No issues with stability.
Tech support is very effective. We can do online requests for read-outs with their tech support - but the more common support would be for security advisory, when we're looking at certain vulnerabilities that we're struggling with how to remediate. We can get online with one of their security engineers, and they provide advice to us some best practices on making the code changes to secure the system. They do a very good job of that.
Prior to working with Veracode, we used a self-applied application. That is, we had the solution on-premise, but just could never quite get the routine approach that we've developed with Veracode. The program management features that Veracode offers to help us get our program up and going, along with the low false-positive rates that their solution provides - versus what we had done in the past - gave us some immediate traction. I think that we were able to make progress in the first five or six months working with Veracode, that we had not made in four or five years with previous approaches.
It was a dynamic scanning solution but, again, it was on-premise. Veracode is a cloud-based platform, where they manage all the back-end, and they do a lot of analysis during the scans, and they do a lot of post-scan reconciliation, where the other solution was a good solution, but all of that work fell upon us to do for ourselves. Our focus is on developing features and functions for our application, and running an application security platform in-house is just not practical, just not our core competency.
It was straightforward. We went from signing a deal on December 30th, to performing that first scan on January 5th, to completing that scan and starting to remediate issues on about January 15th. And that is one of the fastest wrap-ups of any technology that I've been associated with.
By implementing Veracode in our development process, what we've done is cost avoidance, not necessarily savings. By getting ahead of it, and releasing product to the market that's more secure, we have very few, if any, reported issues by our customers. So we don't have to go and do a maintenance repair of those. That's an avoidance of cost.
It's a pretty accepted standard that if you release a vulnerability or a flaw into the market, it's going to cost you 10 times more to address it after the fact than if you prevent it. I'd say that that, plus the automation of the scanning, has also reduced the amount of capacity or full time equivalence we have to apply to repair and scan.
As I said, we have 35 applications, and instead of having 35 different people preparing their packages for upload and scan, it's automated. We don't have to spend money doing that as well.
So avoiding the cost of releasing vulnerabilities into the market that get caught by customers and reported back, is a big one; and then, reducing the investment of performing the continual scans.
We're very comfortable with their model. We think they're a good value.
We worked very closely with Veracode on understanding their license model, understanding what comprises the fee and what does not. With their assistance in design, we decomposed our application in a way where we are scanning a very significant amount of code without wasting their capacity and generating redundant reported issues. You scan in profiles, per se. And we work with them, in their offices, to design the most effective approach.
So the advice I would have for customers is, you can get up and live fast, but work closely with Veracode to refine the method you use for scanning and the way you compile the applications. There's a concept called entry-point scanning, and that's probably not used well by the rest of their customers. We see our licensing as a good value because we leverage it heavily. I'd say many customers might not quite go to that level. But that's their choice.
I'd rather not give out competitor names.
But the method we were using in the past was what is called dynamic scanning, or DAST. That required we have an environment that was up and running with the application, and then we could proceed to scan. You can see that if we have 35 applications, that means we've got 35 environments running our application internally, just for scanning purposes. That's a lot of hardware, whereas this methodology uses static scanning, where we upload the compiled code and we don't invest any hardware in doing that. The scanning capability not only does the scanning but contains the application code for us. There are a lot of complexities with trying to do a dynamic scan on-premise, versus a static scan on a platform.
You almost can't compare the two. False-positive rate in the dynamic scanning was very high - 30 percent, maybe - and the false-positive rate for the static scanning is very low - maybe two to four percent. That is a significant value, because you don't have to spend a lot of time sorting through reported issues to determine if they're valid or not. We're pretty well assured that as we start investigating one, it's more than likely valid. We don't have that doubt entering in.
It was a different approach. Two concepts:
We recommend Veracode to colleagues all the time.
I'd give the advice of not getting hung up on trying to compare the static scanning to the dynamic scanning, that's number one. Don't even compare them. If you're doing neither, do statics first. It'll get the majority of your exposures addressed. Then you come in, in a second round, and do dynamic. Dynamic really becomes more of a confirmation of security.
The other piece of advice I'd give is to "follow the directions." Make sure they understand how they're supposed to compile code. Take the advice of the program management team with their code, and follow their lead, and you'll come out in a very good position very quickly.
I'd give Veracode a 10 out of 10 because the rate at which we gained control of our security posture, from a development perspective, was fast. There is a lack of wasted time on our developer organization in chasing down erroneously reported vulnerabilities. The erroneous reported vulnerabilities is very low, and that means that our developer time is very effective as we investigate a reported issue. As I said, it's 96, 98 percent probability it is real. So our developers gain confidence and don't second-guess the results.
The level of detail that we are provided for a given vulnerability - the data path that it follows, the precision with which the justification is provided - is very high. Again, you're highly confident in the result. You are provided a tremendous amount of detail about the vulnerability it found. And the rate at which you can ramp up and be productive is very fast.