Veracode Reviews

We use the Veracode SAST solution to scan the Java, Node.js, and Python microservices as part of our CI/CD pipeline, wherein we are using our CI/CD server as Bamboo, Jenkins, and GitLab CI/CD. 

We have teams for both our cloud pipeline and on-prem pipeline, and both teams use this solution. We are using Veracode to constantly run the internal application source code and ensure the code's security hygiene.

Before, the pentesting was happening at later part of the SDLC. Now, we have been getting early feedback about insights from Veracode, including traction around the application security aspects. Developers keep coming to us and asking the questions. Vericode has built a bridge between the development and security teams, which is something really helpful in an organization.

Veracode has helped us build security training in our clients' organizations.

The solution’s policy reporting for ensuring compliance with industry standards and regulations is very helpful. We use Veracode to scan for vulnerabilities. This help us comply with regulatory standards for the European region. While the policy scanning takes time, it is very good from a compliance point of view.

There are quite a few features that are very reliable, like the newly launched Veracode Pipelines Scan, which is pretty awesome. It supports the synchronous pipeline pretty well. We been using it out of the Jira plugin, and that is fantastic. 

We are using the Veracode APIs to build the Splunk dashboards, which is something very nice, as we are able to showcase the application security hygiene to our stakeholders and leadership. 

We have been using Veracode Greenlight for the IDE scanning. 

Veracode has good documentation, integrations, and tools, so it has been a very good solution. 

Veracode is pretty good about providing recommendations, remedies, and guidelines on issues that are occurring.

It is an excellent solution. It finds a good number of the securities used, providing good coverage across the languages that we require at our client site.

We have been using the solution’s Static Analysis Pipeline Scan, which is excellent. When we started, it took more time because we were doing asynchronous scans. However, in the last six months, Veracode has come with the Pipeline Scan, which supports synchronous scans. It has been helping us out a lot. Now, we don't worry when the pentesting report comes in. By using Veracode, the code is secure, and there are no issues that will stop the release later on in the SDLC. 

The speed of the Pipeline Scan is very nice. It takes less than 10 minutes. This is very good, because our policy scans used to take hours.

Veracode is good in terms of giving feedback.

We would like to see fewer false positives. 

Sometimes, I get feedback from a developer saying, "They are scanning a Python code, but getting feedback around Java code." While the remediation and guidelines are there, improvement is still required, e.g., you won't get the exact guidelines, but you can get some sort of a high-level insights.

Veracode has a little bit of noise. Sometimes you will get a lot of issues, which you just need to triage. While the solution is excellent, it does come with a little bit of noise.

We have been using the solution for a year and a half.

The stability is good, except every month it needs maintenance. So far, we haven't had an outage during UK working hours, e.g., where we are unable access the platform. There were some issues out-of-the-box, but now it's pretty much fine.

More than 100 people are using the Veracode solution in our organization. Mostly, the guys who use Veracode are developers, QA engineers, product owners, Scrum Masters, and some data scientists.

We have a three-person team of security guys who maintain the entire service. The security guys have automation skills and can write the code. We are one squad in a company out of 21 squads. We are a security who helps other development teams with Veracode as part of their DevSecOps.

We have adapted Veracode across three line of our client's business. In the future, we may expand Veracode into more lines of business. 

The technical support sometimes takes 48 hours to get back to us. Some of the support staff are not that great. There is no extra support on Slack channel nor is there a chat. Instead, we just have to wait for an email. They gave us a mobile number, which sometimes doesn't work. Then, if it does, it takes time. The technical support is something that needs to be improved.

Veracode's application security team is very helpful. If we are not getting the answers that we need, this team will come and assist us. For example, we had a call with their application security team who helped us determine best practices. They are good and very professional. 

Their account team is helpful and knowledgeable.

We use the solution’s support for cloud-native applications, like AWS Lambda. We have a cloud pipeline, where some of our microservices functions are getting developed there. Less than five of our squad use this service.

Because of my consulting background, I have used other solutions prior to the use of Veracode. However, Veracode was the first solution implemented of its type. Before Veracode, developers didn't know how they could develop secure software. After Veracode was implemented, developers knew when they wrote code that they could scan it in their IDEs. Also, while pushing a deployment, they can get feedback from the Pipeline Scan.

The initial setup is straightforward. It took us three months to deploy the entire solution across all the squad at our site via Pipeline Scan as well as have the squads adopt it. If you are familiar with security, you can be up and running with the solution in a week's time.

Our implementation strategy was to give the Greenlight ID plugin to all the developers and enable the microservices. Then, we wanted to let the non-human account use the new unlimited account and all the source code. This has helped us in last year and a half, as we have over 150 microservices being scanned by the Veracode platform.

Customer support was amazing during the evaluation phase.

The ROI seems good so far. The client is happy with what they invested in Veracode. Having our developers now think about security is also helping us out.

The solution has reduced the cost of AppSec a little bit for our organization through the automation of pentesting.

We have seen a 30 percent reduction in pentesting. Using Veracode, we can do faster releases.

Veracode's price is high. I would like them to better optimize their pricing. 

Veracode's price is a little higher than other tools. However, they are the market leader.

