Veracode Reviews

We use Veracode for security scanning purposes, and our security services team has developed the logic. We create the pipeline and run the Veracode scan for particular microservices. My role is to run the Veracode pipeline and to see all the detailed reports. Once the scan is complete, I download the Veracode report and share it with developers.

We have multiple environments, and all entities use the solution. We have approximately 1000 users.

The best feature is definitely the detailed reports. It provides code-related queries in the order of high, medium, and low depending on what we need to do. Veracode is user-friendly as well.

It provides all the details to prevent vulnerable code from going into production. The Veracode scanning report shows where we need to create security and how to encrypt usernames, passwords, or other details. It's very helpful from an application security perspective.

With this solution, we have visibility into application status at every phase of development including static analysis, dynamic analysis, software composition analysis, and manual penetration test throughout our SDLC. It is helpful for our DevSecOps processes because we get all the details before going into production. We can then talk with the design team and developers to fix any issues before going live.

Veracode helped to improve our ability to fix flaws.

It also saved our developers' time by 50% to 60%. Before going live, we always integrate Veracode with our application's bill pipeline. Instead of resolving issues once it is live, we can fix them beforehand.

Searching for applications in Veracode is a little bit difficult. We have to minimize the length of an application's name to 47 characters. It would be good if this limit could be increased so that an application's name can be properly reflected in Veracode.

My organization has been using Veracode for four years, and I've been working with it for two years.

Veracode is a stable solution.

It is a scalable solution.

Veracode's technical support is good, and I'd rate them a nine on a scale from one to ten.

Overall, I'd give Veracode an eight out of ten.

I am a software engineer, and one of my clients needed Veracode for security requirements. We needed to send the code through some security tools to see if there are breaches or malicious code that could attack the company. In this case, the client used Veracode to scan third-party libraries from our application. Veracode was running on a private cloud using Azure. 

Veracode helped us prevent possible security breaches. The team can anticipate and correct issues earlier instead of waiting for someone to find the issue or discover it when your application is attacked. 

The report is good because it has lots of security information. It isn't related to the code itself, like the line of the code or the connected library that contains an issue. It's sometimes difficult to figure out how to solve that.

Veracode saves time in the development process because we can anticipate security issues in an application. On the other hand, from a software development perspective, it could be a technical increase in depth. After we develop a feature in the application and run Veracode, we might find some security issues we need to fix. 

For example, we spent a month building a feature on an application, but during this month, Veracode found a security issue in the third-party library we were using and reported it. If we had found the issue mid-development, we would need to rebuild the solution. Sometimes, it might increase the technical depth of the application because this type of security flaw was not found previously in our daily work. 

Veracode creates a list of issues. You can go through them one by one and click through to a new window with all the information about the issue discovered.

We waste a lot of time figuring out which results are false positives, and it has affected our trust in the tool. After we've spent time training and setting up the tool correctly, we need to scan our code and remove all the false positives. Finally, it's good enough to identify our security issues.

We get some false positives with JavaScript languages like React, TypeScript, and Angular. The problem is rooted in the build process of JavaScript, not the code we are using. This is something we spend lots of time trying to resolve. When we point to a specific library and review that on the code, we can see it is a part of the build that isn't going into production. It's only a part of the build because JavaScript has a different build process. 

This hasn't happened in .NET or C# because we use can all the libraries used when coding. In JavaScript, it's tough, and we spend tons of time trying to find the issue. However, it's not a problem because it's a pre-compiled language. This isn't unique to Veracode. Black Duck does the same thing.

Maybe Veracode could automatically detect the language type first and improve the way it scans JavaScript to reduce the false positive rate for this specific language. Also, in the reporting area, it could connect to the source code Veracode uses for the third-party library.

When Veracode finds security issues, it creates a report with the number and description of the issues. Sometimes, we are not able to connect that issue with the third-party library containing the code and applications the developers are building. The relationship between the flaw in the code and the third-party library could be more apparent because developers may not realize that the root cause is the library, not the code itself. 

The compliance features are good, but it's pretty picky in terms of what it considers a security issue. I and the other developers struggle to understand what is flagged as a security vulnerability. If you can see a security issue in there, you can see all the documentation, but it's difficult to relate that to the code to determine why the issue happened. It could be clearer how to find the issue in the structure of the code. 

I'm not using Veracode anymore, but I used it for eight months in the last year. 

Veracode is stable overall. When we start the process on the Veracode side, the report generates in less than a minute, and we can see the issues. I don't have any problems with stability.

I used a tool called Black Duck when I worked for another company two years ago. The client chose to use Veracode. It wasn't my option. 

We put Veracode in our pipeline, so the process runs automatically during development. It isn't something we can run manually. There are scripts that run when we start. There isn't any maintenance on the developer side. A designated team takes care of all this.

I don't think we've seen a return on this, but it's hard to calculate because you have to estimate the value of a breach that hasn't happened. This is the main benefit of using this tool. I don't know how to measure that.

