Veracode Reviews

C++ financial application acting as hub for my academic accounting system.

Application, which my institution partially owns, was analyzed after just having compiled the code. This happens seldom in academic software.

It does software composition analysis, discovering open source software weaknesses.

I can have quick results by just uploading compiled components. It gives me an idea about the most important vulnerabilities and fast remediation tips.

• Dynamic analysis of on-premises applications using the Veracode proxy module.
• Static analysis of applications, on which I share property with third-parties.

• Management of false positives
• Agile best practices: Violation detection.
• Support for more programming languages, like SQL.
• Support for more frameworks for Java: .NET, Python, PHP, C, and C++.

It never crashes, as far as I know.

Since it is a SaaS solution, the performance is fine.

CA still has some difficulties integrating the Veracode team in their support services.

I used SonarQube. It lacks of real enterprise-wide security detection. I continue to use Fortify and AppScan, while I am using Veracode.

Setup is really simple, just use Jenkins, JIRA, Visual Studio, and Eclipse connectors for on-premise. The rest is online.

Since we are based in the UK, the original Veracode Team (not CA) was helping us directly during the setup, then trained us.

Given the following:

• Effectiveness of automatic detection of defects, taking into account bad fixes. 
• Effort to find and correct a defect during automatic detection.
• Effort to find and correct a defect during post release. 
• Effectiveness of testing. 
  

ROI expressed as project savings is 2.4% of the project cost.

Costs are reasonable. No special infrastructure is required and the license model is good.

I evaluated Kiuwan, Coverity, and Klocwork

I wish Veracode support had more SDLC integration tools.

We use this solution for Digital Health.

This solution has helped us in developing a secured product.

Veracode is fantastic! All of the features are valuable.

My experience with Veracode across the board every time, in all products, the technology, the product, the service, and the salespeople are fabulous. They are engaging.

I would suggest charging the developer for training, as it's not very expensive.

Only charge for developer training because it's a service you give now and they may need to be technical support. 

It costs them money to do that, but with the technology, an incremental user is negligible incremental costs, which doesn't really cost them. That's software economics.

I would like to see them only charge for developer training for the qualified startups and start charging for the licensing once the product goes into production, and available.

I have several years of experience working with Veracode.

When we used this solution a year ago, we used the most current version.

It's a stable solution. I would rate stability a ten out of ten.

It's a scalable product. My rating out of ten would be a ten, scalability-wise.

We have a software development manager and three other people who are using it.

Technical support is phenomenal. They are fabulous and very responsive, it's amazing.

Previously, I did not use another solution. Because I knew Veracode for many years, my approach with the company was that it was a startup and we need to do it securely. This is s why we went with Veracode.

The initial setup was straightforward. It was extremely easy and took only a few hours to deploy.

We have a team in-house to implement this solution.

The pricing for qualified startups such as Neo4j could be improved.

It allows startups to develop a secure product, but it takes time for startups to get money for the products. 

Veracode could provide the services, at a significantly lower price during that period with a condition that the moment that it becomes production, Veracode has to be paid.

If they would change that, it would be phenomenal for the entire industry and for them.

Licensing cost is on a yearly basis and there are no additional costs, the pricing is straightforward.

At the time that we used this solution, we were a startup, the software may not have been that complex. It's not like Oracle.

My advice to others who are interested in using this solution is to pay attention to the full instructions.

I would rate Veracode Developer Training a ten out of ten.

We use Veracode for static analysis of source code as well as some dynamic analysis.

It's valuable to any business that has software developers or that is producing software that consumers use. You have to do some type of application security testing before allowing consumers to use software. Otherwise, it's risky. You could be publishing software with certain security defects, which would open up your company to the likelihood of a class action lawsuit.

I don't have any examples of how it improved the way our company functions. However, I did use a lot of the findings to put pressure on our vendors to try to improve their security postures.

Veracode has helped with developer security training and helped build developer security skills. Developers who get the tickets can go into it and take a look at the remediation advice. They have a lot of published documentation about different types of security issues, documentation that developers can freely get into and read.