Micro Focus Fortify doesn't have good APIs. Instead, they are relying on CLI. Whereas, Veracode is more API and DevSecOps friendly. Veracode's scanning time is better than Fortify's. 

It is an excellent solution. I would recommend adopting it. If you come from a security background, Veracode is an easy solution. If you don't come from a security background, the adoption of Veracode will take a bit of time.

Veracode has been integrated with our IDEs. It has been also integrated with our DevOps CI/CD server, which is Bamboo, Jenkins, or GitLab CI/CD. It is all pretty neat and clean. 

I would rate this solution as a nine out of 10.

We use both the static and the dynamic scanning. What we do is run the code through the scanner once we make any modifications. And periodically, we also run the dynamic to connect several applications. We use Veracode to check for specific vulnerabilities such as cross-site scripting. When we are checking for those vulnerabilities, we take a portion of code that is going to be generated and we run the scanner.

We work a lot with open sources. Using the Static Analysis, the Dynamic Analysis, and the scan module, we can control everything we do via Veracode. Moreover, because all our applications are security applications, keeping a high security standard is really important.

The visibility into application status across all testing types in a single dashboard is helpful because, even if you are running different types of scans, you have everything in one place. You have a unique dashboard to control all the applications, and that is good.

Overall, we've never had any problem with vulnerable code going into production. It's quite a solid tool. We have a really good feeling with this solution.

The most valuable feature is actually the support provided by Veracode. Once you start to use the platform, you can mount the IDE plugin for your script. The advantage is that you can run the scan and check what the problem is and you can fix it yourself. Support could be used to address something that could go beyond your skills. If you use Veracode Greenlight, you have a small pop-up that you can use to interact directly with the team and you can ask a consultant to advise how an issue can be fixed. One of the good things about the Greenlight plugin is that it is very simple. There are several guides that tell you how to install it. It's a matter of one or two minutes and you are ready to go.

Once you check something, they provide links, not manually, it's all automated. When you want to check into a vulnerability you click and open the website where there is a description. If this is not enough of an answer, you can ask directly by scheduling an appointment with a Veracode guy.

Another feature of Veracode is that they provide e-learning, but the e-learning is not basic, rather it is quite advanced. They don't teach you how to develop in Java, Python, PHP or C#, but they instruct you about the best practices that should be adopted for secure code developing and how to prevent improper management of some component of the code that could lead to a vulnerability. The e-learning that Veracode provides is an extremely good tool. And as far as I know, there are no other competitors that offer it.

The best stuff is the training: this enables your team to adopt the same programming approach, although these people have a different background or joined the projects in a different phase. Doing that, they can take the training and be aligned so that they all write code in a good way.

We also use the Static Analysis Pipeline Scan and it's quite good. They provide several of the most common templates for pipelines. You see the process, while you program, right up until you package an application, and that the platform is able to detect things that are a blocking point. Before deploying to the production, you already know what is doing. And the speed of the Pipeline Scan is quite good.

Another good feature is the policy reporting for ensuring compliance with industry standards and regulations. We test compliance for medical devices, for GDPR, and for payment methods. These are all good. If you are not correctly prepared on one of these sets of regulations, you know that Veracode is going to take care of it using pre-prepared templates. But we can also customize our own policy if we are facing a unique use case. Even if it's not really common, we can take a regulation and build it the way we want it to look.

In addition, you can check everything from the dashboard. Veracode provides a web portal that is connected with your account and through that you can check the status of all the deployments that were run. And suppose you also have an application that is quite complex. You can deploy and upload it through the portal. When it is ready, you receive a notification from the portal that the job has been done and that you can check the results. When you go to the dashboard, you have the OWASP vulnerabilities. There is a really simple graphic with the colors showing how many vulnerabilities have been found and how much these vulnerabilities are repeated in your code. It also tells you the potential effect, if it is a backdoor data breach, for example, etc. It also suggests what you can do to remediate. It might suggest modifying code or changing the status of some part of the development, or updating a third-party.

And if you have people on different projects, there is also a role management feature, so you can select, for example, that people who are working on a given project can only see that project. If you are running something with different levels of classifications, for example, if you have an external consultant, it does not affect the confidentiality of the system. When people are collaborating, not all people are at the same level of an NDA. It is good that each person can see only their part implementing Need-To-Know.

It also integrates with developer tools. We use IntelliJ and Eclipse, among others.

They should invest in mobile security.

I have been using Veracode since 2017.

We have never faced a problem or any downtime.

We haven't perceived any issue when it comes to scalability. But it's true that if you have more tenants, the response of the scanners is going to get released quicker.

I would rate Veracode's technical support at nine out of 10. They would probably deserve a 10 but it is not as quick as it should be. They need to increase the support workforce. The support people are well-prepared, but it can sometimes take one or two days to get the right guy to do support.

The previous solution that we were working with was mainly focused on the quality of the coding. We are happy with Veracode because it's focused on security.

The initial setup is very simple. The Veracode guy who accompanied us made it appear really straightforward.

It's a SaaS solution so once it's prepared on the Veracode side, to deploy onsite may take up to a couple of hours to get everything prepared, mainly due to the configuration, for a simple implementation. Overall, setting up the product is quite straightforward. 

In terms of managing the code, it's quite simple for us because we are all technical guys. Once we saw it working, it was really easy to manage. We have three people who use the solution and they are all developers.