I rate Veracode eight out of 10. It can help you improve your security by identifying and preventing issues faster. At the same time, you should know that using Veracode will lengthen the development process because the team needs to check and correct issues. It could increase your development costs. 

Using Veracode has challenged us to be more conscious of security. Sometimes, developers just want to build code. This tool allows you to check if the code or libraries are secure enough to add. 

The most valuable features of Veracode Static Analysis are its ability to work with GitLab and GitHub so that you can do the reviews and force the code.

I have been using Veracode Static Analysis for approximately five years.

The stability of Veracode Static Analysis is good.

I rate the stability of Veracode Static Analysis a nine out of ten.

We have approximately 900 people using the solution.

The solution is scalable, but there is a high cost attached to it.

I use SonarQube with Veracode Static Analysis.

The initial setup of Veracode Static Analysis was reasonably quick.

We did the deployment of the solution in-house.

The price of Veracode Static Analysis could improve.

Sometimes the model that Veracode pushes forward for you to use isn't beneficial. I advise companies to use SonarQube and Veracode together because we use SonarQube for all the individual developers to scan and do their checks and tasks before they do a full peer review to make sure that they have it clean and it's understood. We then use Veracode Static Analysis for repository control because you need fewer licenses. Veracode Static Analysis is expensive and this is why we split the two solutions.

There are extra costs per developer and it can get expensive quickly. They charge approximately $25 a month for each developer that uses it.

I rate the price of Veracode Static Analysis an eight out of ten.

I would advise people to use Veracode Static Analysis in the final levels of deployment. For example, when you used another tooling, such as SonarQube to do the initial tasks with the developers, then for peer reviews it is best to use Veracode Static Analysis for making sure that your repositories are controlled and managed properly.

I would always advise people to deploy at least two tools, one at a lower level to do the peer-to-peer that is cheaper, such as SonarQube because close to being free. Then use something, such as Veracode for the repository control and the management control of your data cubes.

No solution is a hundred percent perfect. I wouldn't rate any solution a 10 because they've all got faults. SonarQube might pick something up that Veracode Static Analysis doesn't and vice versa.

I rate Veracode Static Analysis a seven out of ten.

We're using Veracode Static Analysis for scanning security vulnerabilities.

Once the image is built in the container, we send it to Veracode Static Analysis for static analysis assessment, and the tool scans it. The tool then provides us with information on vulnerabilities in our code and the third parties, then provides recommendations on how to solve vulnerabilities, and that's helpful.

What I found most valuable in Veracode Static Analysis is that it categorizes security vulnerabilities. My company is mainly worried about security vulnerabilities, so it's beneficial that the tool identifies security-related vulnerabilities.

Veracode Static Analysis lacks penetration testing, so that's a concern. The tool is also unable to scan when it's a C or C++ model, so that's another area for improvement.

I've used Veracode Static Analysis for one and a half years, and I'm still using the tool.

I didn't find any stability issues with Veracode Static Analysis. It's a stable tool.

Veracode Static Analysis is a scalable solution. My company has between one hundred fifty to two hundred microservices, yet the tool can scan cost-efficiently without issues.

Veracode Static Analysis has good support. There's a channel where my team communicates with support, raises tickets, then support will give you a call, though there were a few times when support struggled on specific cases.

The IT team set up Veracode Static Analysis, but it's a bit complex.

We deployed Veracode Static Analysis in-house.

We have not reached the point where we see ROI from Veracode Static Analysis because we're still assessing it, but there are so many vulnerabilities. If we fix some of the high-priority vulnerabilities not reported by the customer, and zero them out or reduce them, then we see value from the tool. Those high-priority vulnerabilities are less than manageable because they have multiple levels or layers.

To my knowledge, licensing for Veracode Static Analysis is paid yearly by my company.

We compared Veracode Static Analysis with other vendors, including SonarQube, and went with Veracode because it had more value than others.

Twenty-five to thirty people from the development and QA teams use Veracode Static Analysis, but my company is still learning the best way to reduce the load. There's no plan to increase the tool's usage for now.

Based on my initial analysis, I'd recommend Veracode Static Analysis to anyone looking into implementing it, as it's a good tool.

My rating for Veracode Static Analysis is eight out of ten.

For every application we develop, we want both static and dynamic security scans done before deploying them.

The solution helps us to verify if our code is error-prone or has any OWASP security flaws. It has also reduced our scanning time, but it's difficult to say by how much.

Also, the scanning process helps a lot when it comes to improving standards and best practices. If we scan multiple times and we get the same warnings again and again, it helps us to identify that there's something we need to rectify, overall, in our standards and processes.

In addition, the solution has helped to increase our security and development teams' productivity.

On the whole, Veracode has improved the quality of our code and the end product. It has reduced our security debt by 40 or 50 percent. It helps protect our application from external attacks.

