Veracode Reviews

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.

We are using it for two purposes. The first is to analyze the final binaries in our normal development cycle and the second is for auditing old software.

It's a SaaS solution.

Veracode is able to analyze the final software products. We compile the applications and it's an advantage for us because there are a lot of areas where we don't have the source code. In some companies, only internal development is taking place and they have the source code and everything else for the software. With those companies, there are other tools that we can use. But for use cases where our company buys a product with the source code, but only the final executables or the binaries, only Veracode is able to work on that type of tool. We are working in the financial sector for big bank banks and insurance companies. A lot of times, these types of companies don't have the source code for the applications, only the final applications. This is the biggest advantage of Veracode, that it's able to analyze these types of applications.

We use the scanning process to help our security professionals and developers fix flaws in the code and that helps speed up the development cycle. It helps to "shift-left" all of the security control to the earliest phase of the development cycle. It has sped up the development cycle significantly. An unexpected vulnerability can stop the development pipeline, at least for a little while, and we are able to avoid that.

It has also helped to increase our fix rate by almost 100 percent. In the past, if it turned out that we had vulnerabilities, we had no time to correct them. We went into production with them. Now, we are able to fix everything, 100 percent, in the development cycle.

In terms of best practices, we have the results from Veracode and then we have a Knowledge Base of the types of vulnerabilities and how they should be corrected by our developers.

Another benefit is that it has helped us with certification and audits. We have a lot of automated reports based on the scans and we can show them to the auditors. That has saved us a lot of money and work.

And Veracode SCA has helped to reduce the risk of a security breach because it finds vulnerabilities as early as possible. It has increased our security and development teams’ productivity because, with the automated scanning, we are able to scan much more than previously. It saves us at least one week per development cycle, if not more.

The recommendations from Veracode have improved our efforts in fixing potential vulnerabilities, and not just finding them. That's important for us because fixing is a very expensive process. If you can save time on that, it is a big help. And SCA’s automated, peer, and expert advice have definitely reduced remediation times, saving us at least a week per development cycle.

Overall, SCA has significantly lowered the risk of vulnerabilities. If we didn't identify them before production, and it turned out that there were vulnerabilities, there would be a big risk. We would have to go into production with them or stop the development pipeline. So it lowers the security risk significantly by doing early scanning. It has reduced our risk by at least 60 percent. It definitely helps create secure software. That is 100 percent important because we are working for financial companies.

It's good that it's cloud-based because we don't have to operate a new IT system for security scanning.

It provides a centralized view across all testing types, including SaaS, DAST, SCA, and manual penetration testing. We now have a central place with overall visibility.

In addition, the mitigation recommendations provided by the scanning engine are good. They are not all perfect, but they are good and usable.

There is room for improvement in the speed of the system. Sometimes, the servers are very busy and slow. Also, because we are located in Europe, it would be a big help if they had a European or national service, because of the regulations, not only because of the speed.

Also, the integration with SonarQube is very weak, so we had to implement a custom solution to extend it.

We have been using Veracode Software Composition Analysis for more than two years.

The stability is good. We haven't had any problems.

The scalability issue is a good question because it's not too fast, but it's scalable because it's cloud-based.

We use it for 10 critical applications.

Their technical support staff is skilled. We have been able to solve all of our problems with them. I wouldn't rate them a 10 because sometimes it's time-consuming to get the right guy to answer our questions. But we always get answers to our questions.

Positive

We used SonarQube because the developers liked it. We also used Checkmarx. We switched to Veracode SCA because of the binary scanning ability. Neither Checkmarx nor SonarQube is able to do that.

The initial setup was very easy. Because it's a cloud-based service, we were able to do it without the help of Veracode. We just read the recommendations and followed them. We had three guys involved, two developers and one security guy.

It took three months to implement. Our implementation strategy was to do a pilot and then everybody in the organization copied the reference implementation.

Our return on investment is due to saving a lot of development hours.