The Veracode team is replying fast and the proved a strong expertise in every challenge.

We could save some money having an on-premise solution, but the fact that this is a SaaS means we can be sure that it's updated. It's outsourced. In terms of cost, I don't see a big advantage, but in terms of operations there is because we don't have to take care of it. We know that if, somewhere else in the world, somebody detects a vulnerability, a few minutes later we will already have a patch. This is extremely important for us. Nobody in our company has to touch anything to get this.

If we had to designate one or two people to take care of maintenance of an application, at some moment one of them might not be updating things. With Veracode, we know that we don't have to worry. We just have to focus on our development. We don't consider maintenance at all because it's all managed.

The pricing is quite standard. It's not cheaper, it's not more expensive.

We looked at other vendors but we selected Veracode because it had a top rating in industry reviews. For us, that was like a warranty.

We were skeptical about running scans with a cloud-based solution, but then we saw the benefits. Everything is up to date without us having to lift a finger. We know we don't have to take care of maintenance. 

Also, if you work in the domain of medical devices, payment methods, or other things that are related to privacy, Veracode provides all these modules. This is a big advantage.

Sometimes the scans are not done quickly, but the solutions that it provides are really good. The quality is high, but the analysis is not done extremely quickly.

False positives are not a main problem. The platform does try to overprotect but, of course, a system like this can only understand the syntax and not the semantics. So it's overprotective when there is a doubt. Sometimes, we ignore some of the advice received.

At this moment in time, in my project, we are mostly using Static Analysis from Veracode. We automated it and added it as a step to our daily pipeline. We also tried using the pipeline plugin from Veracode that gives an immediate evaluation of your code. We're also using agent-based Software Composition Analysis. I have not exactly used it in my project, but I participated in investigating it and setting it up.

I know two flavors of doing Software Composition Analysis. The first one is a part of a daily static scan where you're uploading all your third-party libraries. The second one is by using agent-based, which gives more reporting capabilities but not doesn't affect policy scans, etc. We use both of them.

We use Software Composition Analysis as a part of our daily build pipeline, so we use Jenkins Plugin from Veracode. Every night, we upload our sources to the Veracode platform. In the morning, we receive results of Static Code Analysis and Software Composition Analysis. 

We are able to receive results for vulnerabilities in other libraries. We can then react to it and fix our code and those dependencies.

We do have a policy in regards to security. As a part of that policy, we cannot have very high-end issues. Usually, when you change third-party libraries, you need to do some level of regression testing. Our release cycle is long, and it could be half a year between releases or sometimes even more. By using Software Composition Analysis, we're checking our sources on a regular basis, and if needed, we change our libraries in our code, So, we are checking and mitigating any vulnerabilities if they are not applicable to our solution.

We use static scanning. This is the main use of Veracode for us. We package our application every day and send it to Veracode. We receive static code analysis results and also the software composition analysis results every day because the first focus for us is on quality improvement. The security improvement is definitely static scanning. We do have a process for analyzing and mitigating results around this static scanning. So far, we have been able to comply with our internal policy. At this moment in time, we are at the stage of releasing our product, and according to our internal policy, certain important issues from 2017 had to be addressed and fixed.

Veracode gives the possibility to find different vulnerabilities and flaws in code, and it also makes things relatively easy because everything is automated. Implementing such a high-quality tool like Veracode, immediately made us aware of a lot of issues, but the volume of issues that we had to address was really high. The support from top management made it easy to fix the issues that Veracode identified in the product that has a long history of more than 20 years. Without the support of higher management in organizing and defining a process of fixing those issues, it wouldn't have been possible to fix all those issues. We took the reports received from Veracode, planned our activities, reviewed everything, and started acting on it as a result. The new release that we have is according to our policy, which is an important thing for us.

It definitely helps in reducing the risk of a security breach, which is rather important for us for providing our customers with a secure product. Among our customers, there are a lot of big companies that take security seriously. So, for us, it is really important. The fact that we have executive sponsorship shows that security is very important for our management. This initiative started because we're treating security really seriously.

It is improving our productivity significantly. We just finished a big chunk of results processing, and we are still in the process of setting up our processes. When you're first doing that scan with Veracode, you receive a bunch of results and an overwhelming amount of flaws in your code. All those results need to be investigated. For some of them, it is sufficient to have mitigations, but some of them need to be fixed. We just finished those fixes, and there were a significant amount of security findings from Veracode.

Considering that in my project, we are mostly using Software Composition Analysis as a part of Static Code Analysis, for me, the main part is reporting and highlighting necessary vulnerabilities. Veracode platform has a rather good database of different vulnerabilities in different libraries and different sources. So, finding vulnerabilities in third-party libraries is the main feature of Software Composition Analysis that we use. It is the most important feature for us.

The results of agent-based software composition analysis are not connected to policy scanning. So, for me, the only thing that Veracode can improve in Software Composition Analysis is to connect it with the policy scan because, at present, it is a bit inconvenient for those in our organization who use agent-based Software Composition Analysis. In the end, they need to make a static scan with all those libraries in order to receive that report. If Veracode implemented a connection between agent-based static scan and static scanning itself, it would be great because it would lead to fewer operations in order to prepare release documentation and release reporting from Veracode. We recently had a conversation with Veracode about it.