The integration with JIRA helps developers see the issues and respond to them.

The most valuable features are that you can do static analysis and dynamic analysis on a scheduled basis and that you can push the findings into JIRA.

Static Analysis Pipeline Scan was able to find security defects in the software we were sending its way. For both Android and iOS that worked very well. It did have a lot of false positives though, but at least we knew it was working. The speed of the pipeline scan was completely reasonable. I don't have any complaints about the time it took.

The efficiency of Veracode is fine when it comes to creating secure software, but it tends to raise a lot of false positives. It will tell you about a lot of issues that might be hard for an attacker to actually manipulate. Because of that it's very difficult, sometimes, to sort through all of the findings and figure out what you actually ought to pay attention to. Maybe calling them false positives isn't entirely accurate. There were a lot of things that it would raise that were accurate, but we just didn't consider them terribly important to address because it would be very hard for an attacker to actually use them to do anything bad. I think it frustrated the engineers at times. 

Also, the policies you have, where you can tune the findings you get, don't allow you not to file tickets about certain findings. It will always report the findings, even if you know you're not that concerned about a library writing to a system log, for example. It will keep raising them, even though you may have a ticket about it. The integration will keep updating the ticket every time the scan runs.

We couldn't make it stop. We tried tuning the policies. We had several meetings with the Veracode team to get their feedback on how we could tune the policies to quiet some of these things down and nothing ever resulted in that. Ultimately we couldn't stop some of these alerts from coming out.

Even stranger, for some of the issues raised, such as the ones that were in the vendor code base, we would put the status in Veracode that we communicated this to the vendor, but then, the next time the scan was run, it would find the same issue. One time it would respect that update and the next time, afterwards, it wouldn't respect it and it would generate the issue again. It was really weird. It was reopening the issues, even though they should have been in a "closed" state.

Another significant area for improvement is that their scanning had a lot of problems over this last year. One of the biggest problems was at first it wasn't able to read packaged Go. When I say packaged Go, I mean packaged the way the Go programming language says you're supposed to package Go to deploy the software, when you're using multiple build modules together to make an app. That's a totally normal thing to do, but Veracode was not able to dig into the packages and the sub-modules and scan all the code. It could only scan top-level code.

Once they fixed that problem, which took them until August, we found that it kept reporting that there were no problems at all in our Go code base. That was even scarier because it would usually give all these false positives on our other repositories. I had the application security engineer write a bunch of known defects into some Go code and push it in there and scan it, and it didn't raise anything with any of that. They're advertising that they have a Go scanner, but it doesn't actually function. If our company was going to continue in business, I would have asked them for a refund on the license for the Go scanner at our next renewal, but since we're going out of business, I'm not renewing.

I would also love to see them make it easier to debug the JIRA integration. Right now, all of the logs that are generated from the JIRA integration are only visible to the Veracode engineering team. If you need to debug this integration, you have to have a live meeting with them while they watch the debug messages. It's utterly ridiculous. Their employees are really nice, and I appreciate that they would go through this trouble with me, but I think it's terrible that we have to bother them to do that.

I have been using Veracode for about a year.

It's highly stable.

It scaled fine. We didn't have any problems with it not being available or going down during our scans. We have used it 100 percent, meaning we've taken advantage of every license we bought.

Their support was really good. I would give them a B+ and maybe an A-. The only thing that's really taking support down is the product itself. You and the support team are fighting against the product. The people at Veracode were great though.

We didn't have a previous solution. 

The initial setup was pretty complex. We had to integrate it with our CI/CD pipeline. This required writing custom code. Once it was integrated there, we had to have the development team make some changes to how they pushed a release to a special branch so it would go to Veracode on a weekly basis. And once it started raising the issues, we had to work on that JIRA-Veracode integration, which was not straightforward at all and required a lot of debugging help from the Veracode engineering team. They provided that and that was great, but ideally it would show you the error messages so that you don't need their help.

The initial deployment took about two or three weeks and then we had to come back and tune it several times, so there were another two to three weeks of tuning. Altogether, it was about six weeks of effort on our part.

