Veracode Reviews

As a full-stack developer, I am also involved with DebOps tasks. When deploying to different environments, we have stages that must be passed as part of DevOps. One of the primary stages that must be passed while deploying to Jenkins is Veracode Analysis. We also have SonarQube analysis, which typically checks code quality, code coverage, and other aspects, such as whether there are any bots or vulnerabilities. Once the code quality test is passed, it enters Veracode analysis. During Veracode analysis, the code is checked for vulnerabilities. Veracode also checks to see if any outdated jobs are being used in the code and suggests better versions to use. All of this information is clearly displayed in the Veracode analysis results. Veracode is linked to JFrog Artifactory, which is a repository of all the jobs available on the market. Veracode uses this information to choose which jobs to use and which jobs to fix. Veracode also explains the possible errors in the code.

We do not receive many threats. The threats are very minimal. Therefore, I have never been in a situation where Veracode had to save me from vulnerable code entering production. However, it is still helpful for us and our managers to access our code to see what is happening and what can be improved using Veracode.

Veracode is constantly being updated and improved. I started using it in October 2022, and at first, we didn't receive much training on it. As a result, we struggled to understand its features at first. However, after some interface changes, I found it easier to catch up. After six months or so, we were able to easily identify and understand what was happening. We use SBOM, and I believe that Veracode is improving significantly in its ability to assess specific vulnerabilities. For example, they are now trying to identify SQL-related injections as well. This is something that I appreciate.

The policy reporting ensures compliance with industry standards and regulations. It also provides a detailed report with multiple options. We can easily generate a report of four to ten pages, or even a one-page report. I really like the way Veracode generates reports on assessments. It's my favorite feature.

It provides visibility into application status at every phase of development, but we must manually scan applications to check the assessment for a specific application or after deploying it to a particular environment. I think they can change this so it automatically scans for us.

The false positive rate is low.

Veracode has improved our organization's ability to fix flaws, and fixing vulnerabilities has sometimes required us to develop new features. This has actually helped us and made our applications better.

It has helped our developers save a lot of time. Jobs are constantly changing and upgrading, Veracode allows us to easily assess the security of our jobs in 10-15 minutes, instead of 40-60 minutes.

Veracode helps us improve our security posture. Once we identify and fix the vulnerabilities Veracode finds, we no longer face any threats.

The feature I like most in Veracode is that it clearly specifies the line in the entire file where a vulnerability is found. For example, if there is a vulnerability on line 32 of the demo.java file, Veracode will clearly state that and also tell me the severity of the threat, such as moderate, high, or very high.

The interface is basic and has room for improvement.

The main problem I have faced with Veracode is that it does not integrate well with JFrog Artifactory, the repository where all our jobs are stored. This means that sometimes jobs are not reflected in the Veracode report, which is a major drawback.

We have a Maven repository provided by Maven itself, which is widely used by all developers. It is the heart of these jobs, and every detail is available in the jobs. So when Veracode says that a specific job is not vulnerable, but the Maven repository says that it is, I don't think Veracode is updated daily. This is a problem because if I fix the job, taking two to three hours to do so, and then Veracode is updated two weeks later and linked to the Maven repository again, Veracode may show that the job is no longer vulnerable. This is a threat, as it wastes a lot of time for developers. As developers, we usually have deadlines to meet for moving to particular environments, such as UAT or production. Veracode is wasting our efforts by not being updated daily.

I have been using Veracode for one year.

The stability can be improved. There are times when we don't see our applications and have to ask a Veracode support person to add them.

Veracode is scalable, and we have not had any issues with the Microsoft and Solar components that we use. It has always worked seamlessly, and we have the ability to scale up to 15 components on our end.

We only had to use the technical support once and it was fine.

Neutral

I would rate Veracode eight out of ten.

There is minimal maintenance required from developers. The infrastructure team will take care of it. So, let's say there is one application, four microservice components, and six flow components. In that case, two members can easily maintain the Veracode platform.

