Veracode Reviews

We use it for security scanning of SaaS and mobile software that we develop: one server-side and two mobile applications. Most customers require SAST and DAST scanning in order to purchase.

It gives us more confidence in the application security of the products we scan. We use it as part of our AppSec best practices. 

It has an easy-to-use interface.

We would like a way to mark entire modules as "safe." The lack of this feature hasn't stopped us previously, it just makes our task more tedious at times. That kind of feature would save us time.

We have never had any problems with the solution.

It has always worked for us, we haven't found any issues. There have been no problems with scanning small and large objects.

Technical support is excellent. It meets our needs.

We had no previous solution. Our choice of Veracode was due to Veracode being a customer and requiring that we use their tool to scan our solution.

The initial setup was straightforward. As it's a SaaS solution, it took no time to set up. But because I didn't take training, I spent a bit of time figuring out the product. No implementation (or strategy for implementation) was required, beyond some simple configuration settings.

No issues, the pricing seems reasonable.

We evaluated no other products for SAST when we started using Veracode. 

Be aware that the first run will find a lot of issues, many of which are not real issues; it will take time to understand that. Don't change object names as that will confuse it. Make sure you get development buy-in early.

We're looking to expand its use within the development organization and are looking into another license. Currently, we have four users of the solution, myself (security) and developers. The four of us also maintain it.

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.

Dynamic and static code analysis.

It has given us insight into the actual flaws that are out there, and the speed at which they're getting mitigated. Now, we're starting to see quantitative metrics to show the overall risk with code vulnerabilities. It has been very helpful in that it has exposed an area that we weren't digging into as much as we should have, before.

The developers' awareness of the security weaknesses within their code has also improved. They aren't just mitigating these issues, they are realizing these are, in fact, issues that have to be dealt with.

We are just starting to integrate Veracode into our software development lifecycle. We are reaching out to a few of our developers to begin project Greenlight. Specifically, right now what we're doing is integrating the static code analysis scans into our change approval. If you want to put a new piece of code live, you have to have a clean Veracode scan, whether it be through mitigation approval or through actually resolving issues. We've integrated it as part of our CAB process, and we're going to take that a step further and integrate it into the actual IDE for the developers.

In terms of security best practices and guidance to our dev teams, Veracode has been fantastic. The one thing we really liked about Veracode when we got it - and I think some other providers are doing it now - was the consultation calls; that our developers are able to schedule them on their own, instead of going to a "gatekeeper." They upload their code, they have questions, they schedule it, they speak with someone on the other side who is an expert, they can speak developer-to-developers. That is really good stuff.

Regarding our customers, I don't know if they have benefited per se, other than getting better, more secure applications. I don't know that our customers are necessarily looking for the most secure application, but it is something that I'm sure is on their mind, and they want to know that we're doing it. I would call it a tangential or unseen benefit. It is probably not in the top-10 things that they're looking for when they use one of our apps or our website. They are just assuming that a company such as ours is going to make sure that we have the appropriate security controls in place. So the way they benefit is that, hopefully, we're meeting that expectation, but I don't know that our customers are specifically looking for that as a decisive factor for using our websites or apps.

The reporting and mitigation features which allow our people to work on their own.

The only areas that I'm concerned with are some of the newer code libraries, things that we're starting to see people dabble with. They move quickly enough to get them into the Analysis Engine, so I wouldn't even say it is a complaint. It is probably the only thing I worry about: Occasionally hitting something that is built in some other obscure development model, where we either can't scan it or can't scan it very well.

I would also like to see some improvement in the speed. That is really the only complaint, but in all reality we have a massive Java application that needs to be scanned. Our developers are saying, "It takes 72 hours to scan it." That is probably the nature of the beast, and I'm actually pretty accepting of that timeframe, but since it's a complaint that I get, faster is always better. I don't necessarily think that the speed is bad as it is, just that faster would be better.

One to three years.