I believe it has been about two years because Software Composition Analysis is a part of the policy scan, and our journey with Veracode has been for about two years.

It is stable. I didn't feel that many problems with it. We did have a few glitches with the platform, but they were not that many. So, I can say that it is stable.

I can't say anything about the scalability of this solution because we are not bothered about keeping its infrastructure up and running. We use Veracode Cloud, and we are not supporting or deploying it. It is just a service for us, and we consider it as a service. We submit the information and receive reports back from that solution.

In our project, every night, we are currently scanning our development branch and three versions of our releases. We have four applications, and I believe that from my team, at least 15 scans happen every night. We have a partnership with another company that provides a part of our functionality. They provide releases to us to embed in our solution. We also do the scanning for their part and inform them about the issues that we've found.

We will increase the number of scanned versions because with each and every release, during the support period, we're supporting versions of our product, and we're also fixing the security stuff. We will be increasing the volume of scans, but it will come to a logical point. When a version is no longer supported, we will definitely remove it from Veracode. So, all in all, at any moment in time, I foresee four or maybe five versions to support multiplied by four applications. There is also a development branch for each application, so there will be around 20-25 automated scans per night.

I am very pleased with the Veracode support because so far, there were no issues where they were not able to help us. Sometimes, in our questions to Veracode, we ask about the deep aspects of functionality, and so far, we've received answers for all those questions, and they were mostly good. I would rate them a nine out of 10 just because I didn't like some of their answers. Because of our approach of having each version as a separate sandbox in Veracode, we had questions about the consistency of results between different sandboxes, but then we realized that these are peculiarities of the platform. It is nothing serious or special. It was mostly related to our expectations from those algorithms, but it actually works perfectly. I can give a 10 for Veracode's support, but then they will have no growth to improve.

It was pretty straightforward. The problem that we had was mostly about our solution's architecture because the solution itself is big and heterogeneous. Some parts or regions are using the Java platform, and some parts are in the .NET code. The main problem was to correctly build our solution for Veracode. This was the only challenge. Veracode provided us with good functionality with their Jenkins Plugin that made it possible for us to automate our daily development. So, the main problem for us was mostly related to properly building our solution and using it in Veracode. It was pretty straightforward. There was nothing complex, but it needed some work from our side.

The strategy for Veracode implementation was pretty straightforward. From the very beginning, we stuck to the idea that it should be automated because all modern DevOps practices and approaches, such as Infrastructure as a Code, are widely used in our company. So, from the very beginning, we decided that it should be coded, and it should be stored in source control and uploaded. Veracode became a part of our process of everyday deployment, and it was a part of our strategy to make it a part of our life and use it as much as we can.

The number of people involved depended on the stage. At the initial stage, when we were evaluating it, there were somewhere around six or seven people who were making the decision of buying Veracode and other stuff. We have different companies and products inside our organization, and each and every product team is responsible for implementing it. We were the pioneers in using the solution from Veracode, and later on, it spread out to other projects. Now, we're acquiring additional licenses and so on. We planned everything with the help of the developer team. We follow the agile approach in our development, so everything was planned. User stories were created, and we just acted on them.

I participated in the review of tools. We reviewed not only Veracode. There were also other candidates for our main tool for static scan and software composition analysis. So, I have been involved in all activities around Veracode from the very beginning. What I liked about Veracode is that it is not just one product. It is a big ecosystem. It even has integration with Visual Studio, etc. First of all, we took a look at the scope of scanning. We compared the results of scanning and the functionality. Veracode had really great reporting functionality. In the end, we came up with the conclusion that Veracode fits best to our needs, and I believe we were right.

My advice would be to adopt Veracode to serve your processes. I believe that the processes inside the company shouldn't be changed significantly with the introduction of new tools. Definitely, for each and every new tool, you need to build some process around usage in terms of administration and control. Veracode has a relatively big ecosystem of tools, which is a big advantage, and my advice would be to check all those tools and see how they can fit into your process, and how they can improve them. There are a lot of options and a lot of tools provided by Veracode that can fit each and every process. Whether you are using a waterfall process or DevOps practices in your organization, with Veracode, you can add necessary steps to your process without making significant changes in the processes that you have.

We take security seriously, and Veracode is not the only thing that we have for security. We do manual penetration testing to security test our applications. We also have some dynamic scanning. We follow some practices while engineering and architecting our solutions. At each and every step, we are trying to cover our solution with the necessary security testing activities or security design principles. Veracode is a big part of our security, but it is not the only one. We are fixing all issues, especially those that are non-compliant with our policy.

We don't use any connections with Software Composition Analysis. It is a separate product in the ecosystem that makes it possible for you to deeply scan your third-party libraries. This is the only way we use it. 

