Veracode Reviews

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 have found the static analysis to be useful in Veracode Static Analysis. However, we are in the process of testing.

Veracode Static Analysis could improve the terminology. For example, I do not know what the sandbox scan does. The terminology and the way they have used it are quite confusing. They should have a process of capturing problems that users are having on their end.

Veracode Static Analysis should adapt and detect the vulnerability which is coming from customers.

I have been using Veracode Static Analysis for one and a half years.

Veracode Static Analysis is a scalable solution.

We have approximately 10 people using this solution in my organization. However, we do not use it daily.

We previously used a free tool that is integrated into the Eclipse.

The initial setup of Veracode Static Analysis is in the middle range of difficulty. We had some minor issues but we had some guidance and support. It took us approximately one month to scan all of the microservices.

Our IT team did the implementation with support from the Veracode team. The Veracode team was very good.

The price of Veracode Static Analysis is on the higher side.

My advice to others would be to follow the instructions and they will not have any issues.

I rate Veracode Static Analysis a seven out of ten.

The primary use case for us was looking for web applications that might have vulnerabilities that could be compromised. Specifically, I was managing a team and we had built a lot of applications as well as having purchased applications from vendors. We were working with a security team to go through and scan those applications for vulnerability using Software Composition Analysis. We were trying to avoid situations where somebody could do something that they should not be able to do like get at data.  

The product helped improve our organization by helping us to identify potential problems in applications and fix them before they were used in a way that they should not be. In essence, it helped enhance our security. I think another thing is that it did is it did kind of helped us with the general education level of staff working on the projects. Developers or technical stakeholders specifically were presented with the opportunity to understand things that maybe they did not before.  

We were not doing the training piece of the process when we were onboarding the product, but just adopting the platform definitely increased their awareness and knowledge about potential issues in development and application vulnerabilities.  

One of the best things about the solution is that I think it is kind of easy to get started using it. The pain of adoption is low. Once you got the code scanned, there is a lot of information that you have to plan time to go through and work with other teams to get things resolved or disposition.  

I think that it was easy to get started, but there was also definitely a learning curve in terms of people needing to understand what the reports meant and what to do about the information that they were getting.  

There is a concept called false positives where things might come up as a potential issue but they really are not. In our case specifically, we might get a false positive when a potential vulnerability is discovered through Veracode analysis, but the way that the application is built makes it so what appears to be a vulnerability is not really an issue. Stated a different way, even though there might be something that prevents that particular event from ever happening, the product does not correctly detect the safeguards or the impossibility of the issue arising.  

When a false positive gets reported by the Composition Analysis, it results in more work for you to do than you should have to. There is a lot of information to go through and so some of it is due to those false positives. You either have to do work to eliminate the false positives being identified, or you have to look at the alert and determine that it is harmless.  

As far as what might be added in future releases, more artificial intelligence capabilities would be desirable. I do not know if they have it now. Maybe one example could be to make more focused suggestions or give more information in the reports to locate the cause of the issues. It should be something that improves results over time so that people do not have to do as much work to understand the details.  

I have been using Veracode Software Composition Analysis for probably around three years.  

I would say it is definitely stable. There were no problems with the platform itself. It has been reliable. We never had issues where we needed to call support.  

I think the opportunities for scalability are good because we did not come upon issues that caused us to wonder about its limitations. We have not really pressed to find scalability problems. So my impression is that scalability is good. We did not experience issues due to bottlenecks or anything like that.  

Our group of users contained a mix of roles. It was developers, project managers, testers, information security analysts, and engineers. It was probably a total of around 30 to 40 people.  

For deployment and maintenance, there were really just like a couple of people. There was not a full-time dedicated need for it.  

There were times when we had to deal with support when we ran scans and we were reviewing results. There were times when we needed to either open a ticket or talk to somebody who had some expertise in a specific area. That process was timely and they were responsive. So that was good.  

Veracode actually has a separate subscription that you can participate in that is something like a learning management catalog. I think that the training piece of support has definitely improved over the course of when we used it.  

We did have a different product, but it was a little bit for a different purpose. We were using a different product but complemented the Veracode product. 

The initial setup was pretty straight forward. That is part of it being an easy solution to get started with.  