I am one of five member developers from India who are using Veracode. We also have locations in Spain, Mexico, and London.

I recommend Veracode for organizations that are not in the cloud and still working on-premises. 

I have implemented Veracode for both static and dynamic analysis to minimize errors in my application and avoid the need for manual reviews. This enables us to create a risk-free application in the code. Additionally, I utilize external libraries and licensing to accelerate the process of identifying vulnerabilities in my software development. This helps me and the development team to provide comprehensive information about the code.

Veracode's capability to prevent the deployment of vulnerable code is impressive. It allows for quick detection of defects during the development cycle, leading to faster release of improved code, and ultimately ensuring that our product is free of vulnerabilities. This feature is a great advantage for our organization.

SBOM is beneficial as it enables us to verify software licensing through static scanning. This helps ensure that the product we provide in the market is compliant with industry standards and user needs. In my opinion, this is a fantastic feature.

Creating a report is easy when using a sample template that we can relate to. If we know what kind of data we want to include and how we want it to be presented, the process of creating a report can be completed quickly.

The main advantage of using Veracode is the assurance that we are developing stable, secure, and fast solutions that are free of risks. This provides us with a clear picture of our progress toward our goals. Veracode helps our developers by providing remedial action and reports in various formats, ranging from summary to detailed. This allows us to customize our reports and share visually appealing reports with the team.

Having visibility into the status of our applications at every phase of development throughout the software development cycle enhances our DevOps productivity and ensures a stable solution.

The false positive rate is valuable. The benefit is that the false positive results provide our developers with a clear understanding of their proficiency level in development. However, the drawback is that during fast penetration or testing, they may receive alerts that can cause frustration. Additionally, if they perform another test, the previous alert may not appear again, making it difficult to address the issue. Overall, I believe that false positives can boost our developers' confidence in their abilities to a certain degree.

The false positives identified through static analysis have been beneficial in saving us time. Due to our use of advanced tools and record-keeping practices, we have been able to streamline processes such as data importing, which may have otherwise required local or manual methods. This has resulted in significant cost and time savings for our team. With the ability to work remotely using tools like Veracode, we are able to provide effective reporting and management for all software applications.

Veracode has been a time-saver for our developers by enabling those with different programming languages and skills to collaborate and develop stable solutions together. As a result, we are able to save some time.

Our overall security posture has been positively impacted by Veracode. We are confident that our solutions are highly secure for our clients and stakeholders. With Veracode's assistance, we ensure that our applications and software are free from bad code and other vulnerabilities. By troubleshooting alerts, we prevent abnormal codes from reaching production, creating stable and secure solutions. Veracode helps ensure social sustainability during the UAT process before we release the final product to consumers, resulting in a highly secure end product. Veracode has enabled us to offer a stable and trusted solution that fosters transparency between our company and the end-users, supporting their needs and activities.

Veracode reduced the cost of our DevSecOps by allowing us to use a single tool that can be operated by a small team of developers. We saved around $1,500 USD using Veracode.

I believe that testing code early on is always beneficial, and using UI saves time by detecting issues in the flow before the release cycle through verification scanning. Additionally, I appreciate the integration provided by Veracode that seamlessly integrates with our CI/CD tools and allows us to integrate with IPA as well. Overall, I'm impressed with the integration and user interface.

Veracode can be slow at times and has room for improvement, which may cause delays in our products and prolonged static scans. However, we can run these scans in the background to minimize disruptions. Static scanning can be a slow process that requires some time.

The cost and scalability also have room for improvement.

I have been using the solution for three years.

Veracode has no downtime and is highly stable.

The scalability is neutral because it lacks some integration. We have 12 end-users within our software and engineering departments.

The technical support is responsive and helps us resolve our issues quickly.

Positive

The initial setup is straightforward. I deployed the solution myself.

The implementation was completed in-house.