In terms of Veracode SCA reducing our overall scan times, I believe that it is not applicable at this point. In the case of agent-based scanning, the situation that we recently had has shown that you cannot fully substitute Software Composition Analysis from a static scan with agent-based. That's because, in the end, documents that you provide together with the release are the policy scan results generated by static scan. You can reduce the amount of time for your scanning, but in the end, you need at least one scan where you will figure out all third-party states as a part of the policy scan report. You cannot use only agent-based Software Composition Analysis because they are two separate sources of information. We can use Software Composition Analysis and then somehow merge results from two sources in one document for it, which is inconvenient. We are having nightly builds for Veracode, and it doesn't matter to us whether it takes more than 30 minutes or less than 30 minutes. We haven't measured the time, but with the approach that we have set in our company, we can leave it for longer time periods, and after nightly build, everything is okay for us. So, Jenkins just does its job of uploading, and no one monitors it. We are just monitoring that the jobs are stable and results are available. Considering that we're doing it at night, it is not that important for us for how long it runs.

It hasn't exactly increased our fix rate because it is not about our code. It is about the third-party code. We definitely have to mitigate, and sometimes, we have to change libraries to a newer version, so it somehow affects our fix rate, but mostly, the static scan affects our fix rate because it shows flaws in our code. So, I don't see any significant improvement with Veracode Software Composition Analysis in terms of our fix rate. I don't see a direct relationship between Veracode Software Composition Analysis and our fix rate, whereas Static Analysis works and gives us the necessary results and plans for fixing and doing our next steps in security.

It has not yet helped our company with certification and audits. We haven't yet shared those green results with our customers, and we didn't have any certifications the last time.

I would rate Veracode Software Composition Analysis a nine out of 10.

We utilize it to scan our in-house developed software, as a part of the CI/CD life cycle. Our primary use case is providing reporting from Veracode to our developers. We are still early on in the process of integrating Veracode into our life cycle, so we haven't consumed all features available to us yet. But we are betting on utilizing the API integration functionality in the long-term. That will allow us to automate the areas that security is responsible for, including invoking the scanning and providing the output to our developers so that they can correct any findings.

Right now, it hasn't affected our AppSec process, but our 2022 strategy is to implement multiple components of Veracode into our CI/CD life cycle, along with the DAST component. The goal is to bridge that with automation to provide something closer to real-time feedback to the developers and our DevOps engineering team. We are also looking for it to save us productivity time across the board, including security.

It's a SaaS solution.

Our needs are primarily foundational and Veracode provides the efficiencies that we need.

The product is being used to replace another solution and we recognize in our early implementation that Veracode DAST is identifying more vulnerabilities in application code than our previous solution did.

Also, at this juncture, I have received no feedback of false positives from our development team. It seems to be fairly good in that regard and probably has minimal false positives. We haven't gotten feedback one way or another from developers about how the false positive rate affects their confidence in the solution, but if there were significant false positives, or even one in our environment, we would certainly be engaged with the vendor to discuss it. But that has not been the case so far.

Overall, I think that if it's implemented correctly for the business, Veracode is highly effective in preventing vulnerable code from going into production.

The visibility into application status helps reduce risk exposure for our software. Today, any findings provided by the DAST are reviewed by the developers and we have internal processes in place to correct those findings before there can be a release. So it absolutely does prevent us from releasing weak code.

Because we're so early in our implementation, we have had minimal feedback in terms of room for improvement. We have seen some minor things within the interface itself that we would love to see some improvements on.

One of those is scheduling, which can be a little difficult. For instance, if you set up recurring scheduled scans and a developer comes in and says, "Hey, I have this critical release that happened outside of our normal release patterns and they want you to scan it," we actually have to change our schedule configuration and that means we lose the recurring scheduling settings we had. We have to change that over to a one-time scan. It would be lovely if we could run ad hoc scans without changing our recurring schedule. That can be a little painful because it happens a lot, unfortunately. I think that will change, so I don't want to knock them completely. Right now, we run a manual configuration setup, but once we integrate this via API into our CI/CD life cycle, that issue should go away.

We have been using Veracode for four months.

So far, my impression of Veracode's stability is very good.

It appears to be very efficient when it comes to scalability. We're a smaller shop, so I may have a different interpretation of what scalability is. We're under 100 licenses at this point, but so far we have had success.

There are some great, positive things about Veracode and the relationship they try to form with the clients.

Regarding tech support, I've mostly had positive engagements, especially because they have one engineer who is, frankly, a rock star. I cross my fingers that I get him every single time because he's very thorough, he's educational, and he is quick. For the most part, it has been positive, especially when I do get assigned that particular engineer. I had a little frustration in the early days because they didn't quite understand the situation, but that was the only time I had a negative engagement with Veracode on support.

Positive

Our previous solution was difficult to configure. Setting up the login process was very difficult, as it was tied to your browser and there were a lot of hoops you had to jump through. The reporting was also hard to follow sometimes and didn't provide a good view into previous findings versus new findings. That made things difficult too. Once we did the evaluation of our old solution against Veracode, it was very clear that it was finding fewer vulnerabilities, which lowered our confidence level in that tool.

The initial setup was straightforward for us, and minimal, since it is a SaaS product.

The major component is being granted access to the tool. They then engage a customer success manager to help you understand and give you an overview of the interface itself and to walk you through some example setups. We were able to work with the CSM to configure a couple of our production scans. He did some hand-holding for us through the process until we felt that we understood it enough and had repeated it enough to do it on our own. He also provided detailed reviews of reporting, et cetera.

Deployment took less than an hour, although we have a small environment today. It would, obviously, take much more time with a larger organization.

Because we were migrating from one solution to another, it was an easy migration path. We just needed to collect the information from the previous solution and replicate that within Veracode.