I don't think that we are even beginning to push the envelope of what the system is capable of. We haven't had any problems. I'd say we are probably on the lower end of usage, not only the number of scans but regarding the number of applications. I haven't seen any issues, but I also wouldn't expect to hit issues, given where we are.

The support team itself, or security program manager and a few others, have been fantastic. Most of the time, they're willing to move and work faster than we are actually capable of. They have been spot on in helping us get this thing rolling.

They are fantastic. They get the highest rating.

We used HP WebInspect, which is now under the Fortify umbrella. HP WebInspect was just terrible. Had we used the on-demand cloud piece - which is why I perhaps have to pull my comment back - maybe we would have had a different experience. But we had a WebInspect instance on a single server that was inside of our own data center. It was very, very kludgy, very slow, didn't work very well. We were hitting the required specs for it but we'd have a dynamic website scan, which should not have taken very long, taking a week. It not only should have been very close to the scanning engine, but had its own dedicated route for pieces that live in the cloud. It was bad, and it was slow, and their reporting was terrible. There was no real support for it. It was just very bad.

It was very easy. The cloud instance got turned on, we had a support rep dedicated to us to help us get up and running. It couldn't have been easier.

I can't think of any cost savings related to code fixes since implementing Veracode. We are mostly focused on using it for application security, which is a hard thing to quantify unless you have a major breach.

I think the pricing is in line with the rest of the tools. I think you get what you pay for. It is certainly not inexpensive, but the value proposition is there. There are certainly cheaper tools, but I don't think we'd be getting the support that we get with those, and that is what separates this product from the others.

Regarding licensing, pay very close attention to what applications you're going to need to do dynamic scanning for, versus static. Right now, the way the licensing is set up, if you don't have any static elements for a website, you can certainly avoid some costs by doing more dynamic licenses. You need to pay very close attention to that, because if you find out later that you have static code elements - like Java scripts, etc. - that you want to have scanned statically, having the two licenses bundled together will actually save you money. 

You really need to understand how your application is going to be delivered and not think of it just as, "This is a website and this is a mobile app," or "This is a website and this is a fat client." Often, with new frameworks, you have websites - especially with Java specifically, which is not even a new framework - running Java, but you also have things running in a local Java sandbox on the machine, or on a Java virtual machine. You really want to understand how that application is being delivered to the end-user, and not just think of it as applications on a box and websites.

My advice is what I mentioned in the pricing/licensing section above, you really need to understand what it is you are looking to do.

Also, take into account a data sensitivity for the applications. It's not "one policy fits all." I really like that Veracode allows me to set up specific policies that I can apply to applications. Understand which are your critical apps that deal with critical, very sensitive data, and then apply a more rigorous scan model to them, versus internal applications that perhaps don't deal with as much PII, with as much sensitive information, and aren't available to the outside world. Those might have a lower risk footprint. Understand that, so when your developers go in there you are not treating every single thing like it is a public-facing, client-data-gathering, credit-card-processing web app. That way your developers can prioritize what they need to work on, so that you are delivering the right metrics to your leadership.

You really need to understand that strategy going in, because the tool is not going to help you determine that. The tool is only going to help you scan.

The only reason I don't rate it a nine or a 10 out of 10 is because we haven't hit those scalability roadblocks yet. I know we might have some challenges in the future, but I would say eight out of 10 is an incredibly good score for a product like this. If you were just asking me about the support and the people behind it, I would rate that a nine or a 10. If you bundle it all together it's an eight.

I recommend Veracode to colleagues all the time.

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.

We used it for performing security checks. We have many Java applications and Android applications. Essentially it was used for checking the security validations for compliance purposes.

Technically there is nothing wrong with Veracode. The only issue that we have here is uploading the code, the process of actually uploading and getting our results back. All of that is a little cumbersome. 

Technically there is nothing wrong with Veracode. The only issue that we have is uploading the code, the process of actually uploading and getting our results back. All of that is a little cumbersome. 

