Veracode Reviews

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.

Security scanning of the applications, of software that my company built.

We have a large developer base at our company ranging in a variety of skills sets. Some are very security aware, others really don't have the knowledge. What Veracode provides is really good feedback on what vulnerabilities were found in their code: examples, definitions, ways to mitigate. One of the huge benefits we've seen is just a bigger security awareness within our development staff.

Further, with the tools that Veracode provides, they're actually able to comprehend what the vulnerability was and then resolve it. So a lot of knowledge has been grown as a result, around security, with our developers.

Veracode provides application security best practices and guides our security and development teams because most of the time, in the issues that it opens, it has lots of links and details in there. There are also regular emails and newsletters and they send out about trends. So, there's a fair amount of communication and there are also a lot of details within the issues that they find. There's always plenty of material that they link to in issues. They do a really good job of providing a lot of communication and detailed documentation around our application security tools.

Our customers have benefited in the fact that know that we put security right in front, as a priority. It's not an afterthought. They're a lot more aware that we're security conscientious, instead of just, "The software works, here you go."

We also have reports. Some of our customers have asked for various types of reporting and security related stuff. Now, we're also able to give them these reports, essentially from Veracode's scans of our software. So, we have a lot more documentation about it. Instead of answering one-off questionnaires from our clients, we actually have a canned report we can provide. Again, all this material, we didn't have a year ago. We were just ad hoc answering things and hoping that they didn't question it anymore, and we really didn't have any good evidence. They were just taking us at our word.

The most important one is the static scanning analysis, and the reason is that it can tell us vulnerability in that code, right before we go ahead and push something to production or provide something to a client.

We pair that with dynamic scanning, which actually hits our Web applications, to try to detect any well-known Web application vulnerabilities as well. It's really just a way for us to stay ahead of it and provide some assurances and security with the software that we deliver.

Also, Veracode has a nice API that they provide to allow for custom things to be built, or automation. We actually have integrated Veracode into our software development cycle using their API. We actually are able to automatically, every time a new build of a software is completed, submit that application, kick off a scan, and we get results in a much more automated fashion. So the API is a huge thing that we use from Veracode, in addition to those two types of scans.

In terms of integrating Veracode into our existing software development life cycle, we heavily use JIRA today for bug tracking issues, time management, and the like, for our development team. When those scans kick, Veracode integrates back into our JIRA and actually open tickets with the appropriate development teams. We can use that as a measurement of vulnerabilities opened, closed; we can tie them to releases. So, we get a whole lot more statistical information about security in our software products. That's really what we use in measuring there, the integration back to JIRA in issues found.

From a technical standpoint, I'm pretty happy with everything. The one thing I'd like to be able to do is schedule dynamic scans. Today we're kicking those off manually, but I believe that it's something have on their roadmap.

Other than that, I don't really get too involved in the cost sides of things that's in my job, I'm more of a technical focus, but I have heard from my manager and a couple other people that the solution is quite expensive. So that is possibly one factor that could turn somebody away from Veracode. But, like I said, I really don't know much more about that. Technically, I'm very impressed and happy with what they've had to offer.

I have not run into one issue with stability with it. I'm throwing stuff at it all day and I can't think of one time where I've had an issue with submitting a scan or getting a scan to complete. It's been pretty flawless.

The one thing we hit was some licensing limitation. Again, it went back to cost, I believe. We had to go back and change our licensing model with Veracode to be able to scan all the things that we wanted to. I think there was some confusion up front with their licensing or cost. 

Like I said, that's really the only area that I've heard some gripes about, but I'm far removed. I'm not sure if it was scalability or a licensing mishap, but we did have some issues early on, with the amount of things that we wanted to scan and what their limits were for us. But ever since whatever was straightened out there, I have not had an issue of scalability.

Initially, I had some questions back and forth and I was able to get everything resolved, mostly via email. Overall, I thought the response time was good, the answers were concise and accurate. Within 24 hours I was getting a response via email from their support. For what I needed to set up, I really thought their support was great and really sharp.