The deployment started smaller in employing the product to analyze a subset of our applications. It initially was being employed to look at the vendor applications that we had. I would probably say that initial period was about three to six months. That effort was focused on one group and did not really include all of the technical people and developers.  

Once we saw what it could do, it got adopted and we rolled it out to more people. So we kind of employed it in stages. The first part, which was essentially a test period, was three to six months. Then pushing it out for broader adoption in the next part was another three to six months.  

We did not use integrators. We did have the training and we did have professional services in the form of customer support from Veracode.  

I do not remember the licensing costs off hand. I would probably estimate it to be between 50,000 to 75,000 in our case.  

The advice that I would have for people who are new to the product would be to start with a proof of concept. This will help you to see how the product works with your process and people.  

The biggest lesson I have learned from using this solution is that it definitely increased my education on how to prevent application vulnerabilities earlier on and how not to repeat them. It also helped me as a manager to better understand how to guide and coach people.  

On a scale from one to ten where one the worst and ten is the best, I would rate this product probably as a  seven, if I am going back in time. I thought that there was room for improvement, but at the same time, it did what we needed it to do. We got what we expected. So I thought it was good, but I also think there were some additional manual steps or work involved that we should not have needed to do. That is really why I do not rate it with a higher number.  

Static analysis.

It has allowed us to integrate with it through automated processes, which saves us a lot of time and effort.

Also, our customers benefited from the added application security assurance of our software, as they’ve been able to identify OWASP top-10 application vulnerabilities without a manual tester.

Static analysis scanning engine, because we need to do static analysis; that’s why we bought the product.

• Better APIs
• Reporting that I can easily query through the APIs
• Preferably, a license model that I can predict

It would save us time when integrating with the APIs. Difficult APIs are annoying to work with and we have to trial/error our way through the integrations. The more straightforward and friendly they are, the less we have to trial/error.

No issues with stability.

Aside from the licensing, no issues with scalability.

Good.

IBM Security App Scan. In looking at Veracode vs IBM Security App Scan, I switched because of the CI/CD offerings of Veracode.

The APIs are a bit nonsensical, but otherwise straightforward.

It has not really resulted in any cost savings related to code fixes.

The worst part about the product is that it does not scale at all. Also, microservices apps will cost you a fortune.

IBM, Coverity.

Regarding measures taken to integrate Veracode into our existing software development lifecycle, we have 100% API integration. We use the Jenkins plugin as a last resort, but we are moving away from that.

The AppSec best practices and guidance to our security and development teams are manifested in the static analysis it provides.

In terms of advice to others looking into implementing this project, I would say don’t use the UI, and do what you can to have license conversations up front.

It depends on the use case and budget, but I would recommend CA Veracode to colleagues.

Software security, static code scanning.

It has performed very well.

The benefits are quick discovery and understanding of software vulnerabilities that we are putting in our own code. By discovering them quickly enough, we can triage them and determine the best ways to remediate them and prevent them from happening in the future.

It helps us gain confidence that the applications we're putting out in the hands of millions and millions of people have that industrial-strength quality to them; that we don't need to worry about as much as we used to. 

• Completeness, comprehensiveness
• speed
• ease of use

We have such a wide variety of users for Veracode, including security champions, development leads, developers themselves, that the ease of use is really quite important, because we don't assume anything about what those people might already know, or need to know. It just makes it very useful for anyone who has to engage with it.

I'd like to see an improved component of it work in a DevOps world, where the scanning speed does not impede progress along the AppSec pipeline.

Three to five years.

Stability has been great. I've never seen any downtime, in four years.

We went from 50 applications in 2015, we're now up to over 400. There seems to be no limit on how quickly it can scale and operate.

They're outstanding. Best in class. Absolutely. They bend over backwards to help us. We'll come up with questions and within minutes, we'll get answers. It's amazing. It's truly amazing.

It was very straightforward. Veracode was very helpful, hand-holding - anything that we needed - they were right there and made it very simple.

We had been evaluating various different types of source-code scanners. It was a fundamental element of the program and we knew we had to have the best one that would meet a wide variety of applications: development, apps, as well as a wide variety of geographic dispersion of the people writing these apps. 