One of the things that we have from a reporting point of view, is that we would love to see a graphical report. If you look through a report for something that has come back from Veracode, it takes a whole lot of time to just go through all the pages of the code to figure out exactly what it says. We know certain areas don’t have the greatest security features but those are usually minor and we don’t want to see those types of notifications. So we would like to see a kind of a graphical representation of the problem areas. I would like to know which file is the biggest source of issues for me so that I can focus on resolving the issue, as a project manager. With how it is now, I am able to do this but I have to take out the whole PDF file and extract it. It takes up a lot of my time. I would like to see better strategic reporting. It would be great to get better graphical reporting.

Stability is very good and there were no issues. I will give it five stars.

It's very good; really very good. I would strongly recommend that. Technically I would be expecting a double concept for Veracode. I would still say this is one of the best products ever on that website. I don't have any issues with the scalability. 

I had no technical issues at all.

The initial setup can be a little complex for people or for organizations that don't have technical skills. Another small thing is that you need to have one person who's fluent and technically knowledgeable to help during the upload process. But otherwise, it's pretty much straightforward. It's not an issue, it's perfect.

I would strongly recommend doing an internal analysis first, before setting it across to Veracode to proceed and to use it more as a final verification point. My point is that Veracode is very good, and I would strongly recommend it. I have seen other solutions on the market and that's why I say: don't waste your time on other products, just get Veracode.

I would rate it an eight out of ten. Not a ten because of the reporting issues I mentioned that I would like to see improved.

Scalability and its optimization of security inspections. At the end of the day, I like the fact that it is all prim. It does not require a lot of support on our side. We get the benefit of security inspections and it scales with our community, which is global. 

It has the ability to scale, and the fact that it doesn't produce a lot of false positives.

Number one, I need analytics, analytics, and more analytics. It is all about risk based management and better decision support, that is why. 

It is rock solid, we have used it now for seven years.

On a scale of one to 10, I would give it an eight. 

We had no previous solution. We didn't know we needed to invest in Veracode. It worked out that way through our evaluation process that it was the right solution for us.

I never give 10s. I would give it a nine. It does nearly everything, but penetration testing. It covers such a broad breadth of our portfolio. In our business, we have applications written in so many different languages. Finding something that can consistently scan and not generate false positives across the paradigm or the whole ecosystem of languages, that is impressive. It is speed of inspection, the accurateness of the inspection outcomes, and frankly, it has fairly good business analytics embedded on the platforms. So, it does a lot more for us than not.

We are using this solution for static analysis.

The main feature that I have found valuable is the solution's ability to find issues in static analysis. Additionally, there are plenty of useful tools.

The solution could improve the Dynamic Analysis Security Testing(DAST).

There could be better support for different languages. It is very difficult in some languages to prepare the solution for the static analysis and this procedure is really hard for a pipeline, such as GitHub. They should make it easy to scan projects for any language like they do in other vendors, such as Checkmarx.

We have found there are a lot of false positives and the severity rating we have been receiving has been different compared to other vendor's solutions. For example, in Veracode, we receive a rating of low but in others solutions, we receive a rating of high when doing the glitch analysis.

We have been using this solution for approximately six years.

We have not had much free expert support from the vendor. We have had to have a team of highly skilled individuals to make the solution work.

The initial setup is difficult. For example, in Android, if I need to scan an ordinary APK Android application, we need to generate the APK and when you are working in GitHub, you need to do a lot of work to make these combinations able to be scanned by Veracode.

We did the implementation ourselves.

I have previously evaluated Checkmarx.

The solution is good at finding issues and provide some very useful tools. I would advise those wanting to implement this solution to purchase professional support from the vendor. If you do not, you run the risk of having many problems such as the ones we have faced.

The DAST tool is very useful and is used in preproduction.  

I rate Veracode a six 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.