It's too expensive for the European market. That is why, in a big bank with 400 applications, we are able to use it for only 10 of them. But the other solutions are also expensive, so it wasn't a differentiator.

The static cost model is not that important. Veracode works on a subscription model, so we have to pay for it every year. 

We chose Veracode's Software Composition Analysis after we evaluated more than 10 products. Among those we evaluated were Checkmarx, Fortify, and SonarQube. The primary differentiator was the binary scanning use case.

Use Veracode for the special use case of binary scanning, because it is the best in this special use case.

Security Labs is very good as well. We are not using it day-to-day, but it's a good feature.

Because Veracode is more interactive than Secure Code Warrior, the big benefit for our organization will be that the developers will not just get the blue team excited, but they will learn to think like the red team, like an attacker. The interactive labs will help developers see that some of the red team attack methods aren't that hard to do, and that will bring them more security awareness. 

Because developers will see exactly how you do a certain type of red team attack or exploit, they will understand that it's important that they don't think, "Oh, this could never happen." And when they realize that some of the attack methods are not so hard to implement, they will secure the code base and fix the vulnerabilities that already exist.

For example, when I tried SQL injection labs, I learned new ways to make those, and that is extremely valuable for me because. If I'm working with a code base, I can know exactly how to mitigate SQL injection, because not all systems are using Hibernate. I've been on code reviews where I could actually point out things related to injection, which is something I wouldn't have been able to do without Veracode.

Another big benefit for our organization is that it is more interactive and fun, in a way, than Secure Code Warrior. Developers will engage and spend more time in Veracode.

It has had a good effect on my security posture because the labs are very informative with current information, showing you some of the things that could be done by attackers if your code is done incorrectly. I have retained more useful information in a fast manner.

And if we talk about scanning, we will see advantages there as well. For example, I'm working on a Java project and because Java is a high-level language, it's hard to make code errors. But if I worked with C or C++, the scanner tool would be very good. If you take the OWASP dependency checker, for example, it goes through all the third-party dependencies which are often where the trouble is in a Java project. However, I have heard that you can upload the necessary files and it will go through the third-party components as well and, in that case, it's very beneficial for the organization to have such a tool.

It can be very hard to make a good lab environment with a console with log windows and code bases. What I like about Veracode is that they managed to do that. It has a very responsive graphical user interface and has worked very well. I was very pleased with that.

I like the web interface of the interactive labs and the information there. It's very well done by those who developed it, and it works very well. It's very fun and you get to learn new things and think like an attacker. It's not like on TryHackMe, but the information I got from doing the labs here was information that I didn't have before. The quality of the information was really good.

When I started to use Veracode, there were a lot of policy documents and I actually have a habit of always reading those. I haven't made a list of all the regulations and policies and how well it complies with all the security regulations, but from what I could see, it is aligned with security regulations and certifications. And in the lab environment, they have divided things into different topics like OWASP top-10. That is very actual and follows the security guidelines that are commonly accepted by organizations today.

I would like to see more AI features. It's a current subject because with ChatGPT and other solutions being developed all the time, IT attacks will increase. I actually talked to the CEO of an IT security company in the United States because he ranked the top-10 IT security risks this year, and one of the biggest risks was new vulnerabilities or attacks would occur because of ChatGPT and similar services. To defend against those it's very important that the good guys use AI in ways that are good instead of bad.

I have been using Veracode for about two weeks. I recently got access to Veracode to test it. I've been spending a lot of time on it, working with it in the lab environment. I have also tried out the scanning tools for code bases, but I mostly have experience working with it in the lab environment.

I haven't used it for very long, but I have never experienced any problems with the stability.

We are an enterprise-size company and I know that our security employees are using Veracode and some of the developers as well, but I don't know to what extent developers are using it. It's pretty widely used across our organization.

I give their technical support a very high grade. I was in contact with them with an inquiry I had, and there was a very fast response time. They took my request and prioritized it. They were nice as well, and that's how you want support to be, although not every support team is like that.