One thing that can be difficult—and it was in our previous solution—is creating the login component for the scans. The learning about how to create that was a little daunting at first, because you have to create what they coin a "login script," but it is really just a recording of a login. Once you get it down, creating those "login scripts" takes less than a minute.

One of the struggles we have had with that recording process is that we have had to redo it more often than not if our developer has changed, even in some minor way, the way they collect information for the login. That does affect the script. That can be a little frustrating at times, but unfortunately, it is a known behavior apparently. It's just the nature of the beast if you do make any modifications to login.

As for admin of the solution, we have one person involved and it probably takes a quarter of their time or less. There is no maintenance since we have the SaaS product, other than ensuring that the scans that we have set up are still scanning successfully and that we don't have any failures.

Veracode has not reduced the cost of AppSec in our organization yet, but that's only because we are very early in the implementation.

We primarily looked at Netsparker as an alternative. 

My advice would be to understand how you want Veracode to function within your environment from a workflow perspective. That way, you can potentially start taking advantage of a lot of the functionality it offers out of the gate, which is something we are not doing yet. We're on a delay until 2022. That is really important. 

Also, in introducing the product to those who will be receiving the output, the findings reports, it would be great to include them in some conversation and collaboration on the move down that Veracode path or, frankly, any path that leads to scanning applications.

Veracode provides guidance for fixing vulnerabilities, although we haven't actually had to utilize that. But as a part of our licensing model, they provide us a certain number of opportunities to engage with someone for consultation.

We are not focusing on using the solution to enhance developer security training right now, although it is a part of our roadmap. We are banking on being able to utilize that aspect of Veracode because we are an Agile environment and we want developers to be able to engage that training. Also, when there are findings, we want our developers to get that assistance in real-time. That is a part of our 2022 strategy. 

We have started out with a much more narrow policy for ourselves because we are just learning about how the tool works and how it functions. But we did evaluate some of Veracode's policies, out of curiosity, and they seem to be very aligned and very helpful. However, I would not be able to speak to whether they are on the money for utilization against compliance frameworks.

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

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

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

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

I've been using this solution for four years. 

I haven't had any issues with the stability. 

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

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

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

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

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

I rate the solution six out of 10.

In my previous organization, we used to use Veracode throughout all verticals. It is a cloud-based platform, and you need to upload the code for static analysis. The code has to be uploaded as per the compilation guide provided by Veracode. So, for different languages, you have to combine the code as per the instructions in the guide.

We used to own and manage the platform. We also used to manage the users. If there was a particular project team that needed to use Veracode to do their code scan, they used to approach us. We used to create the user accounts for them so that user accounts were limited to just the code. We also used to guide and train them on how to upload the code on Veracode, how to combine the code, and how to initiate the scan. After the scan is completed, we used to tell them and guide them about how to treat the vulnerabilities in that code, how to fix and mitigate them, and what's the next process. Apart from that, we used to create a project team to build their CI/CD pipeline, where we used to create DevSecOps automation.

It is a cloud-based platform, so every organization or every security team in the organization is concerned about uploading their code because ultimately the code is intellectual property. The most useful thing about Veracode is that if you want to upload the code, they accept only byte code. They do not accept the plain source code as an input. The code is converted into binary code, and it is uploaded to Veracode. So, it is quite secure. It also has the automation feature where you can integrate security during the initial stages of your software development life cycle.

Veracode provides integration with multiple tools and platforms, such as Visual Studio, Java, and Eclipse. Developers can integrate with those tools by using Jenkins. The security consultation or the support that they provide is also really good.

Its user management is also good. You can restrict the users for a particular application so that only certain developers will be able to see the code that has been scanned. 

Their reporting model is really good. For each customer, they provide a program manager. Every quarter, they have their reviews about how much it has scanned. They also ensure that the tool has been used efficiently. 

There are few languages that take time for scanning. It covers the majority of languages from C to Scala, but it doesn't support certain languages and the newer versions of certain languages. For example, it doesn't support SAP and new JavaScript frameworks such as Node.js and React JS. They can include support for these. If you go to their website, you can see the list of languages that are currently supported.

The false-positive rates are also something they can work on.

I have been using Veracode for the last four years.

From my perspective, it is really good. It is one of the best SaaS solutions that I have come across. Veracode is also a leader in Gartner Quadrant.

It is pretty good in terms of scalability. There are many users of this solution. There are also many customers of Veracode. We had around 1,000 plus users.

The support that Veracode provides is really fabulous. They are very responsive. They provide you with a thorough analysis. If you have any questions or doubts, they help to clear them in a very simple manner.

I've used Checkmarx and HPE Fortify. Now, I am using Micro Focus. As compared to Veracode, Checkmarx takes input as plain text. It takes the code as it is and does not compile the code. This is the main difference between Checkmarx and Veracode. Checkmarx also has an on-prem solution, but Veracode does not have an on-prem solution. 

There is also a major difference in the cost and licensing model. Veracode's license model is quite complex. Comparatively, Checkmarx's license model is straightforward. You can upload any amount of code. For example, it could be 1 Gig or 2 Gig. They charge based on the number of applications, but Veracode's licensing model is pretty different. They charge based on the amount of code that has been analyzed.