Veracode assists us in increasing our sales by allowing us to redirect the funds that would have been used to pay our ex-pats to troubleshoot errors or issues with vulnerable code. Consequently, we are experiencing a higher return on investment, and our company has generated over 55 percent return on investment since implementing Veracode.

The pricing for Veracode is high, making it difficult for beginners to afford. Whether or not Veracode is a viable option may depend on the specific needs and use cases of the user, as it may not be affordable for small businesses.

Veracode is costly, which makes it unsuitable for small organizations. However, if an organization has the budget for the solution, it is worth investing in.

I give the solution a seven out of ten.

I believe that it is a wise decision to test our code to ensure its security. Utilizing Veracode is a beneficial practice as it examines our code and provides recommendations on areas that require improvement. This ultimately results in a stable solution. However, I advise using Veracode only if the business has the budget for it, as it can be expensive. Any organization that chooses to use Veracode, can be confident in the quality of its solution but must be prepared for the associated costs.

We use Veracode for static code analysis, dynamic code analysis, and software composition analysis. In our organization, we have a bunch of applications that are running on a monorepo or microservice level. We have to do SAST on those applications so that we have a code review done on a bit level. 

Going forward through the application pipeline, we do it on the dynamic level, as well, where we are scanning the public URLs of those applications to see what people can see externally. It's a type of out-to-in scanning in which we are analyzing the traffic that is sent out and even the traffic that is coming in, the response and request headers of the URLs, whenever someone is at a single URL. 

Finally, for the software composition, Veracode uses a third-party analysis tool in which it has the libraries and the functions that are being used at a source code level. They are open source or dependent files that are used for building that in-house application.

As a company, we have moved from using contractors and third-party consulting companies to creating our software through more of an in-house model. We are moving more into the DevOps realm with more of our own teams developing our software. Veracode fits that DevSecOps ideology. It is definitely helping us build more secure software than we previously had.

We have a bunch of applications into which we have integrated Veracode and we have seen that, in the final phase of production delivery, there are fewer vulnerabilities than we used to have.

And because Veracode has remediation and tracking within the platform, it becomes a good single pane of glass where the developers and the security professionals can operate and govern the flaws in the software. And they can take the necessary steps to remediate them.

In the metrics that we generate every month, we have seen the numbers go up with respect to remediation as well as the number of flaws that we catch. The word is spreading, and more and more application teams are using the static code analysis tool inside their pipelines. Overall, we are moving from reactive mode to proactive mode in remediating vulnerabilities through Veracode.

Veracode also helps our developers save time, in the big picture, compared to a situation without Veracode. Let's say there is an application on which no static analysis was done and the audit team says, "Hey, you don't have any static code analysis in your pipelines. You need to do something about that." They could scan the code that is already running in production and find flaws, but those flaws would take a lot more effort, time, and resources to mitigate compared to if they had been detected in a static analysis prior to the code going into production. In that way, it has definitely saved time. But if we are talking about short-term planning for sprints, it takes a little more time than usual because security is coming into the picture, as well. But overall, it helps save time.

Our security posture has gotten better since 2020. It takes time to do the integration of the platform and educate people about how to use Veracode, and then move on to remediating and validating things. But the journey that we had with Veracode has definitely helped us a lot, overall, with respect to bettering our security posture.

The static analysis is the most valuable aspect for us.

It also has the ability to block a build. In pipeline scanning, there is a configuration that can be set with respect to the security level of the flaw. If there is a high or a critical issue, there's a way the build can be failed and blocked before going into production. But the best case that I have found for blocking builds is in the staging area. You don't really want any blocking done on the production environment because there are business SLAs that the enterprise has to fulfill. The best case would be blocking the builds in the staging phase, the pre-production environment, so that everything is taken care of before it is pushed to production.

There are three integration points for Veracode. One is the IDE plugin. Whenever a developer is writing code on their IDE platform plugin for Veracode—whether IntelliJ or Visual Studio, et cetera—it tells them if that piece of code has any vulnerabilities and if there is a better way to write the code.