I don't work with the support that often, now that things are established. But to get off the ground running, they were extremely helpful.

We had never done anything like this in the past. This was the solution that we chose. We didn't really evaluate anything else. I know that my boss has been a fan of some CA products in the past and really recommended this one. I did some digging on it, from a technical standpoint, and I said I believed it would be able to scan all our stuff, support our platforms, the languages that we write our applications in, so that's how we landed on Veracode.

Without the API, it would have been extremely complex. It would have been very painful because it would have been a very manual process of submitting applications. 

I am fortunate enough that I have a pretty strong development background, so I do a lot of coding myself. For the person without development experience, using the API would have been very difficult. Where I work, we're a little unique in that sense.

But the rest of it, it's a cloud-based solution. I'm kicking off all my stuff over to Veracode and it's running in their environments and producing results. There's not a whole lot of setup besides that. It's not a big cost on an any infrastructure that we have to run or support. So, pretty painless really.

I wish I had some numbers - this is really not my area. I would assume that it's got to be a fair amount of cost savings, only because we're touching things earlier. We didn't have anything before. I don't have good stats to provide except for the fact that now we have something in our process, where before we didn't. Before, security things were only being addressed if somebody actually found something or, even worse, if a customer found something. We don't have a lot of historical data but it's got to be substantial.

I believe, from a technical standpoint, it's paying off for the rest of the organization. I think ethically it's the right thing to do. Educating our staff - I don't really know how you measure that in a dollar amount - but our developers are getting education and are becoming more aware of security in their software. Me being a technical guy, those two things are huge, and the dollars don't add up enough. I'm not sure how you would measure it.

It probably pays off more over time as well. We're still only a year into it. So we're still learning a lot ourselves.

If you're licensing, and you're looking at licensing models, you might want to ask Veracode about their microservice, depending on the company. If you are a microservice architecture, I would suggest asking them about their microservice pricing. I would suggest that you evaluate that with your code and their other licensing model, which is like a lump sum in size of artifacts, and just make sure that you price that out with them, because there might be some tradeoffs that can be made in price.

There were some, but we didn't get serious about them because they didn't have everything that we wanted.

I would advise that you figure out a way to integrate it into your software development lifecycle in a way that it's not intrusive to your developers. That was really something that I set out to do. I didn't want my developers to have to go into their code, and kick off scans, and upload their code. So, I would really suggest looking at your integrations, your JIRA, your Jenkins, all of your add-ons, and hopefully that fits into the SDLC process, and then automating via their API.

Essentially, what we were able to achieve is, my developers still live within JIRA and the issues get opened from Veracode into JIRA and they work on things that way. They can remediate it, kick it that way, and if they need to they can log into Veracode. But I'd suggest making the SDLC process integrated as much as you can to make it something that developers aren't having to spend a lot of time doing every day.

Overall, I would give Veracode a nine out of 10, just because nothing is perfect. But it does everything for us and it was so painless. I speak very highly of it for those reasons.

I would highly recommend CA Veracode. Every engineer that I've dealt with has been really sharp. The review process they have is really good and the knowledge they have has been tremendous. I really recommend working with them.

The primary use is as a static analysis tool. But we also use Greenlight and dynamic, and we're currently having a manual penetration test.

Firstly, it prevents me from putting out software that has security vulnerabilities, which is a big thing and can be one of the most important things. 

Also, we just finished a vendor due diligence with a very large company that wants to do business with us, and one of their security questions was "Do you do static analysis?" I was able to just send a very professionally done report. They know Veracode and they said, "Okay, great. This is terrific." 

That very reason is why, three years ago when I first got to this company, I said, "We have to get hooked up with Veracode right away, so it's not like an afterthought." Because I'd been in a situation where you do it after the fact and you end up with 3,000 errors, medium to critical errors.

It helps us put out better software more quickly, and gives me the piece of mind that we've done everything we can to prevent any security exploits.