It scans for the OWASP top-10 security flaws at the dynamic level and, at the static level, it scans for all the warnings so that developers can fix the code before we go to UAT or the next phase.

It also gives us a centralized view of issues and that is important because security is key to any application. We want to identify the flaws as early as possible. The centralized view means that everybody can see the report and remediate accordingly.

I would like to see improvement on the analytics side, and in integrations with different tools.

Also, the dynamic scanning takes time.

We have been using Veracode for more than six years.

It's a stable product.

We have about 30 to 40 developers using the solution. We use it on a weekly basis but I can't comment on whether we will increase our use of it. That depends on our product.

Technical support is average. They take some time to respond.

Neutral

We didn't use anything prior to this.

The ROI for us is that it improves our code quality and helps remove security flaws. It is an essential tool.

It does root analysis, but fixing things is up to us. Also, it doesn't require much maintenance.

I would highly recommend it.

We use it for static scans. It is mandatory in our company for every sort of project.

Veracode provides the organization an understanding of security bugs and security holes in our software, finding out if the software is production-ready. It is used as gate management, so we can have a fast understanding if the software is suitable for deployment and production.

My job is to help projects by getting the data integrated in Veracode. I don't own the code or develop code. In this area, I am a little bit like an integration specialist.

We use Azure and AWS, though AWS is relatively fresh as we are now just starting to define guidelines and how the architecture will look. Eventually, within a half year to a year, we would like to have deployments there. I am not sure if dynamic scanning is possible in AWS Cloud. If so, that would be just great.

The possibility to integrate Azure is very valuable because you can have every build integrated into the content integration pipeline. So, you can have every build scanned and determine when a new bug was introduced. Thus, you can keep great track of your code's security.

You can easily integrate it with Azure DevOps. This is an added value because we work with Azure DevOps. Veracode is natively supported and we don't have to work with APIs.

Third-party library scanning would be very useful to have. When I was researching this a year ago, there was not a third-party library scan available. This would be a nice feature to have because we are now running through some assessments and finding out which tool can do it since this information needs to be captured. Since Veracode is a security solution, this should be related.

I would recommend that they keep working on the integrations. For Azure DevOps, the integration is great. I am not sure what the integration possibilities are for the Google platform or AWS, but I would suggest every other platform should have this easy and great integration. It takes a lot of time for companies, so this feature is a big plus.

I have been using it for about three years.

There have been no issues at all. There has been no downtime registered.

I worked with the technical support to integrate some things. One of our private cloud providers only had old routers. It was possible only to open network connections to IP addresses, while Veracode only provided the URL in their guide. So, I asked the technical support if it was possible to provide some fixed URLs that we could give our provider since it is unfortunately against the concept of the cloud to provide the IP addresses that work just for some time. The technical support's response was within a day, and it was prompt and clear. Also, all their reasoning made sense so the support was very good. I would rate the technical support as 10 out of 10.

Positive

We also use SonarCloud, which is a code quality tool. We use both of them because both these platforms are good in some areas. While the Veracode is very good at finding security-related issues, the SonarQube Sonar suite is very good at determining code quality. Also, when I was looking into the topic, the SonarQube team answered that there is no point for them to go further into code security since there are already great competitors who have years of experience and development behind them, specifically mentioning Veracode as masters in their field. That is the reason why we use both solutions: We benefit from using them both. These solutions compliment each other.

I evaluated WhiteSource Bolt specifically for third-party library scanning, but I did not have a lot of time to create a proper PoC. I had a call with WhiteSource and told them that I would like to do a PoC, but I was not very satisfied with their support. It was like, "Just try the free solution then contact us again." However, the free solution didn't provide me enough things to make a decision. So, I just put it off until sometime possibly in the future. If Veracode offered third-party scanning, then we wouldn't need WhiteSource Bolt at all.

If you have Azure DevOps and would like to understand your code and how secure it is, then there are not a lot of better options. Also, there are not many choices in this area at the moment.

Once your code is scanned by the static scan of Veracode, you get some evaluation scores based on some criteria. For the management, when it is above a certain number, it is fine, but when it is built below, then it is no-go for production. Even though there is a possibility to create a sandbox environment for projects, they don't get it. That is understandable to me. I try to explain to them that there are no issues if you are working in a development environment and you get difficult scans. It is fine then because you can create a sandbox environment, which will not screw up or make the production releases worse because it is in a separate bucket.

We are happy using the solution. I would rate it as nine out of 10.

Manual Penetration Testing is a security tool for static code scanning. It's still in testing, so the client has it in their commercial cloud. As soon as it's federally approved, they'll move it to the government cloud. That's supposed to happen any day now. I think their government cloud is AWS. I believe they're looking at the dynamic piece as well.

I don't have much experience with the solution yet. We're looking at integrating Manual Penetration Testing with JIRA and Bamboo and then building that into a CICD model, so the integration is the most valuable feature so far.

We're still trying to get things operationalized, piloted, and tested. I haven't heard about any problems so far. However, it would be great if Veracode automatically packaged stuff up for you. 