The next point is the pipeline integration in which, whenever a build is getting pushed from a standalone branch to the main branch, a scan is done on that commit to see if there are any vulnerabilities.

Finally, when the build is published with the whole module, it can do another scan, as well. These three scans have their own pros and cons. The policy scan, which is a build scan, does the scanning on an overall basis with regard to the different standards out there, like OS and Spin5. It scans the first-party and third-party code, which is the most holistic scan that there can be. But the point is that it scans at three different integration points or stages, so it helps developers to remediate their vulnerabilities before they have moved far in the pipeline. Shift-left is definitely possible through Veracode.

Veracode's false positive rate is a little toward the higher side. We understand that Veracode doesn't have the business context. I advocate that people look at their code, even though there is a vulnerability, to see exactly what it is. For example, a randomize function is being used to create an ID that is not being hashed. Veracode marks it as a false positive because it doesn't know if the ID is being used for cookie generation or some random ID in the log generator. We, as dev or sec people, have to go in there and analyze what the ID is being used for. But the false positive rate is definitely a little bit on the higher side.

The effect of the false positive rate on developers' confidence in the solution depends on the maturity level of that particular application team with respect to learning Veracode. In the initial stages, obviously, when developers see that, whenever they're writing code or pushing a build, there are a bunch of vulnerabilities, it may affect their confidence. But a couple of months or a couple of quarters down the line, when those same developers have already used Veracode and have raised their maturity level from one to at least three, it doesn't really affect them because they know that they have to go in there and check the vulnerabilities for themselves to determine if it's a false positive or a real vulnerability.

It has definitely taken a little more time to validate the false positives, but I would say there are a lot of true positives, as well, which have been remediated and which have been mitigated for the betterment of the security posture. But it has definitely taken a little more time to mark or validate those positives. Hence, I definitely advocate that people shift a little more to the left. They should do ID and pipeline scanning before they hit policy scanning because, with ID and pipeline scanning, you scan small chunks of code. You remediate that code faster, before it goes to the whole package and there's a bunch that you have to deal with.

Also, container security is slowly becoming a prevalent part of the development realm. Veracode's SAST, DAST, and SCA are pretty good with respect to industry standards, but with regard to container security, they are in either beta or alpha testing. They need to get that particular feature up and running so that they take care of the container security part.

In addition, there is a new concept out there, the IAST, which is interactive assessment security testing. It is a little more proactive than SAST. So if Veracode can combine that feature with their current technology, they would definitely be a front-runner again for the next five to six years.

I've been using Veracode for the last three and a half years.

Once or twice a month there is maintenance on the Veracode side because they're updating some signature in their database or something else. I have seen maintenance coming up, but it's not an issue because the pipelines and integrations that we are running keep on running in the background. It's just the GUI that we are not able to access at that particular time.

It's pretty scalable if our enterprise has the licenses for scaling the applications. I haven't faced any issues with regard to scalability, apart from licensing, of course.

We have contacted Veracode's tech support a bunch of times. The only downside is the time needed to schedule a consultation call with the pro services team, keeping in mind that enterprises need to buy pro services licenses before they can use it.

When someone is scheduling a meeting with them, the issue type should be as precise as possible. In that way, they can rope in the exact SME for that particular topic, because in the development realm there are so many languages and so many types of issues out there. There are different personnel for each of those categories. So the more precise the details are for the meeting, the better the SME will be for that particular consultation.

Positive

We have only used Veracode, right from the start.

The initial setup was pretty straightforward. They have a SaaS solution and there are a bunch of API integrations that made it pretty straightforward.

As for maintenance, all the upgrades and updates are done on Veracode's side. But there is a wrapper. When we are doing the integration, there is a package that we use to upload the files in Veracode. Sometimes there is a new release for that package and we have to update it in the GitLab repo. That's the only maintenance we need to do.