We had IBM, we had Fortify, we had PMD, and there was one other scanner at the time that we were evaluating. Veracode came out on top, in almost every category.

By using a cloud-based scanner, we really had no issues with where the developers are geographically located. So we didn't really have setup problems at all. It just kind of happened, and scales fairly naturally, organically.

The most important criteria when selecting a vendor are

• reliability
• customer service.

Take advantage of all of the help that Veracode provides, for implementation, operations, and maintenance, because they absolutely know what they're doing.

We use the solution to scan for and identify vulnerabilities or security issues.

We use a SaaS deployment.

Before releases, we must ensure that all the security issues identified by Veracode are addressed. Occasionally, some false positives may be encountered, but these can be safely ignored. We are usually satisfied with the accuracy of the report as all the important security issues are identified and addressed allowing us to focus on our release sooner.

All the applications that are going to production in our large company are required to pass through Veracode, which provides us with a uniform standard that everyone must adhere to. This standard allows us to ensure the quality of our products before they go to market.

Veracode may not seem to immediately save our developers time, and it may even seem tedious at times. Ultimately, however, it can be extremely useful in identifying issues and vulnerabilities before they become larger problems, making it a valuable resource.

Veracode helped our security posture by checking security gaps in the production environment.

The most valuable feature is the static scan that checks for security issues. We use Veracode for this purpose; we also use the solution for our UI, but for the backend, we only use the static scan. I'm not sure what it is called, but it is one of two scans, the other one being dynamic. We only use the static scan to identify any security issues.

Veracode assists in the prevention of vulnerable code from reaching production by providing a comprehensive review of security risks and comprehensive reports with thorough descriptions of the vulnerabilities. This allows us to address any security gaps in the release. Based on the severity, we should determine the standards for release. We should not have any security issues with a severity of medium or higher before releasing.

Veracode provides us with ultimate visibility concerning security issues. Additionally, we use OWASP, which checks our dependencies to identify any potential weaknesses, but Veracode is the only tool we use to check our source code. With Veracode, we have the capability to recognize any security issues in our source code.

The false positives have room for improvement. Sometimes, we will get false positives, which we mark as mitigated. However, it can be annoying when they come up again in the next release. Every time a new person is doing the work, they may not be aware of the history of the issue. They must then check the false positive again and mark it as mitigated, and it may come up again in the future. False positives can be an irritating and time-consuming issue for developers to deal with. Investigating them can be a waste of time, as they have already been looked into. This can be frustrating for those involved. False positives waste our time and resources.

The zip file scanning has room for improvement. Sometimes when we upload the zip files for scanning, it can take a long time to get the report. This can take up to a day. Unfortunately, even after waiting a day, sometimes we find that nothing happened and we have to start the process over. This is both time-consuming and frustrating, as we feel the system has crashed.

The reports have room for improvement. I believe the reports are thorough but can become overwhelming with unnecessary information that may not be pertinent to the developer. I'd prefer to have customizable reports that allow us to select which elements we'd like to include.

I believe the usability of the UI needs to be improved. For example, when we navigate away from a page, it should remember our last location and take us back there instead of sending us to the homepage. Additionally, it should be easier to navigate between pages without having to refresh the page each time.

Veracode should provide potential customers with better training materials and resources to help them make a more informed decision before purchasing the product. This could include tutorials, demonstrations, more about how the product works, the user interface, the quality of Veracode's reports, and more. It is unclear if these resources are already available, but they should be made more visible if so.

I have been using the solution for over one year.

The report is usually ready without any problems, but occasionally there may be a crash or other issue occurring in the background that prevents it from being ready. This happens about 10% of the time. The solution is primarily stable.

I haven't experienced any scalability issues so far. This is likely because the job is always the same and the files we upload remain the same. We haven't had to change any parameters in the input, so scalability hasn't been a concern.

We used CodeSonar to analyze various aspects of our source code, and we already utilize OWASP to assess the security risks of our dependencies.

I give the solution an eight out of ten.

One of the applications we supported through Veracode is designed for use by travelers of an airline. The application handles everything from searching for availability to obtaining tickets.

The solution does not require any maintenance. I am logging into my organization's portal, from which I have a direct link to access Veracode. I do not need to do anything else, such as create content or install anything.

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.

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.