Initially, we had one person working on the deployment, and then I started working on it as well. Later, there were four of us working with Veracode during these calls to try to do the policy tuning and figure out if we could make it work better for everyone.

We had six people using the solution: four software engineers and two security engineers.

I'm not sure if we have seen ROI. We didn't have any high-severity security defects being raised by Veracode, and that's just a function of the development team members we had. It helped in protecting ourselves from potential class action lawsuits.

The pricing is really fair compared to a lot of other tools on the market.

It's not like a typical SaaS offering. Let's say you got SaaS software from G Suite. You're going to get Google Docs and Google Drive and Google Sheets, etc. It's going to be the same for everybody. But in Veracode, it's not. You buy a license for specific kinds of scanners. I had two licenses for static analysis scanners and one license for a dynamic analysis scanner. 

I chose Veracode over others because it supported the programming languages we're using. It had the best language support. A lot of the other solutions might have supported one of the languages we're using, but not all of them.

My advice would be to definitely have some code that has a lot of security defects embedded into it and to run it through the scanner to test it early on in the process, ideally during the evaluation process. If your company works in five programming languages, you would want to create some code in each of those languages, code that has a lot of security defects, and then run the scanner over it to just make sure it can catch the security vulnerabilities you need it to catch and that it's consistent with how it raises those vulnerabilities.

Veracode provides guidance for fixing vulnerabilities but that doesn't enable developers to write secure code from the start. The way the product works is it scans code that has already been written and then raises issues about the security problems found in the code. That is the point at which the developer sees the issue and can look at the remediation advice Veracode gives, and the possible training. But it doesn't allow them to write secure code in the first place, unless they really remember everything. It does educate them about it, but it's usually after the fact.

The solution provides policy reporting for ensuring compliance with industry standards and regulation. While those features were not applicable to us, they were in there. I think they would be very useful for anyone working in a high-compliance industry.

It also provides visibility into application status across all testing types, including SAST, DAST, SCA, and manual penetration testing, in a centralized view. If you buy the SAST and DAST license, of course you'll see those scan results inside that view, but to see the pen testing that means you'd have to buy pen testing from them as well. Seeing those testing types in one view didn't really affect our AppSec. It's nice for the security team, but it's just not that important because they weren't in there everyday looking at it. Since we had the JIRA integration, the defects would flow into JIRA. The software engineers would take a look at it and categorize whether it was something they could fix or something that was in a vendor's library. The software engineers would prioritize the things that they could fix, and if it was in a vendor's library, I would batch those up and communicate them to the vendor.

Overall, I would grade Veracode as a "B" when it comes to its ability to prevent vulnerable code from going into production. It will find everything that's wrong, but it doesn't have enough tuning parameters to make it easier for organizations without compliance burdens to use it more effectively.

Overall, it's pretty solid. I would give it an eight out of 10.

We use it for static checking.

We are a state agency, we're not a private-sector company. What we're able to do is take our main web-based application, which is not only for internal use but which the citizens of Ohio also use, and we can run this application, and others as well, through Veracode to ensure that we've done our job, our due diligence.

We print out a report, we see the rating of the vulnerabilities that have been found: "critical" and "high", "moderate" and "low." We've been able to go from having critical vulnerabilities to where we're now into the more moderate range. We've shown improvement through the years. We can provide that information to our superiors, and to people who come in and audit us, to show that we've made progress on scanning.

When we find a vulnerability, we do pass it on to our developers and they've been able to go in and adjust the code so that the vulnerability is no longer there. The goal, of course, is that these findings will help them as they develop new code so that these vulnerabilities are not a part of the next application. We run a follow-up scan to make sure the vulnerability has been cleared.

The benefit, at this point, has been more internal than for our customers. Obviously we don't want them to have a problem so that they could then, theoretically, actually see the benefit. We try to be proactive.

• Having the option of static scanning. Most tools of this type are centered around dynamic scanning. Having a static scan is very important.
• Utilizing the software as a service. We do the scanning of the compiled code ourselves but it's on their servers, which is a plus.
• Technical support is available if needed and that is advantageous.
• Having online education and training is also advantageous. 