For example, it would be nice if the solution used AI or machine learning to detect what your code was by doing. It could perform the review and decide how to package up the software. You could run it and wouldn't need as much developer involvement.

We've had Veracode in place for about three or four months now.

I haven't heard anything negative about Veracode's performance, and we've had a hundred people test it at one time. We may get to a point where see some degradation, but we haven't yet. 

Manual Penetration Testing looks relatively scalable. We won't know those things until we get a critical mass of people testing all at the same time. We have around four teams that are scanning continuously, or on a fairly regular basis at this point. So.

I'm happy with Veracode's support. We're getting the help we need. I meet with them weekly, and they answer our questions.

We haven't worked with something like this before. This is the first time the organization has picked up this type of scanning solution.

Setting up Manual Penetration Testing wasn't complex. None of these solutions are complicated. You get it, set it up, and run it. It has been deployed. They're already scanning, and more developers are being onboarded. 

We followed the implementation strategy provided by Veracode. One person is probably enough to onboard people and set them up. We need one person to concentrate on the strategy and ensure the systems are set up correctly.

We deployed Manual Penetration Testing ourselves, but we have an arrangement with Veracode to provide the necessary professional services to support us. Consulting is part of the package they provide.

We used it to scan and detected a vulnerability, and they're trying to use it to identify how to fix the problem. That's the only example of an ROI we've got so far. 

I'm not familiar with the costs, but I believe it's around half a million. I'm not sure how it compares to the other solutions, but I assume they're all in the same ballpark. HCL might have been a little less expensive.

I think someone at my company was looking at SonarQube, but whoever did that didn't go forward with a commercial version. I don't know how it would've worked out, and I didn't look at it. There was a community version someone had for years, but it never got the traction. 

Then I looked at HCL, Synopsis, and Cast. Cast is deep but highly expensive. Those were the Cadillac solutions. We went with the SaaS because they did not have anything that was on-premThey wanted something that would be in the gov cloud that we fed ramped and low maintenance on our side. 

I rate Veracode Manual Penetration Testing nine out of 10 for support and ease of setup. If you're considering this solution, I suggest trying it out and taking the opportunity to learn and teach yourself. Take some classes or online training. I found the solution pretty straightforward, and I'm not terribly technical. 

When code is being developed by our developers, the testing team runs through the static code application scanning and takes a look at how it is working out.

There are multiple code check-ins happening. When check-ins occur, we want to make sure that anything that needs to be tested, whether in that particular unit, or whether in the end-to-end functionality, is scanned and that the code is certified as usable. That's the first step we do, and it's a very important one. The scanning process helps our security team and developers fix flaws in the code and increases our fix rate.

Veracode SCA also reduces scan times because it scans incrementally. There is an initial baseline when the code is being created, but it does any additional delta check-ins fast and gets us the information.

We have been able to handle the overall code review process faster, because of Veracode's static code analysis. For example, we were able to onboard around 120 applications in seven to 10 months.

Another benefit is that it helps reduce security debt. It becomes much easier to run through the overall code. We have predominantly used it for shift-left, testing code much earlier from a security standpoint. Compared to when we started versus now, we have done a phenomenal job. Year on year, our security debt has been continuously decreasing by 10 to 12 percent.

Veracode takes the burden out of manual code reviews, helping to create secure software. The Greenlight feature helps the developer, at his desktop, before his code is even checked in. He gets a good understanding of how things look from a security standpoint, meaning how secure his code is. It will mitigate a lot of basic vulnerabilities at the start. And then, during the source code analysis, once it has been checked in, we have seen a 30 to 40 percent reduction in dynamic vulnerability identification because of the static code analysis that precedes it. Our vulnerabilities are at the dynamic standpoint. It's one of our most important requirements because we want to make sure that we provide a secure product and services. It's of paramount importance.

And as an educated guess, it has increased security and development teams' productivity by 7 to 9 percent, and that's a month-on-month increase.

The main feature we have been using is the software composition analysis, which provides us with a scoring system in terms of version 3 of the CVS. A lot of vulnerabilities are typically detected, but, at the end of the day, we also want to check how well they are being targeted, based on the Common Vulnerability Scoring system. Not every vulnerability is high-severity, because some of them do have fixes. That particular feature is helpful for us.

It gives you JSON output. When you do agent-based scans, at any point in time, there are multiple check-ins of the code. We have to look at it from the perspectives of how important it is to fix something and when it should be prioritized for fixing. The JSON output from the agent-based scans gives us the CVS core, and that makes things much easier. It's available on the new version of the Veracode SCA agent.

It also has a decent support system for audits. From that perspective, they did a very good job.

The mitigation recommendations are the standard ones, but if there are specific activities that come into the picture, Veracode should provide more remediation solutions. Since all of our team members are pretty good at what they do, they're able to do a good job with the information they get. But if somebody had to start off from the ground floor, they might need some help to understand things.

