Veracode Reviews

Provides static code analysis of the customers' applications from all industries. It includes any type of code and scripts, but mostly Java, .Net, C++, and C# environments.

The solution is a specialist in SAST that you can rely on. Code scanning is fast with current, updated algorithms.

Provides consistent evaluation and results without huge fluctuations in false positives or negatives. 

It should include more informational, low level, vulnerability summaries and groupings. Large related groups of low level vulnerabilities may amount to a design flaw or another avenue for attack.

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.

• The static scanning of the software is very important to us.
• The ability to set policy profiles that are specific to us. 
• The software composition analysis, to give us reports on known vulnerabilities from our third-party components.

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.

None.

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: 

1. That it is a cloud-based solution, which is very valuable to us, we don't need that hardware running our scans and hosting the environment to be scanned.
2. The technology, the static scanning versus dynamic scanning produces a much better result, a more accurate result.

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.

Certifying the application security of my SAS-based application code base.

It allows us to prove our security levels to vendors, and additionally helps us with our HIPAA security policies. Also, CA Veracode has provided AppSec best practices and guidance to our teams. Finally, it makes the IT Governance process of the sales cycle easier.

Static and dynamic scans of the code. It is part of our release cycle.

Mitigation review isn't always super easy.

No issues with stability.

No issues with scalability.

It is excellent.

Straightforward to set up, but the configuration of the rules engine is difficult and complicated.

It helps us get over the line for security when contracting with customers, and any help reducing security vulnerabilities is a big help to us.

Pricing/licensing is complicated.

Do your research, make sure you implement the tools you need.

I am very likely to recommend Veracode to a colleague.

We test each major release of our software using Veracode static and dynamic testing. We also do manual penetration testing annually.

Ensures our code and system are 100% compliant. In terms of APPSec best practices and guidance to our team, the Knowledgebase available on the Veracode system is a great resource for our developers.

For our customers, the added security assurance is a requirement.

• Ad-hoc scanning during the development cycle
• Reports for audits

In terms of integrating Veracode into our existing software development lifecycle, there are regular milestones in the SDLC to perform Veracode scans.

• Entering comments for internal tracking
• Entering a priority
• Reports that show the above

No issues with stability.

No issues with scalability.

Excellent.

We did use a previous solution. It didn't satisfy our needs technically, and the customer service and its cost were not satisfactory.

Easy.

We don't do a detailed enough analysis to reflect on any cost savings relating to code fixes made since we implemented Veracode.

Negotiate some, but their prices are reasonable.

HPE Fortify.

Have them guide you through your first scan - make sure to add hours to your initial contract for that.

I am very likely to recommend Veracode to colleagues.

Scanning for code security vulnerabilities within our company's products.

Made our company aware of any potential code security vulnerabilities. Also, customers can use our products knowing they are verified by top organizations as safe.

Informing me of application security vulnerabilities. Bamboo build-automation with Veracode API calls are used.

• The user interface could be more sleek.
• Some scanning requirements aren't flexible.
• Some features take some time for new users to understand (like what exactly "modules" are).

No issues with stability.

No issues with scalability.

Great.

Somewhat straightforward. There was a little confusion about "missing modules" that are third-party files that we couldn't upload because we don't actually have them. That really confused us, but the technical support resolved the confusion.

I can't report on any cost savings relating to code fixes since implementing Veracode in our development process, but it makes us feel more confident about our code, which is awesome.

We are satisfied.

None. We might look into Checkmarx.

I am very likely to recommend Veracode to colleagues. Veracode is great.

We use it to assess or do security inspections of our software that we produce or assemble. We have a very large portfolio of software across our enterprise. The Veracode system is a platform that scales with the dynamics of our organization. We have people that are in many locations, in the US and abroad. The fact that the Veracode platform is essentially a cloud-based platform, that makes it scalable.

We are able to create business policies, and the Veracode system allows us to enforce those policies. That's at the very high level.

We're looking at improving the overall security quality of our software. We use it as a platform to help enable that process. Veracode, in and of itself, is doing nothing but inspecting software. But, there are many other practices that are essential to onboard and embed into our development lifecycle. Veracode is simply the platform that lets us see how well the software is being engineered. Based on some of the findings, we make improvements in areas that need education.