I attended a meeting of one of the security organizations I am associated with. At the meeting were security professionals from several major retail companies. The topic of discussion happened to be application development security. When the question was asked concerning what tools are being used, many of these major retail companies said they are using Veracode. However, they were quick to comment that the product is too expensive and that there are too many false positives which take too much time to remediate.

The stability is very good. They haven't had too many updates or upgrades. They did a major upgrade several years ago but it came out just fine. It has been a really good product.

I'd call us a "mid-range" agency, so it's not like we have a ton of applications that we're changing and updating. It's good for us, but I can't really answer how scalable it is because we're not really big.

I don't believe that the team has had any problem going on to the website, downloading the static code, or running scans. They do it quite often without any issue and are able to read the report and rectify whatever vulnerability has been discovered. There has not been a problem walking through those steps. It's been pretty straightforward. And if our team has any problems, we've got access to someone that we can schedule a call with to work out the issues.

We haven't had to call tech support too often, but when we have had to call them, support has been good in terms of resolution time.

I was involved, on a cursory level, with the setup. Our implementation strategy was to focus on our main web-based application. The way that they developed the application here was under one static set of code, so we could scan this code and, in essence, be able to check the vulnerability of most of the applications from the different business in our agency.

We did not use an integrator or a third-party. We did it with the help of Veracode.

We are a state agency, so we're not for profit. I tell everybody we don't make money, we spend money. To frame it in the context of the public sector, I think we are giving our citizens peace of mind. When they come in to write a permit, and we send them to a service that collects payment, that jumping-off point is secure and safe. It would be more in those terms, rather than the bottom line.

In the public sector, return on investment is not a term that is easily understood because we do not invest. But total cost of ownership is something that we can put our arms around. When we think about potential data breaches, Veracode has certainly helped us. When you think about the cost of the product and that I have one person, not ten people, running this tool, the total cost of ownership is low. I have no devices or servers, I didn't have to do any of that here onsite. It's all in the cloud. The total cost of ownership, given the services they provide, is very low, in my opinion.

We're always looking to save the taxpayers' money. I used to tell my vendors, sharpen those pencils and make the tip laser-sharp. When it can be, I want it to be less expensive, but you get what you pay for too. Vendors need to be fair and I think Veracode has been fair.

We use their SaaS solution and it's just an annual subscription.

The state of Ohio decided to bring AppScan in and that's an IBM tool. IBM became a major vendor in the state of Ohio. But what happened is that AppScan does not offer static code vulnerability checking; dynamic is something they do offer, but it's not as complete and comprehensive as a static scan is. Even the state has gone away from AppScan, but we were looking at it, we were starting to get set up for it. But evidently, other agencies haven't found it to be as useful. So we're not going that direction, we're staying with Veracode. 

There would have been cost savings associated with going with AppScan but we decided, because the state was not going that way, that we were not going that way either.

I would absolutely recommend Veracode. I've suggested to one of the larger agencies that they implement the solution and that they come to see what we've experienced and how we use the tool.

I really like Veracode. That is one of the reasons that we brought them onboard ten years ago. Of course, they were new back then. The different aspects of the offerings that Veracode provides to their customers are somewhat unique and, right now, I couldn't ask another thing from them.

We have approximately 30 Java developers and four or five testers. There are also project managers using it. We have one person who manages running of the scans and that person might have one or two other people to help.

We haven't really been utilizing it to its full potential. We probably utilize it once or twice per quarter. We are planning to increase the capacity that we've purchased. However, we're getting ready to elect a new governor in Ohio. With that election, things will change, according to his or her desires. Right now, we're in a holding pattern waiting for November to come and go.

In terms of integrating the solution into our existing software development lifecycle, because we started so long ago - before the software development lifecycle was fully implemented - we were doing Veracode testing just because it was a good idea. Then we actually developed a lifecycle. We got into scrums and it just naturally worked its way in, so when we actually hired a testing group, Veracode was already a part of the process.

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.

To have a third-party analyze our code and make recommendations from a security perspective.