They have made it worth the price with the kind of discount and the kinds of modifications they made for us with regard to licensing. Previously, it was per profile. But they have adjusted according to our requirements because we are a big company and we handle a lot of applications. There's a tiered discount that they have provided us, so the cost is justified.

If someone looking at Veracode is concerned about the price, it depends on their requirements. I wouldn't really recommend Veracode for a small firm, because it might be a little pricey for them. But for a large organization, with more than 1,000 applications in the enterprise, there are tiered levels of pricing. Obviously, there are other cutting-edge solutions that have become available recently, but Veracode is something that a big organization should look at.

When it comes to managing risks, we use the remediation feature that Veracode has. Whenever there is a flaw, we do have tickets open up for it and the application owner or the developer goes through the vulnerabilities. There are times when the vulnerability is a false positive and you can mark it as such within the Veracode platform itself. And we, as security professionals, do the validation for whether the business justification is good or not. And we either have a source code review for the vulnerability or have an exception open up for the remediation step that the application or the owner is asking for. We do risks via the platform, as well as through the ticketing tool that we use.

We are also using SBOM (Software Bill of Materials) for inventing all the different kinds of modules and libraries that we are using for an application. Using the SBOM feature, you would have to leverage the API to get the inventory from the API calls that Veracode has. But in our organization, we use the GUI report generation more than the SBOM report because there is an executive summary in the GUI report with regard to first-party and third-party flaws. It also has the mitigation steps. SBOM would only give you the list of softwares, libraries, and versions that are being used. It is not as detailed as the GUI report that Veracode provides.

Things to consider when looking at Veracode include the different integration points where you want to integrate Veracode, how big your organization is, and how many applications you want to do security analysis on. If it's a big organization, Veracode is obviously a solution to evaluate, but for a small organization, below 500 apps, it might be a little pricey. Also, you will need a couple of Veracode champions on your team who know it inside out. You will need training provided by Veracode, so make sure that is included during the procurement stage. That will help you implement the tool within your organization faster and much more efficiently.

I would have given Veracode a nine out of 10 a couple of years back, but given the tools that are coming out on the market, and the scope of development, which is increasing, I would place it at eight.

We use it primarily for our application security concerns. We use the dynamic, static, and SCA scanning tools. We run our static scans after the code is compiled, and that gets uploaded automatically through our DevOps tool. We have installed an agent in one of our cloud servers that is behind a firewall to run the dynamic scan against the runtime. We run our SCA scans when we do the static scans, which is after compilation.

Prior to using Veracode, we hadn't really looked into security features or thought about security in the same way that we have since we started using Veracode. We were focused on what you hear about in the news, such as making sure that it is HTTPS secured. We hadn't really dug into the nitty gritty of application security and scanning our source code, running it against a runtime environment, and looking at the actual third-party solutions that we integrate or use in our code. Veracode has helped with our mindset as an organization to start thinking about things more securely by design rather than as a reactive measure. We're being more proactive with security.

Veracode's integration with our continuous integration solution is what I've found to be the most valuable feature. It is easy to connect the two and to run scans in an automated way without needing as much manual intervention.

We feel very confident about Veracode's ability to prevent vulnerable code from going into production. Having the stamp of approval helps not only from a marketability standpoint but also from an overall good feeling within the organization that we're doing our part to help keep our code free from vulnerabilities.

This solution provides visibility into application status at every phase of development. It goes from compiling the code all the way to running it in production. It covers all major aspects of the SDLC. We run static scans and SCA scans early on in the process to make sure that we catch any code that is insecure by design. If we are able to catch it earlier on, before it's actually out in the production environment, it reduces costs. The dynamic scans are run further along in our QA process. That is, once we've deployed the code and have it in a runtime environment, we run weekly scans in a dynamic environment against the code runtime to make sure that there aren't any new vulnerabilities that got introduced. We are looking at doing manual penetration testing in 2023, where we would be using a spinoff of the code that was released to the customers to make sure that there aren't any holes through which a nefarious actor could get in and exploit what was built.