Positive

I was previously working with Secure Code Warrior which is very different, but it's within the security field.

I've been using the security platform TryHackMe a lot, which also has a web console, but I wouldn't pay for the kind of console window that TryHackMe had. It has a lot of good aspects, so no disrespect to them; I learned a lot from it. But I understand how hard it is to create that and Veracode has managed to do so in a responsive way that works well. It's very impressive.

Scanning tools are a big safeguard for getting vulnerable code out of production. It's almost mandatory today to scan applications because there are so many attacks happening in the world right now, no matter which solution you use.

I was very pleased when I tried Veracode because I hadn't heard about it before, but it was much better than I thought.

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.

We are using the static application security testing from Veracode and the Software Composition Analysis solution for the main product that we are developing. We don't use the Software Composition Analysis for checking license requirements, but only for finding problems in third-party dependencies.

It has given our management a view into issues with all of our product lines. We have three products and all of them were scanned. As a result, the project lead for each product has taken measures to improve things.

We also use a third-party dependency check from OWASP that is included in one of our other solutions. The Software Composition Analysis from Veracode is on top of that. It offers integration with the Veracode platform so that we can visualize all of these security problems at once. It is great to have an overview of all of the security problems that we have on all of our applications.

The most important thing that we have used Veracode for is the static application testing. That was our main target.

The UI is messy because it freezes sometimes and some of the UI components are blocked and I do not know why that is happening. It's not happening only to me. Colleagues have reported to me that they have this issue.

We have been using Veracode for more than a year, but we have only been using the Software Composition Analysis for a few months.

We haven't run it often enough to check if it is stable or not.

The support guys are good professionals. We have received valuable comments on proposals from their side. They are reliable partners and have good expertise.

Positive

We use various techniques to improve our security. We use an OWASP software application networking model to improve security in our different products. We use a number of native plugins to check licenses and vulnerabilities in the third-party libraries that are part of the application. We also have several plugins from SonarLint that are integrated in another tool that we use for quality assurance.

We put Veracode in place because we have an agreement with SAP and we must fulfill some security checks to become partners for their solution. Veracode's functionalities resolve all of the security checks that were demanded of us.

We use a different company for pen tests, three times per year, and it usually takes two or three weeks each time.

There isn't much of an implementation. We upload binaries to the Veracode platform and they are scanned and processed according to certain policies and security requirements. Then we get the results.

We are working on implementing Veracode SCA with our biggest product.

We want to integrate the software composition analysis with our CI pipeline and we are working on it, but because of the size of the application we have encountered some difficulties, things we have to tackle technically.

It's problematic if you want to integrate it with your pipelines because the documentation is not so well written and it's full of typos. It is not presented in a structured way. It does not say, "If you want to achieve this particular thing, you have to do steps 1, 2, and 3." Instead, it contains bits of information in different parts, and you have to read everything and then understand the big picture. Hopefully, then, you can integrate it.

Regarding the recommendations provided by Veracode scanning engine, we have our own way of dealing with the software composition issues. We plan to change them, but not very soon because it was really hard to impose Veracode on our whole group and for all product lines, as Veracode is a relatively new technology for us. We have had it for one year, but the change has not been so easy. We will try to combine all of our strategies in the Veracode platform in the future.

We hope that we will have a successful integration in the near future and that it will bring major benefits, at least for the managers and the people who are responsible for analyzing the flows and for keeping security under control. The amount of management effort will be reduced at that point.

For our company, the price is reasonable for the benefits that we get.

We paid for a one-year license. The contract was reasonable in terms of financial features. The pricing itself depends on the size of the company and on how much the company is willing to pay for these security extensions and how much the company is willing to invest in security in the first place.

Veracode was rated by industry reviews as the top player in this field for static application security testing and SCA. My advice would be to investigate the market because it will give you an idea of what is the best and most cost-effective solution for your company.

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.

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.