It is pretty much straightforward. It is a cloud-based solution. So, creating a user in Veracode is pretty much easy. It involves just a few clicks. Uploading the code is also pretty much easy. It is user-friendly and developer-friendly.

When I used to maintain this for 1,000 developers, two or three people were enough to maintain it.

Veracode is costly. They have different license models for different customers. What we had was based on the amount of code that has been analyzed. The license that we had was capped to a certain amount, for example, 5 Gig. There would be an extra charge for anything above 5 Gig.

Veracode is well-suited for modern programming languages. Veracode is not for scanning large legacy applications with a huge codebase. It also doesn't support some unique languages such as SAP. This could be a challenge for certain people. 

More organizations are taking the left shift approach for application security and trying to integrate security early into their software development life cycle. Veracode is good for such automation.

I would rate Veracode Static Analysis a nine out of ten.

We use this solution for Digital Health.

This solution has helped us in developing a secured product.

Veracode is fantastic! All of the features are valuable.

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

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

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

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

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

I have several years of experience working with Veracode.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The use case is that we have quite a few projects on GitHub. As we are a consulting company, some of these projects are open source and others are enterprise and private. We do security investigating for these projects. We scan the repository for both the static analysis—to find things that might be dangerous—and we use the Software Composition Analysis as well. We get notifications when we are using some open source library that has a known vulnerability and we have to upgrade it. We can plan accordingly.

We are using the software as a service.

It has improved the way our organization functions mostly because we can perfect the security issues on our products. That means our product managers can plan accordingly regarding when to fix something based on the severity, and plan fixes for specific releases. So, it has improved our internal process. It has also improved the image of the company from the outside, because they can see in the release notes of our products that we take security seriously, and that we are timely in the way that we address issues.

The solution has helped with developer security training because when we open a ticket with information coming from Veracode, it explains, for example, that some code path or patterns that we have used might be dangerous. That knowledge wasn't there before. That has really helped developers to improve in terms of awareness of security.

The feature that we use the most is the static analysis, by uploading the artifacts. We have two types of applications. They are either Java Server applications using Spring Boot or JavaScript frontend applications. We scan both using the static analysis. Before, we used to do the software composition on one side and the static analysis. For about a year now, we have had a proper security architect who's in charge of organizing the way that we scan for security. He suggested that we only use the static analysis because the software composition has been integrated. So in the reports, we can also see the version of the libraries that have vulnerabilities and that need to be upgraded.

It is good in terms of the efficiency of creating secure software.

My team only does cloud-native applications. Ultimately, the part that we are interested in, in testing, works fine.

There are some false positives, like any products that we have tried in this area, but slightly less. I would trust Veracode more than the others. For example, we had quite a few issues with Snyk which was much worse in terms of false positives, when we tested it for open source.

Also, the solution's ability to prevent vulnerable code from going into production is perfectly fine. It delivers, at least for the reports that we have been checking on Java and JavaScript. It has reported things that were helpful.

What could improve a lot is the user interface because it's quite dated. And in general, as we are heavy users of GitHub, the integration with the user interface of GitHub could be improved as well. 

There is also room for improvement in the reporting in conjunction with releases. Every time we release software to the outside world, we also need to provide an inventory of the libraries that we are using, with the current state of vulnerabilities, so that it is clear. And if we can't upgrade a library, we need to document a workaround and that we are not really touched by the vulnerability. For all of this reporting, the product could offer a little bit more in that direction. Otherwise, we just use information and we drop these reports manually.

Another problem we have is that, while it is integrated with single sign-on—we are using Okta—the user interface is not great. That's especially true for a permanent link of a report of a page. If you access it, it goes to the normal login page that has nothing that says "Log in with single sign-on," unlike other software as a service that we use. It's quite bothersome because it means that we have to go to the Okta dashboard, find the Veracode link, and log in through it. Only at that point can we go to the permanent link of the page we wanted to access.

Veracode has plenty of data. The problem is the information on the dashboards of Veracode, as the user interface is not great. It's not immediately usable. Most of the time, the best way to use it is to just create issues and put them in JIRA. It provides visibility into the SAST, DAST and SCA, but honestly, all the information then travels outside of the system and it goes to JIRA.

In the end, we are an enterprise software company and we have some products that are not as modern as others. So we are used to user interfaces that are not great. But if I were a startup, and only had products with a good user interface, I wouldn't use Veracode because the UI is very dated.

Also, we're not using the pipeline scan. We upload using the Java API agent and do a standard scan. We don't use the pipeline scan because it only has output on the user interface and it gets lost. When we do it as part of our CI process, all the results are only available in the log of the CI. In our case we are using Travis, and it requires someone to go there and check things in the build logs. That's an area where the product could improve, because if this information was surfaced, say, in the checks of the code we test on GitHub—as happens with other static analysis tools that we use on our code that check for syntax errors and mapping—in that case, it would be much more usable. As it is, it is not enough.

The management of the false positives is better than in other tools, but still could improve in terms of usability, especially when working with multiple branches. Some of the issues that we had already marked as "To be ignored" because they were either false positives or just not applicable in our context come down, again, to the problem of the user interface. It should have been better thought out to make it easier for someone who is reviewing the list of the findings to mark the false positives easily. For example, there were some vulnerabilities mentioning parts of libraries that we weren't actually using, even if we were including them for different reasons, and in that case we just ignore those items.