Veracode's false-positive rate is low. The few instances when it looked like there were false positives, the issues were found to be either true vulnerabilities or things that were that way by design. If a developer thought that there would be a ton of false positives when using the tool, it would then diminish the value of actually using the tool. Veracode touts itself as being a tool with the lowest false-positive rate in the market. It gives inherent confidence in the tool itself, and developers are more inclined to think that if it found something, it's pretty likely that it is not a false positive. They would then work to prove it wrong rather than discounting it without even looking into it.

We haven't really found many false positives with static analysis, and there hasn't been a significant impact on our time and cost related to tuning, leveraging data, and machine learning.

Continuous integration linking definitely saves a lot of time because it takes away the step where a developer needs to manually upload the code every time to do a scan. It can run in the background, and having the Visual Studio plugin includes it directly in the development environment. If developers do get assigned a bug that they need to fix, they can pull it right up in their development environment and not have to log in to the portal. It will all be right there.

I'm primarily the one who has been involved in DevSecOps, and Veracode has definitely reduced my time. If we had gone with a conglomeration of open-source tools, it would've taken me a ton more time. Whereas with Veracode, all the documentation is out there, and I'm able to integrate everything that I need from a usability standpoint. I don't have to learn a new tool every time I need to integrate a new security scanning option. It has helped me tremendously and has saved me a lot of time.

I do expect large applications with millions of lines of code to take a while, but it would be nice if there was a possibility to be able to have a baseline initial scan. I know that Veracode touts that there are Pipeline Scans that are supposed to take 90 seconds or less, and we've tried to do that ourselves with our ERP application. However, it actually times out after two hours of scanning.

If the static scan itself or another option to run a lower tier scan can be integrated earlier on into our SDLC, it would be great. Right now, it takes so long that we usually leave it till a bit later in the cycle, whereas if it ran faster, we could push it to the time when a developer will be checking in code. That would make us feel a lot more confident that we'd be able to catch things almost instantaneously.

I've been using Veracode for a little over a year now.

I haven't had any stability issues, bugs, or glitches.

The scalability is really good. I recently added to the solution some new applications that I learned about late in the game. There were probably 10 that I had to add in rapid succession and scan as well. It was very quick and painless.

Veracode's technical support is very responsive, and I've heard back within 24 hours regarding a couple of issues I've entered. We have actual consulting calls, which are a scheduled event, and I like the way they handle those as well. I have nothing but good things to say about them and give them a rating of ten out of ten.

Positive

I was involved with the initial setup of Veracode, and it was straightforward. We had a third-party vendor who was evaluating it, so a little bit of the setup was done. However, adding a new application to the tool is easy and self-explanatory. It doesn't take much time at all, and the documentation is out there if we need to look up anything.

We implemented it with the help of a third-party vendor. They had two people on their team who were working on the deployment along with me. My responsibilities included adding all of our software to the tool to run scans against it, integrating it with our DevOps solution, discussing the tool itself with internal stakeholders as to how they can use it and showing programmers how to use the tool from an internal adoption standpoint.

I know that Veracode is a semi-pricey solution. If you are serious about security, I would recommend that you use an open-source option to learn how the scanning process works and then look into Veracode if you want to really step up your game and have an all-in-one solution.

We evaluated a couple of open-source tools such as Snyk and SonarQube against Veracode with the help of a third-party vendor. We didn't use any of those and landed on Veracode because of the Veracode Verified seal. This, along with Veracode being the market leader, gave Veracode an edge over the others.

The main difference between Veracode and the solutions we evaluated is that Veracode is an all-in-one solution. Though an open-source solution would've been more cost-effective, we would've had to use a bunch of different tools. It would have required more knowledge to do the integration piece and would've taken a lot more time and effort. There would have been invisible costs associated with it just by the virtue of time. In comparison, Veracode's dynamic scan, static scan, and software composition analysis are all in one place.