Veracode doesn't really help you so much when it comes to fixing things. It is able to find our vulnerabilities but the remediation activities it does provide are not a straight out-of-the-box kind of model. We need to work on remediation and not completely rely on Veracode.

Also, there are certain third-party libraries that might be called up by the code and that might have vulnerabilities. I haven't seen that Veracode is able to deal with that aspect. 

Another area for improvement is when the code's logic might have certain flaws that can result in a security vulnerability. Veracode doesn't handle that as well. Improvement in those areas would help us determine things much faster.

I've been using Veracode Software Composition Analysis for about five years.

It's pretty robust.

The scalability is very good. 

Our users are developers and security testers, predominantly. The number of people using it depends on the project. Sometimes we have 10 people on it and at other times we might have only five.

The teams that work on it take care of maintenance, so we do not need any additional team to do that. We also have a center of excellence that takes care of things.

The solution's technical support is good.

Positive

We did not have a previous solution.

The process of setting it up was fast and easy. Integrating it into our ecosystem was much faster than expected. That was one of the biggest ways it improved our ability to get the code analysis done. 

The reason why it was straightforward is that everybody knows how it has to be set up. All the developers and the testers are well-educated, from a Veracode standpoint, because they have experience with it from the past. It was not a new tool on the block.

The cost has been an important aspect for us, but we have run with the additional cost of the overall code analysis. One of the major reasons is that developers get a better understanding of where their code stands before a security tester gets into the picture. The cost-benefit for us is that, rather than having to build up a whole security testing team, developers get security insights earlier in the development lifecycle. After that, we can introduce the testers to get things finished, and that reduces the manpower cost.

Compared to the typical software composition analysis solutions, Veracode is not so costly, although the static analysis part of it is a little costlier. It depends upon the ecosystem you are using, whether your application is a web application or a custom, non-web application. It can support all of them. The pricing depends where you are at with your overall security strategy.

If you have multiple applications and you want to scale it at an enterprise level, this is a good tool. But a very small shop might not want to go with it because there are a bunch of alternatives that work well. Again, it depends upon where you are at on your overall software AppSec journey.

In terms of security breaches, the static code analysis is what we use to try to ensure that an application is free of vulnerabilities. But when you deploy it in the environment, there are multiple aspects that might contribute to a breach. It could be either due to the infrastructure or another application or even through endpoint network solutions. So, we cannot completely rely on Veracode to prevent security breaches but it can reduce them.

Veracode SCA reviews the code and allows us to provide overall information in terms of vulnerabilities. It does a pretty decent job. We are used to Veracode, having used it for a long time. Compared to when we started, all the developers are comparatively more confident and happy with it.

Every build running CI/CD on our applications, like Bamboo or Azure DevOps, will be scanned through Veracode SCA first. If its report for the build has a vulnerability or redundancy that is outdated or vulnerable, then that is our use case for our application. We have a lot of applications that need to automate these things, then get the report to the application team. Therefore, the security team needs to check these one by one.

We have a lot of people using Veracode, like the security team and DevOp. Also, the application team checks the Veracode result and updates it necessarily. Since it is integrated into our applications, there are a lot of users.

Our deployment model is on-prem. We deploy it as a JAR file inside our Cloud CMS.

We are using it to fix flaws in the code. Sometimes, we have reports that need to be checked. If it is a false positive, then we need to submit the false positive. However, if it is positive, then we need to fix it and perform a new scan to make sure the vulnerability has been fixed on the latest report.

After scanning, we receive report slides from Veracode. Their reports can help us to see the CVEs that we haven't even heard of and best practices that we can do, e.g., using logging properly, which is helpful. It helps us 50% of the time.

It has increased our security productivity by approximately 30%. It has reduced our development productivity by a bit less, since it sometimes breaks a lot of modules.

Veracode SCA helps us know about vulnerabilities before they go into our environment. This is one of its best benefits.

The most valuable feature is the security and vulnerability part of the solution. It shows medium to high vulnerabilities so we can find them, then upgrade our model before it is too late. It is useful because it automates security. Also, it makes things more efficient. So, there is no need for the security team to scan every time. The application team can update it whenever possible in development. Because we are using the Azure methodology, this helps us make sure that the application team can do it using the proper Azure method. For example, when we are using scrum, the application team can improve this Veracode scan on this scrum methodology. Therefore, if they were going to create a pull request, it would be detected. It would be scanned first before it goes to production or another environment, then they can fix it so we can do development more rapidly.

Our fix rate has increased by 15%. We know that we can update something now or put it in our roadmap to update later on in our application.

The mitigation recommendations are sometimes helpful. Sometimes, they are outdated. Sometimes, there are a lot of false positives inside Veracode. That is something that I already suggested to the Veracode team.

It could have better integration with our pipeline. If we could have better integration with our application pipeline, e.g., Jira, Bamboo, or Azure DevOps, then that will be very helpful. Right now, it is quite hard to integrate the solution into our existing pipeline.