We have reported all of these things to product management because we have direct contact with Veracode, and hopefully they are going to be fixed. Obviously, these are things that will improve the usability of the product and are really needed. I'm totally happy to help them and support them in going in the right direction, meaning the right direction from my perspective.

I have used Veracode for quite a long time now, about two years. I have been working here for three years. In my first year, the company was using a different product for security and then it standardized on Veracode because every department had its own before that. There was consolidation with Veracode.

The stability is good. What I have seen in the stats is that there is downtime of the service a little too often, but it's not something, as a service, where you really need that level of availability on. So I'm not really bothered by that.

We don't have to do anything to scale, because it's SaaS. 

We started with a smaller number of users and then we extended to full single sign-on.

The staff of Veracode is very good. They're very supportive. When the product doesn't report something that we need and is not delivering straight away, they always help us in trying to find a solution, including writing custom code to call the APIs.

From that point of view, Veracode is great. The product, much less so, but I believe that they have good people. They are promising and they listen so I hope they can improve.

We started with WhiteSource, but it didn't have some features like the static analysis, so it was an incomplete solution. And we were already using Veracode for the static analysis, so when Veracode bought SourceClear, we decided to switch.

The initial setup is easy and quite well documented. I was really impressed by the quality of the technical support. When I had problems, that the product wasn't good enough for me, they were always there to help and give suggestions.

Being a service, there wasn't really much of an implementation. It's not complex to use.

My job is mostly technical. I don't own a budget and I don't track numbers. But as the customers are really keen on having us checking security issues, I would definitely say that we have seen a return on investment.

Most of our customers tend, especially in the software composition analysis, to apply their own in-house tools to the artifacts that we share with them. Whenever we release a new version of software and Docker images, they upload it to their systems. Some of them have the internal equivalent of Veracode and they come back to us to say, "Hey, you haven't taken care of this vulnerability." So it is very important for us to be proactive on each set of release notes. We need to show the current status of the product: that we have fixed these vulnerabilities and that we still have some well-known vulnerabilities, but that there are workarounds that we document. In addition they can check the reports that we attach, the reports from Veracode, that show that the severity is not high, meaning they don't create a big risk.

It delivers because we haven't been thinking, "Okay, let's consider another product." We might see some savings so I think the pricing is right.

For open source projects we mostly tested Snyk, which works quite well with JavaScript but much less so with other technologies. But it has some bigger problems because Snyk considers each file inside a repository of GitHub as a separate project, so it was creating a lot of false positives. That made it basically unmanageable, so we gave up on using it.

We have also been using an open source project called the OWASP Dependency-Check that was doing a decent job of software composition analysis but it required a lot of effort in checking false positives. To be honest, it would have been a good solution only if we didn't have a budget for Veracode, but luckily we had the budget, so there was no point in using it.

Another one that we tried, mostly because it was a small company and we had the opportunity to speak directly with them to ask for some small changes, was a company called the Meterian. It doesn't do static analysis, but otherwise the software composition analysis and the library report were the best of the bunch. From my perspective, if we didn't have the need for static analysis, I would have chosen Meterian, mostly because the user interface is much more usable than Veracode's. Also, the findings were much better. We still use it on the open source project because they offer a free version for open source—which is another good thing about some of these products, where the findings are available to anyone. For a company like ours, where we have both open source and enterprise products, this is quite good. Unfortunately, with Veracode, if we scan the open source project, we cannot link the pages of Veracode with the findings because they are private. That's a problem. In the end, for the open source projects, we are still using Meterian because the quality is good.

My main issues with Veracode, in general, are mostly to do with the user interface of the web application and, sometimes, that some pages are inconsistent with each other. But the functionality underneath is there, which is the reason we stay with Veracode.

Usually, we open tickets now using the JIRA/GitHub integration and then we plan them. We decide when we want to fix them and we assign them to developers, mostly because there are some projects that are a little bit more on the legacy side. Changing the version of the library is not easy as in the newer projects, in terms of testing. So we do some planning. But in general, we open tickets and we plan them.

We also have it integrated in the pipelines, but that's really just to report. It's a little bit annoying that the pipeline might break because of security issues. It's good to know, but the fact that that interrupts development is not great. When we tried to put it as a part of the local build, it was too much. It was really getting in the way. The developers worried that they had to fix the security issues before releasing. Instead, we just started creating the issues and started doing proper planning. It is good to have visibility, but executing it all the time is just wrong, from our experience. You have to do it at the right time, and not all the time.

The solution integrates with developer tools, if you consider JIRA and GitHub as developer tools. We tried to use the IntelliJ plugin but it wasn't working straightaway and we gave up.

We haven't been using the container scanning of Veracode, mostly because we are using a different product at the moment to store our Docker images, something that already has some security scanning. So we haven't standardized. We still have to potentially explore the features of Veracode in that area. At the moment we are using Key from IBM Red Hat, and it is also software as a service. When you upload a Docker image there, after some time you also get a security scan, and that's where our customers are getting our images from. It's a private registry.

Overall, I would rate Veracode as a five out of 10, because the functionality is there, but to me, the usability of the user interface is very important and it's still not there.