We do not pass our release without performing a static and a dynamic scan, and mitigating the flaws identified.

In terms of how our customers have benefited from the added application security of our applications, they are aware of our development process and it makes them comfortable that we have implemented industry best practices.

All the features provided by Veracode are valuable.

We use Ruby on Rails and we still don't have any support for that from Veracode.

The static scans on Java lack microservices architecture scanning. We have developed an in-house pattern for this and the scans can't take care of it as a single entity.

No issues with stability.

No issues with scalability.

The support is good but has room for improvement. Issues don't get acknowledged quickly, repeated updating is required.

The cost savings are the efforts that it would take to do this at a stretch if this was not implemented early on in our development cycle.

I think licensing needs to be changed or updated so that it works with adjustments. Pricing is expensive compared to the amount of scanning we perform.

WhiteHat.

We have made process changes and improvements, although Veracode is not tightly integrated into our CI/CD platform yet.

I am very likely to recommend to colleauges that they work with CA Veracode.

I'm an automation practice leader and we are customers of Veracode.

The valuable features are the static analysis and the dynamic analysis. The security is also a good feature.

The solution has issues with scanning. It tries to decode the binaries that we are trying to scan. It decodes the binaries and then scans for the code. It scans for vulnerabilities but the code doesn't. They really need two different ways of scanning; one for static analysis and one for dynamic analysis, and they shouldn't decode the binaries for doing the security scanning. It's a challenge for us and doesn't work too well. 

As an additional feature I'd like to see third party vulnerability scanning as well as any container image scanning, interactive application security testing and IAS testing. Those are some of the features that Veracode needs to improve. Aside from that, the API integration is very challenging to integrate with the different tools. I think Veracode can do better in those areas.

I've been using this solution for four years. 

I haven't had any issues with the stability. 

The solution is scalable but if we scale too far then the performance is impacted. We have around 300 developers using Veracode. 

The technical support is good. Whenever we have any vulnerability issues, we can easily contact them and then have a triage with the technical support team.

The initial configurations were okay, but then the integration to the CI/CD pipeline was not so smooth. We had multiple rounds of calls with the Veracode engineers to get it up and running.

Veracode is very, very expensive, one of the most expensive security scanning tools available.
We pay an annual license fee that is over $1 million. 

For any company wanting to use Veracode and buying vendor binaries from third party vendors, it's important to get the legal and compliance clearance from the vendor as well. Some vendors have a policy that they're selling you the binary of a particular software but you're not supposed to decode it. Those are the general terms and conditions that every vendor gets you to sign but Veracode does decode and then scans for the vulnerabilities. It's a challenge for any company purchasing the solution from vendors.

I rate the solution six out of 10.

I'm a security practitioner and I use it for security and vulnerability scanning and assessments.

The main purpose of getting Veracode was to serve as a solution for scanning lines of code which was lacking in the organization. It has improved the quality of code being delivered for test and its vulnerability resolutions timeline has improved.

The static scan module is the most valuable. 

In the next release, I would like a proper way of packaging files for scanning and the packing of IOS apps and API Dynamic scan methodology. 

Also, there seem to be lots of false positives. This can be improved upon. 

I've been using Veracode for about six months.

The solution is stable.

It is scalable.

The technical support has been quite helpful. I had a consultation yesterday and it was straightforward and explanatory. They seem to be okay. The customer rep helped resolve the issues observed. Although there were issues encountered which were not answered, I was referred to the support option on Veracode. 

Positive

I've used quite a few other solutions including SonarQube which is similar to Veracode. The challenge with SonarQube was financial, it charges per line of code while Veracode charges per application.

Initially, the setup was complex for those who had not done solution integration. However, my team was able to pick up after the refresher course. 

We implemented the solution in-house.

We've just concluded the onboarding this year. I can see improvement, but I can't really equate it to a monetary value. This will be determined by the financial team. 

My advice to anyone considering Veracode will be to negotiate with the team directly and define what constitutes an additional application.  

We evaluated other options.

The process of packaging scannable modules is not straightforward.