My advice would be to look at the open source tools out there and see how far along you are in your security journey and what your needs are. If you're looking for the best in the market, Veracode is a great option, as far as paid solutions go, because it's a one-stop shop. If you have more time at your disposal and you don't mind integrating some solutions, then I'd recommend an open-source tool. However, if you have the resources, I would definitely recommend going for Veracode.

On a scale from one to ten, I would rate Veracode at nine.

We use Veracode for static code analysis of our applications in two main ways: reactively and proactively. For the reactive approach, we run automatic scans nightly after developers merge changes from feature branches into the release branch. Proactively, we use the Veracode Greenlight plugin, which checks for vulnerabilities when developers try to commit code, even on feature branches, only allowing commits after passing these checks.

I appreciate Veracode's SAST and SCA features, which help to find open-source vulnerabilities. I'd estimate it's about 98% accurate, though some false positives occasionally exist. Our team has been using it for a long time. 

We sometimes use the free access to the tool's application security consulting team. We reach out to them when we've tried to change our code based on its recommendations but still can't achieve 100% green status. They help us fix issues in real-time through screen sharing and development work.

We saw the tool's benefits long ago when we first implemented it. Security is a top priority for us when working for a bank. We recognized the solution as one of the best tools in the market and decided to integrate it into our pipeline. We set up quality checks in our pipelines so that any code with high or critical vulnerabilities can't even be deployed to the development environment. This proved helpful for our team. Now, we have a quality gate that checks the Veracode status before any code goes into production. If Veracode scanning shows no vulnerabilities, the code can only be deployed to production. We strictly follow this process and have made Veracode an integral part of our Software Development Life Cycle approach.

Veracode has also helped us save time, especially with its proactive approach. The Greenlight plugin works directly in our IDE and is particularly helpful.

The solution should include monthly guidelines, a calendar, or a newsletter highlighting the top vulnerabilities and how to resolve them using Veracode. Its  policies should be up-to-date with NIST standards and OWASP policies.

I think if it could be enhanced with AI capabilities similar to Copilot, it could be even more beneficial in guiding developers and catching potential issues early in the development process. The solution should also come up with docker images. 

I have been using the product for six years. 

The product's support is good. 

Positive

The solution's deployment is easy. 

I rate the overall product an eight out of ten. 

We have some applications that connect to external providers or provide external services that users can access from the public internet. We are uploading these applications to Veracode to assess the security threats that our code may pose.

Veracode's analytical capabilities are very good, but I'm not sure if they have prevented security vulnerabilities from going into production in our case because we haven't been using them optimally. We're now working on integrating them into our development pipeline so that we can test applications before they're released. This will also allow us to familiarize ourselves with the sandboxes during development. I believe that if we start using Veracode correctly, it will be very beneficial in preventing security vulnerabilities from going live.

The main benefit of Veracode is the software composition analysis because it helped us identify that we were using some libraries with security flaws. This is important because the individual software components are owned by different smaller teams, and all of those teams contribute to one overall large application. Therefore, there is no single person who would be able to take care of all of the third-party libraries that we are using. Veracode analyzing the libraries that we use is therefore beneficial to us.

Veracode's policy reporting for insurance compliance depends on how our organization uses it. I'm not sure if we're using it to the best of our ability because, for example, I discovered that there is a central space where we can run analysis and sandboxes. Based on what the Veracode expert I spoke to told me, policies should be reported from the danger space, but in our organization, we're reporting them from the Prod CI sandbox. This doesn't seem to be a good solution because the overall application is displayed on the main page, which doesn't reflect what our compliance teams think about our applications. Besides that, I think it comes down to how we're using Veracode within our firm. Overall, I think it's great that the firm can configure certain policies to monitor applications, and the flaw report also enables us to see the flaws that need to be fixed to become compliant, which is a good feature. From Veracode's perspective, everything looks fine.