If it has better integration with our DevOps pipeline, then we would use it more. However, at the moment, if the solution can be used for a new project, then we can integrate it. However, if that takes too long, we will integrate other things that are faster.

We have been using the solution for two years and a few months.

The biggest problem is with the false positives. However, it is quite stable for scanning compared to some other applications. That is why we are still using it.

At the moment, it is hard to implement on our pipeline. Therefore, we need better scalability, as it is quite hard to scale it to bigger projects because then the scanning will take a lot more time.

Their technical support is helpful. If we send a message to them, then they respond within the SLA. I would rate the customer service as eight out of 10.

Positive

While Veracode SCA may take some time to scan, it helps to reduce the number of scans that we need to do. Before, we needed to scan manually multiple times. Whereas, with SCA, we can just check one by one, then send it as a batch and scan it again. We used to scan 10 times or so. With this automated system, we now scan on average five or six times.

I know how hard it was for our DevOps to set it up.

The deployment process is different for each application. There are a lot of different things that we need to set for this solution. If we have a standardized system, not only using JAR but also other things, then that would be very helpful and make it easier for us to integrate. Currently, there is a lot of preparation that goes into setting up Veracode for integration with our existing applications.

Depending on the pipeline, it takes about five working days to deploy.

On our team, the solution has been very helpful. For more than two years, it has helped us get a lot of things on our application. It is easier for us to do fixes instead of just doing a pen test every time, then getting everyone to check it. 

It has good, fair licensing. If the price could depend on the scope of its scanning or the languages supported, then that would be better.

It is quite important to have fixed or static costs because it is easier for our financing.

Compared to other solutions, Veracode is more expensive but offers a lot for free.

We also evaluated SonarQube and Snyk in PoCs. We thought SonarQube and Veracode were good. 

We went with Veracode because its processes are very detailed and it supports a lot of languages. Though, compared to other solutions, it is difficult to integrate into the pipeline and can improve on its false positives.

Try all of the features. Make sure that you use the Veracode SCA with different languages since we can see differences between scanning Java, Node.js, or PHP.

For our site, we only use SAST and DAST for penetration testing. Also, the penetration testing for SCA is handled by another vendor since we have a different vendor for this usage. 

It helps indirectly with Webex.

I would rate the solution as eight out of 10.

My company produces a SaaS application that is used by very large customers for pricing analytics and sales workflows. The data that our customers put into our software is very sensitive and confidential. This means that they want a high degree of confidence that our solution is secure.

We use Veracode as one of the pillars that we can point to as helping us to deliver on the promise of having a secure product. We have a multi-dimensional security program and Veracode is one important aspect of that.

Veracode provides guidance for fixing vulnerabilities. It provides guidance to help us understand what it flags, and what we can do about it. It still takes some interpretation and insight on our side, but we aren't generally security experts, so we get good information from Veracode to help inform us.

The developers are able to understand the types of issues Veracode looks for, and then as they see that happen, it helps them to learn. It's good because they consider it the next time and hopefully, we don't need Veracode to flag the issue because there is no issue.

With respect to efficiency when it comes to creating secure software, Veracode is able to help us with very low overhead. There's not a lot of work needed on our side unnecessarily. Once we've wired everything together, it's seamless to get the scan done and get the results back and know what we need to do about them.

We use Veracode for some of our older, more monolithic software, as well as for our newer solutions, which are designed to be cloud-native. We've found Veracode useful in both use cases; first, with our huge monolithic software, as well as with our microservices cloud-native solutions.

In terms of AppSec, there are a lot of benefits that cloud-native design brings in terms of not only cost and scalability, but testability and security. Certainly, the design patterns of cloud-native are well aligned with delivering good security practices. Working with products that support cloud-native solutions is an important part of our evolution.

Using Veracode has helped with developer security training and skill-building. It's definitely a good way to create awareness and to deliver information that's meaningful and in context. It's not abstract or theoretical. It's the code that they've written yesterday that they're getting feedback on, and it is a pretty ideal way to learn and improve.

The static scan capability is very powerful. It's very good in terms of the signal-to-noise ratio. The findings that we get are meaningful, or at least understandable, and there's not a bunch of junk that some other code scanning tools can sometimes produce. Having results like that make it hard to find the valuable bits. Veracode is highly effective at finding meaningful issues.

The speed of the static scan is okay. It meets or exceeds our expectations. For our monolithic application, which is a million lines of code, it takes a while to scan, but that's totally understandable. If it could be done magically in five minutes, I wouldn't say that's bad. Overall, it's very reasonable and appropriate.

Veracode has policy reporting features for ensuring compliance with industry standards and regulations. We have one such policy configured and it's helpful to highlight high-priority areas. We can address and help focus our effects, which ensures that we're spending our time in the best way possible for security movement. The policy is a good structure to guide results over time.