It can't be boiled down to the one or two most important things. It's not Veracode by itself that's doing all of the stuff, there are a lot of tertiary activities that go into building better software. The Veracode system is used to help us validate the security quality of what we're producing. It helps us zero in on some of the things that we can do better. But that means we have to provide education to our developers and architects.

In some cases we use their APIs; they're not as rich as I would like. We have added Greenlight to the IDEs, where the Greenlight tool is compatible.

In terms of cost savings relating to code fixes since implementing Veracode, it would be difficult for me to give you some specifics. I'm not exposed to the cost of the iterations. Development teams have a budget for the year. There are features planned, there are releases planned. There are many other functions responsible for planning the releases. My job is to provide application security tools, so that they can incorporate the security practices that our company expects us all to adhere to. We know, anecdotally, that the time to write software, or scripts... You should write them securely, as opposed to having some additional testing development activities, and several other iterations downstream, because that would mean we're paying three, four, or five times for our resources to accomplish what they could perform correctly the first time, out of the gate.

In that sense, the Veracode system, since we've been using it, has helped us identify and code correct over 34,000 security weaknesses. That means there are 34,000 weaknesses and vulnerabilities that never made it into production. It's hard to quantify, if any of those had been exploited, what would have been the real cost to catch them. The only thing I could do is speculate on cost right now. But we do know that it's far better to embed security upstream in the development lifecycle, and produce software correctly the first time, rather than retroactively adding security remediations to the iterations that produce software for service packs and patch releases. Those are unplanned events and there are certainly costs associated with those unplanned events. But I don't have a number I could throw out there and tell you what it is.

I don't really look at Veracode as providing any best practices. It may have some educational aid embedded in the platform. I think the Veracode database of remediation guidance is somewhat vanilla. It's not contextual. I frankly don't rely on it to provide the kind of guidance developers need contextually. So, we augment education aids and remediation guidance with humans, security analysts. We also have other third-party solutions that really provide more contextual remediation guidance unique to the situations, as developers are trying to address them. We don't anticipate what their system is going to identify. But, based on what the system identifies, I would say it's 50/50, whether or not the scripted, plain vanilla, embedded guidance is really the right approach. It may or may not be, and I would say it's probably 50% accurate, but it's very vanilla.

In terms of benefits to our clients from using Veracode, that's like asking me: Am I really happy that my car stops when I press the brakes. I think most people would expect cars to have brakes, and the brakes to work. No more, no less. Software, to me, it's probably in the same wheelhouse, that people use software without thinking, "Is it really secure?" It's assumed, frankly. So I'm not so sure our customers consciously think about security as a benefit, unless they are breached or compromised. It's one of those things that's difficult to track, in terms of how customers are benefiting. We just know that through our efforts we're delivering high-quality software.

Maybe customers that are being independently assessed by third-party assessors - when those assessors have to do security inspections of the technologies that may be consumed by those institutions - if our software is deployed on-prem, we tend to believe that our software will have fewer weaknesses and vulnerabilities identified than, say, other technologies that are consumed on-prem. Only then, might it become apparent to the customer that they're working with a supplier of software that provides higher quality, relative to other suppliers.

The Static and Dynamic Analysis capabilities are very valuable to us. 

They've improved the speed of the inspection process.

I'd never want the inspection process to become something that's suspect. False positives would diminish confidence in the results; if we don't continue to focus on reducing false positives... that is number one.

The on-platform reporting needs to be opened up much more. We'd like to be able to look at the inspection data from a trending perspective in a much more open manner. I need to be able to sort and filter much more flexibly than I can today. I don't have the on-platform flexibility to sort and filter inspection data, and that's not good.

Another thing I need is continued support for the new languages today that are popular. Most of them are scripting languages more so than real, fourth-generation, commercial grade stuff; we're evolving. Most applications are using so much open-source that, quite frankly, it would be great to see Veracode, or anybody else, extend their platform to where they are able to help secure open-source platforms or repositories. Currently, I have to have another supplier in my tool chain and that means I have to extract data from different tool repositories to see one holistic picture of security quality, risks, and vulnerabilities. It would be great if I could see it all in one place, but I have to harvest the information from Veracode, harvest information from Rapid7, harvest information from Sonatype, just so that I can get a good, round perspective of where my first-party and third-party code, and the components in the dependent libraries, are in terms of weaknesses, risks, and vulnerabilities. That's a burdensome activity. 