It's something that our customers don't think about, and the benefit would be that as long as there are no data breaches, there's no hacking within our system, they get a non-functional benefit. We work with pharmacies and they just expect that the system is secure. I would view that as a benefit to them - maybe something that they don't think about - but nonetheless, it's there. 

Certainly it eases integration into our workflow. Veracode is part of our Jenkins build, so whenever we build our software, Jenkins will automatically submit the code bundle over to Veracode, which automatically kicks off the static analysis. It sends an email when it's done, and we look at the report.

Once it's set up - and it's pretty easy to set up - it pretty much just works and I don't really have to think about it, outside of whenever I get my emails to look at the reports.

It was a very easy integration that we did within the first week of going live with the software.

So ease of use, ease of integration.

The Web portal, at times, is not necessarily intuitive. I can get around when I want to but there are times when I have to email my account manager on: "Hey, where do I find this report?" Or "How do I do this?" They always respond with, "Here's how you do it." But that points to a somewhat non-intuitive portal. 

With that said, I hate when companies redo their portals all the time. So it's kind of a catch-22, but that would be my only critique.

It's always been pretty rock solid. 

No scalability issues that I'm aware of. 

Exceptional.

Veracode was really my first introduction to static code analysis. The way I came across it in my previous company was, they were going through security due diligence and we didn't have any code analysis software. The company, a very large health plan, said, "Here are three that we recommend." Veracode happened to have been one of them, along with HPE and another company, maybe it was IBM, I don't know. We took a look at all of them and we made a decision to go with Veracode.

It was easy. It's very straightforward. There's nothing complicated about it.

I haven't really thought about cost savings related to code fixes, since we implemented Veracode, other than: It's always easier and much cheaper to catch errors and fix them before you go to production, versus catching them while in production. Just like it's much easier to fix things before production, as opposed to having somebody hack your system and to find out that you have a cross-site script error.

But again, I've never quantified it in terms of whether it's saved me money. 

Just off the cuff, the cost of the license is small in comparison to the value it brings. I don't have to buy the software myself, I don't have to have specially trained security professionals that monitor this stuff. But I haven't really broken it down to quantify it into dollars, as such.

I think it's a great value. It's at a price point that a small company like mine can afford to use versus, if it was too exorbitant, I wouldn't be able to use this product.

About licensing, just go ahead and get them.

Get a license at the beginning of a project. Don't wait until the end, because you want to use the product throughout the entire software development lifecycle, not just at the end. You could be surprised, and not in a positive way, with all the vulnerabilities there are in your code.

When I was at the last company, I looked at HPE (now Micro Focus) Fortify vs Veracode and maybe IBM had a product, but they were overly complex and overly expensive. I remember talking to our Veracode account rep, who also was my account rep originally here at Focus Script, and she did a fabulous job of explaining it, doing a demo, showing how easy it was to use, and that's what sold me. Again, it was recommended from a very large health plan as one of the more reputable systems out there.

CA Veracode provides application security (AppSec) best practices and guidance to our teams in a couple ways. First of all, they have an e-learning module that has courses that we have required our developers to take. That's a best practice.

Secondly, when we do have errors, Veracode is always available, their consultants, to help us either mitigate the error, or provide technical assistance on pointing exactly where the problem is and how we could probably fix it. I'm always amazed at how knowledgeable they are. 

They also have what's called a Software Composition Analysis that can point out errors and fixes for third-party software frameworks, which is very nice. The list goes on... And again, having received, early on, education from them on how best to integrate this in the workflow, those are areas where we've relied on best practices from Veracode.

I'm in healthcare, and it's very important - and I'm sure in other industries just as well - but the stakes are very high. If we get hacked, if there's a data breach, it could put us out of business. It's a very good price point for a small company to have these kinds of capabilities, something we can afford for our application.

I am very likely to recommend it to colleagues. As I mentioned, I brought it to this company, and I've already recommended and provided references to a few other companies over the last couple of years.