We use Veracode as one metric that we track internally. It gives us information in terms of knowing that we are resolving issues and not introducing issues. I cannot estimate metrics such as, for example, Veracode has made us 10% more secure. I can certainly say it's very important when we talk to our customers about the steps we follow. We do external pen tests, we do web app pen tests, and we also use Veracode. It's certainly very helpful in those conversations, where we can state that it is one of our security practices, but there's no outcome-based quantitative statistic that I can point to.

The static scan is the feature that we use the most, as it gives us insight into our source code. We have it integrated with our continuous integration, continuous delivery system, so we can get insight quickly. We're doing scans daily, so that's the most important feature for us.

The interface is great. It allows us to look at our different applications, understand all of the different types of scans, as well as the results. The types of testing include SAST, DAST, and SCA, and it pulls all of the information together into a single view. It also produces reports that we can give to our customers when requested.

Veracode certainly provides a quick and intuitive way to understand the results, to see the context of them, and to identify what we need to do to address them. In general, it's a pretty quick way to get the information that we need in the most useful way possible. Then, we can turn around an action plan.

We have it integrated with our build pipeline and that works well. It's very important because we don't have to complete a separate, manual step of sending the software up to Veracode to scan it and get the results. It's great. the more things that we can integrate into the build pipeline, the better. It's a very positive thing.

Veracode is very good in terms of not having a lot of false positives. It would be very frustrating if a tool gave you 10 good results but 50 false positives. Even with the issues that we get that we choose not to address, we can still understand why they're being flagged. We have found that the results are meaningful and accurate, which gives us confidence in the solution when fixing vulnerabilities. 

We may choose not to address them for different reasons. For example, it could be because it's an issue about input sanitization, but we have another layer on top of that component to handle that task. We can recognize that it's important that Veracode is flagging those things at that lower level, and that they're bringing that additional insight and consideration to the designs that we're choosing. Overwhelmingly, even the issues we choose not to address are still valuable and meaningful, so the actual false positive rate is quite low.

This is a very useful and powerful tool that ensures our code is well-designed and correctly implemented. It is important that it's only one aspect of a security program and not the only insight or the only test. That said, it provides us with some pretty important feedback and insights that we wouldn't have a great way to get otherwise.

The ideal situation in terms of putting the results in front of the developers would be with Veracode integration into the developer environment (IDE). They do have a plugin, which we've used in the past, but we were not as positive about it. The pricing model was expensive and the results were not the same as the full solution analysis. It gives a differently scoped "just in time" analysis within the context of the IDE, so it didn't speak to the same problem space.

The best situation would be the one where the developers don't even need to log into the web portal, and the results from the scans would be delivered into their IDEs. It would be an asynchronous job, but if they could see the results right there, while they're working on the code, then they wouldn't need to go to a separate tool to look at the information to figure out what to do next.

The workflow today on the build side is optimal, so imagine that's still doing the same thing but then in the backend, whenever a developer has that project open in the browser, if they chose to, they could enable a view to see the most recent Veracode results of that module. That scan might be from last night or six hours ago or any other point, and that's fine. It would be the best possible situation to put the results and the actions right in front of the developer, in the tool that they're already using when they're touching the code.

The only other thing that we've found a reasonable workaround with is how to work with microservices in the context of Veracode. This was necessary because Veracode's licensing model and the interaction model are built around an idea of an application. When you're talking about a section of business logic that's being delivered by possibly dozens of microservices, there is some friction with Veracode in terms of how that application gets defined and how the scans occur and get reported on.

When we reached out to Veracode about this, I got a slide deck that provided us with different options of how they recommend proceeding in this context. It was helpful, and clearly a question they've considered and they had answers ready to go on. The ideas helped us and essentially reinforced what we were already thinking. It's getting the job done, but it still feels like a little bit of a square peg in a round hole and it could be a little smoother in terms of that interaction.

The problem boils down to how we fit the microservices architecture into the Veracode notion of an application. We need to be able to get a holistic view across the microservices, which is extremely challenging, especially when those microservices are owned by different teams who have different needs to see and respond to the scans. 

I have been using Veracode for between five and six years.

The stability is great. They've probably had some downtime, but I don't know about them. From our perspective, it's been solid.

I know the web portal has some planned downtimes because I see the splash screens about them. They're good about warning you, but they're also performed at very weird times, like the middle of the night, so it's never blocked me from getting in when I need to get in.

We use Veracode for all of our software development. We have more than 100 engineers, and our entire engineering team is using it. Obviously, every team has some designated people who look at this more than others, so not everybody's in there every day, but in terms of the software we write, we know that it's all being scanned constantly.

Over the last few years, we've made a couple of acquisitions of other companies and when we've done that, we very quickly brought those solutions in as well. We've seen the value and because of that, it's part of our onboarding process when we integrate other companies into our environment.

If we create another solution or we acquire another company, we will certainly expand our use of Veracode to match within our current solution stack.