If Veracode spent more time providing more plug-ins to other competitors' environments, or provided very open APIs so we could harvest data, bring it into one lens so that we can look at the security inspection data through one set of dashboards, it would provide a lot more value from a governance perspective. 

I hold Veracode in high regard. It's a good organization to work with, and it's a very conscientious organization. I'm always a recommender of the solution set.

To certify that we have valid code, and that the developers are working with valid structures and writing good code.

The coding standards in our development group have improved. When we scan our code - at the end of a build cycle we'll go through and scan our code - from those scans we've learned the patterns and techniques to make our code more secure. An example would be SQL injection. We have mitigated all the SQL injection in our applications.

That is now part of our software development life cycle, to do a static scan before we release to our client base. We mitigate what we have to.

I'm not aware of any cost savings relating to code fixes since implementing Veracode in our development process.

In terms of Veracode providing application security best practices and guidance to our development teams, once we scan the software and we have to go through a mitigation process, we make sure we implement that in the base standards. Once we mitigate a problem, we implement it back into the base to make sure the developers who are still developing code are not going to have the same issues that we just mitigated.

For our customers, they know that we go through another level of application security with our application, one our competitors don't use. They know our code meets a standard and that we implement the standard and the structures. That we have mitigated gives them a little bit of peace of mind that our code is valid, and that it's not going to hurt their infrastructure. 

We just use the static scan, it's all we got into as of now. We're happy with that, it seems to work very well for us.

Going through the mitigation is probably the hardest thing to do and that's still an ongoing process. If there is a code issue to mitigate, it sometimes takes a little bit longer than what you would think. It might not be anything that they're doing. It's just their engine is changing and our code is changing so we have two things moving. We get a good score one time, scan it again on a new release and the score drops because the engine is picking up more things. I don't know if they could do anything about that. It's just one of those things you might just have to live with.

No issues with stability.

No issues with scalability, we're good there.

They're very good. Anything that we've brought up to them, they've responded to us very quickly.

We used the built-in solution inside of Microsoft Visual Studio, and we switched because Veracode had more cohesive scanning abilities and found a lot more issues with our code, when we first scanned it.

It was pretty straightforward.

We get good value out of what we have right now.

We had a couple of products that we looked at, but went with Veracode.

I am highly likely to recommend Veracode to colleagues.

Make sure, once you scan and find issues with your code, that the developers know how to remediate those issues so they don't go through them again.

It's going to take some time to get through your first set of scans and mitigations. To fix your code is not straightforward. But once you do that and implement it back through your whole development cycle, they identify the issues and it's very easy to fix them, once you know and have gone through it once.

Security scanning.

It has caught lots of flaws that could have been exploited, like SQL injection flaws. It has also improved developer engagement with information security.

In terms of application security best practices and guidance to our teams, their engineering staff is really excellent. They provide our developers with suggestions and they take those to heart. They've learned from the recommended remediation strategies provided by the Veracode security engineers. That makes all of their future code better.

As for our customers, it lowers the risk for people visiting our site.

Catching coding flaws before they go live.

Regarding integrating Veracode into our software development lifecycle, we started out with it being used only as a web interface, and now developers are starting to use it right in their IDE on the desktop.

It's a pretty dynamic product. It's changing all the time and improving.

The scanning is a little slow, but other than that it's fine. It's usually when the binaries get up into the multi-hundred-megabyte size.

We haven't encountered any scalability issues with Veracode so far.

They're awesome. Their timeliness is acceptable, but their expertise is phenomenal.

Veracode is the first professional solution I've used. It was in place when I got to the company.

We just use it as a cloud service for third-party developers.

In terms of cost savings relating to code fixes since implementing Veracode in our development process, I can't really give hard numbers.

I'm not the pricing guy.

Licensing is pretty flexible. It's a little bit weird, it's by the size of the binary, which is a strange way to license a product. So far they've been pretty flexible about it.

I recommend it all the time.

It's an important aspect of a complete security program. Not necessarily this product, but source code, fraud detection.

I'd give it an eight out of 10 because it's pretty straightforward, but you still have to mostly wrap it with organizational policies that encourages its use. It's not a product - and I don't think it's really a product category - that sells itself to the end-user. They see benefits, but they do have to be convinced to use it.