Over the past year, we discovered a severe security flaw in Lot 4j 1.2.15. We initially believed that this version had been replaced with a newer version that does not have the flaw, but our software composition analysis reports revealed that this is not the case. We still have a few binaries that depend on Lot 4j 1.2.15, which is vulnerable. The software composition analysis results prompted us to schedule a replacement with a new version, which is currently underway.

Veracode has helped us fix flaws effectively. Our security teams enforce monitoring and fix deadlines for reported flaws. If a reported flaw cannot be accepted as a false positive, we must fix it promptly to maintain a high success rate.

Veracode has improved our security posture and will continue to do so as we learn to use the solution more effectively.

I like the way the flaws are reported in the system. It is quite clearly visible where the flaw is coming from, and it is possible to upload the code to see exactly which line was identified as a security threat. I also like the software composition analysis that Veracode provides, because we can see third-party libraries that are used in our software and check if there are any known security flaws in those libraries.

There are many false positives, especially one particular type: reported hard-coded passwords in the code. We do not have hard-coded passwords in our code, but we are using third-party libraries that have variables with passwords in their names. For example, a variable might be named "passwordForCommonFixFile" or "passwordForSecurityStore." Veracode's keyword analysis probably assesses these variables as hard-coded passwords. This is problematic because the false positives are coming from third-party libraries, and we cannot easily check the flaws to see if they are false positives. To fix the problem, we have to compile the code, which we should not have to do. We are forced to accept the false positives because we know from the software and system design that there cannot be hard-coded passwords in the third-party libraries we are using. If the libraries were generic, then there would be no chance that they would have hard-coded passwords for the specific services that we are connecting to. To reschedule the scan, we have to go through some bureaucracy. 

Despite the presence of many false positives, we remain confident in Veracode. However, the impact on developer confidence is negative, as it leads to resistance to enforcing certain development processes, including the use of Veracode in the development pipeline. This is understandable, given the complexity of the process required to reschedule the flaw for a single false positive. This process requires approval from the system owner, a senior manager, and the cybersecurity team.

Veracode has increased the work time of our developers because of the false positives.

The area with the most room for improvement is the speed and responsiveness of the query, as it is usually very slow. I am not sure if there is a specific space allocated for us that can cause this, but when I open an application and want to click through multiple scans to see the differences, or if I want to do anything else, everything loads very slowly. This makes it much less user-friendly to play around with the GUI and explore the features.

I have been using Veracode for three months.

Veracode is stable but a bit slow.

I have only one experience with Veracode support, but it was very positive. I used the schedule consultation feature in the GUI, which was very useful. We had some questions about how to correctly upload a code, and I was able to schedule a call with a Veracode expert. The support person who helped me provided me with many insights, answered all of my questions, and even went beyond what I asked to explain how to use the feature and improve our process.

Positive

The initial deployment is complex because our system is huge, consisting of hundreds of different binaries. Dozens of teams contribute to the releases, and as a result, a large number of changes are deployed at the same time. This makes it very easy to break something, and there are many people involved in the process.

The deployment required a core team of five, with some additional people on hand to support if anything went wrong. The maximum time for deployment was one day.

I give Veracode a seven out of ten due to the slow speed and the false positives.

We only use Veracode for static analysis. We do not use the other features at all.

We have infrastructure deployed in multiple locations around the world. In my team, 50 people use Veracode. Across the entire organization, it is used by hundreds, if not thousands, of users.

I advise everyone to use Veracode in their development pipelines, so that scans can run very frequently, at least once during each nightly build. This will ensure that reports and flaws are addressed effectively. From my development perspective, I recommend against enforcing specific rules on using Veracode, giving deadlines to fix flaws, or introducing additional bureaucracy. This can worsen the developer experience and lead to developers finding ways to avoid having flaws reported, such as by decreasing the frequency of scans. In my opinion, the more processes and bureaucracy we add, the less useful Veracode will be. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

It helps indirectly with Webex.

I would rate the solution as eight out of 10.

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

It's a SaaS solution.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We use it for 10 critical applications.

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

Positive

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

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

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

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

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

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

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

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

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