The support has been good at understanding issues. There are two aspects of technical support. One concerns issues with the platform in terms of functionality, and the other is that they will provide you with assistance in terms of interpreting your findings.

Our experience from the technical side is that they helped us with figuring out how to best use the platform for microservices applications. They were very helpful in that conversation.

We also have experience with the other layer of technical support that Veracode provides, which is where you can get consultations about the findings. We've done a few of those where you set up an appointment with a Veracode engineer. It helps to understand the results if the platform isn't totally clear on why something is a problem or what we need to do about it. For us, that's been pretty good.

Obviously, the Veracode engineer doesn't have the full understanding of what our application does and in a short call, you can't possibly do an architectural deep dive to understand the context of an issue, but their conversations have been useful when we've had them in terms of understanding issues and context and if we need to do anything.

Prior to using Veracode, we used other code quality scanning tools, but not anything at the level of Veracode for security issues.

The initial setup was straightforward. It was pretty easy to get going and we've incrementally gotten better and deeper as we've used it over the years.

The initial setup was manual uploads of applications, and then it was about incorporating it into our build pipelines and using the sandbox to support our microservices architecture. We've gotten more mature over time, but time to initial use and results were very easy.

Only a very short time is required for deployment, as there is very little that has to be done. Ours was completed within a couple of days and that's a matter of coordination in terms of getting our teams to upload a solution and figure it out. It was a learning experience for us but there was no time or delay brought on by the solution.

When we first began with Veracode, the initial strategy was just to get our first solution uploaded and scanned and see what the results looked like. We didn't have a systematic history of doing that, back then.

With approximately 500 employees, we're not a huge company. Deploying it in an enterprise company would be a different situation but for us, it was just a matter of understanding how we needed to configure the platform and how we needed to provide our software and states and get good results.

It probably took a couple of uploads of trial and error and we were running.

We implemented the solution in-house. It is not that complicated.

In terms of maintenance, there is certainly some overhead involved for each team. They have to make sure that the build pipeline integration is still working and essentially, that we're still getting results. Occasionally, for whatever reason, it breaks and somebody has to go in and fix it.

I can't say that there is no staffing required for maintenance but it's rare. In total, a few hours a month across the company is spent keeping it going. More time is spent evaluating and resolving the findings, which is part of our development work. That's not imposed by the solution but rather a positive outcome from using Veracode. As such, I wouldn't count that as maintenance. 

We have seen a return on our investment with Veracode. I can't point to a dollar figure, but I've been directly involved in customer conversations where we can talk about our security program and how Veracode is an important element. We've distributed report summaries and talked about results with our customers and having this information in those conversations is definitely valuable.

It's also very useful that we can talk about it with our security auditors. We have SOC 1, SOC 2, and ISO 27001, and they don't specify that you must have a static analysis tool. But when we need to maintain secure engineering practices, having a tool like Veracode is very important for us to demonstrate that to auditors. There's certainly value there as well.

There is also a tremendous value on the marketplace that we get from having those security audits and certificates, which is a second-order of value that Veracode drives.

I can't say with certainty that Veracode reduces the cost of application security, although I would say that it focuses our effort. It gives us guidance and prioritization on where we should spend time. Otherwise, we might not know about particular issues. We might inadvertently spend time on things that aren't that valuable. So, the value is more about focusing on where we need to spend time.

From a cost perspective, it seems okay, although we will probably evaluate alternatives next time it's up for renewal because for us, it's a relatively high cost, and we want to make sure that we are using our resources most appropriately.

I like that the platform provides you with some flexibility. We had to revise our licensing because it did not fit our environment. We wanted to license based on the number of applications, rather than another measure such as the number of lines of code. There was clearly some complexity that led us to be in that situation, although it seems preventable. Ever since our last renewal, the licensing has been smooth and clear. There is a certain amount of flexibility in that regard but also, they allow us some leeway in our current model.

There have been times when for some reason, we spin up a new application on a temporary basis. It may be because we're trying a new configuration. Even though we're licensed for a certain number of applications, the platform lets us exceed that. Consequently, we receive an email stating that we can't do that forever, but it's very useful to have the flexibility for the couple of times that we've used it to briefly exceed the application account.

I am not sure what other solutions, if any, the company looked at before choosing Veracode initially. We have renewed it since that time and we pretty quickly decided to stick with Veracode, rather than switching. However, because of the relatively high cost, we will probably evaluate other options next time it's up for renewal.

We see at least quarterly updates about new features or things that have been fixed. It happens without our involvement, which is great.

My advice for anybody who is considering Veracode is to test it. Although I have not compared Veracode against other products as part of an evaluation process, it would be very useful and very easy to actually try it. Top-load your application, get the results and take a look at what Veracode finds. This is the most useful activity somebody could do.

This is a product that lives up to its promise. It's easy to use, and it's predictable. There are some improvement opportunities but on the whole, it's very good at what it does. 

I would rate this solution a nine out of ten.