Veracode Reviews

My company produces one of the most secure fabrics that you can find. Veracode is integrated into our development cycle through Jira. We do a full static analysis with Veracode and use Burp Suite to review the findings. The most common attack vector we find in Java code is SQL injection. When SQL injection shows up, you send a screenshot and a report to your executive team. They see the screenshot and say, "Oh, they're seeking injection here." 

This has now become a top priority. We're going to pause all these redundant features that we're making here and ensure our code is secure with no SQL injection vulnerabilities. Veracode finds everything, and the security engineers do the penetration test using the results. You provide a report showing where the issue is, and developers can fix it. We also use Veracode to train security engineers and teach them how to file reports.

My case is different from other individuals. I worked for a startup, so we had to find a way to capitalize on all the resources in Veracode. Larger organizations are not leveraging the built-in dashboard. That aspect is what people want to know about. They want to see how their money is being spent on security. The biggest problem with security is getting funding. None of these executives believe anything these users are saying until they can see the results.

They want that dashboard report. In less than three weeks, a junior security engineer can learn to create a dashboard easily that will allow the organization to stay on top of the most important things. They need to show the stakeholders that we're doing something here. They'll get the certification and see the dashboards. You now have something that's actually worth $2,000. With these other ones, who knows what you'll get. 

It allows us to provide a certificate showing stakeholders and potential customers the proof that we take security seriously. Everyone says that they're on top of their security and have all these things in place. In a sales call, we can immediately respond to any questions about our security posture by pointing them to a link showing that your company was among the few companies that completed the full certification process. Veracode has four levels of certification, and we are at level three, I believe. 

To my knowledge, Veracode is the only real devSecOps pipeline that captures every component of the software delivery cycle, from sandbox and staging to development and production. You need to go through those four phases and ensure the code is secure by the time it hits production. Veracode handles all those phases seamlessly and can be automated with Jenkins.

Veracode is highly efficient at fixing flaws. A single person can go through and do a penetration test after collecting the data from Veracode. Instead of telling developers where the issue is, they can show them in the code editor for the static analysis. They can assign tasks to the team using Jira, so developers almost never need to do that work. They actually almost never go back and fix any of these vulnerabilities. That's why I was my company's most hated and most loved man. I forced them to do it.

I like Veracode's API. You can put it into a simple bash script and run your own security testing from your MacBook in less than 15 minutes. Veracode's application security consulting team is very helpful. They're responsive and follow up quickly. 

Veracode would benefit greatly from more training resources. The videos are great, but I would like more hands-on training writing a script, validating a script with a unit test in a different language, etc. That's something that would be very valuable. 

We have used Veracode for more than four years.

Veracode is highly stable. It very rarely crashes. 

I rate Veracode support 10 out of 10. Their customer support is incredible. If I have any issues, I can immediately connect with their support team and have a real working solution within one week.

Positive

Deploying Veracode is easy. I had the best customer success manager at Veracode helping me. After deployment, Veracode requires little maintenance. 

Veracode is inexpensive and cost-effective. The licensing model is unambiguous. You know what you are getting. They also give you several seats for training. That's why it would benefit them to improve the training because more people could take advantage of it and use certifications. Some certifications for other products don't have much real value, but Veracode is a product many companies use, so it could help people get jobs.

If you're concerned about the cost, you should meet with a representative to talk about pricing. Veracode is flexible, and they're willing to let companies try the platform or test different features. They will work with companies to get to the point where they'll use it.

I used JFrog X-ray with homegrown scripts for testing the code. It was terrible. We chose Veracode because it is more scalable. We could run scans on any code, and it was reliable. Also, their documentation was up to date. With other software providers, you would find an issue in the documentation, and they would backtrack, saying, "Oh, no one's using that." 

Veracode immediately responds to the community. You have people in the community supporting each other and suggesting new features. Software providers say they're open to suggestions. Veracode will quickly get something from the community and immediately put it into development. JFrog has the same stuff as they did four years ago. They haven't changed anything. 

I rate Veracode 10 out of 10. Veracode is constantly changing and improving. 

We are using Veracode to shift development left. Therefore, we want to train our team of third-party vendors and improve our code security.

Veracode has been effective at preventing vulnerable code from entering production. I can easily enable the support team. Additionally, the reports are free. Although we are at the beginning of our journey, I can see that Veracode is capturing vulnerabilities.

The cooperation between the security team and the development team is improving, and our security team's visibility is increasing. As a result, we are achieving better and better results, and Veracode is helping to improve our security posture.

I am using Veracode's preconfigured policies because I find them useful and complex.

I am satisfied with Veracode's visibility into application status at every phase of development.

We can see that false positives are quite low, around five to ten percent.

We can add notes to any false positives during static analysis testing so that our developers can see the notes and avoid wasting time on them.

Veracode's reporting function and executive summary help us emphasize the security of our business-critical products to our business, which also helps us get sponsorship from our management to fix flaws and move forward.

Veracode helps our developers save 10 percent of their time by identifying security flaws early in the development process. This allows us to fix the flaws before they go into production, which is more efficient and cost-effective.

Veracode has helped us improve our security posture.

The admin ID can be downloaded into Visual Studio, for example, and developers can use that directive without having to type code. I think this is the best feature of Veracode.

The integration of static testing with our Azure DevOps CI pipeline was easy.

Veracode's support could be better. It is limited and slow.

The security labs integration has room for improvement. Currently, it is not possible to see the security labs training reports on the dashboard. These reports are only available separately in the security labs platform. I think that adding the dashboards for integration would be a good area of improvement.

I have been using Veracode for almost six months.

Veracode is stable.

Veracode is easy to scale.

Technical support needs to improve its response times and the details of its responses.

Neutral

The deployment was somewhat complex because some of the documentation was outdated, which caused some problems. There was confusion about how to implement the static pipeline scan. It took some time to find the correct articles and speak with the support team to implement Veracode.

The deployment took a couple of hours and required one DevOps and one tech person.

Veracode is fairly priced.

Before selecting Veracode, we evaluated SonarQube and Codacy. We chose Veracode because of its comprehensiveness and its ability to provide us with a solution for each phase of the software development life cycle. Veracode offers both dynamic code analysis and static code analysis solutions. With Veracode, we were able to get everything we needed in one place, without having to sign contracts with multiple vendors.

I would rate Veracode eight out of ten.

We deployed Veracode in one location and have ten users.

I recommend Veracode based on the script language being used.

We use Veracode to scan server applications, and we also use it for SCA functionality and to scan pipelines of our other projects.

The quality of our code is much better now with structured utils meant for improving various topics related to security. Those are being applied consistently to various modules of the application. It enforces a type of structure and code changes to support future transformation.

False positives are a problem. Sometimes the flow paths are not accurate and don't represent real attack vectors, but this happens with every application that performs static analysis of the code. But it's under control. The number of false positives is not so high that it is unmanageable on our side. Once they are identified, you can mark them as false positives, and they can be accepted by the security project lead. After that, life goes on, and those will no longer be reported.

The problem is the time that you spend analyzing a flow to be sure that it is a false positive. Every problem that is reported as a security vulnerability has to be treated with maximum care by the developers. It is good, in the end, when it's a false positive instead of having a real vulnerability.

Because we are working on a huge application with lots of dependent sub-projects, there are 9 to 20 data paths. We have to check all of the vectors from all of these paths. If we decide that an attack vector might be susceptible to that attack, we start fixing it. But for the others, the attack vector is not relevant.

There is always room for improvement in any product; it's not something related specifically to Veracode. But in the case of Veracode, maybe they could improve the scanner to reduce the number of false positive events so that they remain only with the valid data paths that represent real attack vectors. We understand that this is quite hard to determine by just scanning the code.

Also, the UI of Veracode could be improved to permit better visualization of the issues and the grouping of the issues, with better filtering.

We have been using Veracode for four years.

We have seen delays in results on the order of hours, but there haven't been any crashes of their scanner. The solution is quite reliable, and all of the results from the scanning can be easily tracked in terms of time frame. You can see how your scanning has evolved, and there are no deviations due to a bug in the scanner.

For small and medium-sized projects, it's quite scalable. You can use the sandbox scanner they provide, and it is fine. But for large applications, it is not scalable. We do manual uploads, and this is not scalable.

We haven't called their support because we know how to interpret the results provided by their platform and how to mitigate the vulnerabilities that they have reported.

However, we have exchanged several emails to discuss some technical details of the solution that we applied it to, and everything was straightforward. There are no complaints from my side regarding what they said. Everything went smoothly and quickly.

Positive

We have used certain plugins from Teamscale, which is also a static code analyzer, and it integrates with various plugins in Sonar. We have also used OWASP for static composition analysis, and we are still using the third-party application scanning from OWASP as a Maven plugin. We have also evaluated Black Duck.

Veracode was the first choice for doing static application security testing. It was ranked first a couple of times in the last few years, so it was a natural choice to go with the top product. Also, SAP has a partnership with Veracode for the application that they are selling. It was a win for us, SAP, and for Veracode.

It took us one day to get ready to use the solution. We built the image and copied it during the night to several machines. The following day, we were ready to put it into the container registry in Azure, and then it could be used. We had a huge procedure and scripting. It was not simple.

The team that did it had about six engineers involved.

It is an expensive solution, but it's the best solution available on the market. If you want something at the top, you have to pay a bit more than the average.

Regarding extra expenses, it depends on what you want to buy. They have certain bundles that provide support via a hotline system with customer service. They can provide you access to certain security laboratories. You can opt for several licenses to educate more developers to be responsible for the security of your applications. All of these change the initial cost.

Of course, if you add more things, you can benefit from a better price. It depends on your negotiation skills and the number of licenses you want to buy.

The price can vary from year to year, and prices usually go up. Maintenance for the servers that do the scanning takes money, as do CPU, power, and memory. And there are the reports that are kept in the history for checking and for ISO certification. Those costs build up during a year.

For example, we have to manually upload the application that we are scanning because it's quite big, and it takes one day to be scanned. That means their scanner runs for a day on this application, and then we get the results back. That means our application is heavily consuming resources of that cloud server. Those resources are no longer paid for directly by us. We delegate this job to Veracode to do it for us, and we pay for it. But we free up our servers locally and can do other jobs with them.

We aren't trying to reduce our costs. We are trying to improve the security and quality to be sure that we and our customers don't have security issues. At the end of the day, security is the most important part. With every new release and with every new year, we allocate more and more to these operations, to improve our overall security.

Not every such application is able to prevent everything from going to production, but several issues can be spotted via the scanning of the code and resolved, and they are valid. There are many others that can be detected with additional tooling from OWASP, Sonar, et cetera.

We are not using the SBOM functionality from Veracode. We use another tool to create the software bill of materials. That solution is also able to scan Docker images, and it also provides details about what is inside the layers of the Docker image file.

In terms of visibility into application status at every phase of development, it depends on how able you are to scan your application. For large applications, you have to do manual uploads, which is the case for us. We don't do manual uploads on every build, but we trigger it at certain times when we want to create releases for customers. That helps with our accuracy, but it doesn't represent the exact moment when there is a problem in the application. We still have to analyze the commits and history, track things, and match them with the new flaws that have been found in the latest report.

Veracode doesn't save us time. We have to spend a lot of time fixing security issues, especially those that impact lots of dependencies, dependent code, and sub-projects. But in the end, we can sleep well at night knowing that we have closed a possible security leak within the code, which is better for everybody. Even if there is no real problem at that moment and you don't see any probability of that vulnerability appearing in production, it is better to take some time to fix it, and then you feel better.

It has provided what we were looking for in such an application, meaning static application security testing functionality. That was what we were interested in.

We use Veracode to test for errors in the code in the applications we are building within our service pipelines.

Veracode assists in preventing vulnerable code from entering production. It is essential to ensure that our applications entering production are free from errors.

It has assisted our organization by providing a report that we can share with our developers, identifying vulnerabilities in their code. This enables them to address the issues before the code is put into production.

Ever since the implementation of Veracode, I have noticed that the processes for rectifying the issues in our pipelines have become much easier.

Veracode helps our developers save time. The solution has simplified the coding process for our developers.

I would rate Veracode's impact on our organization's overall security posture as nine out of ten. The solution has been beneficial to us daily, and we haven't encountered any issues with their solution so far.

The capability to identify vulnerable code is the most valuable feature of Veracode.

There are times when certain modules cannot be scanned automatically, requiring us to manually select these modules and initiate the scanning process on our side.

The vulnerability report has potential for improvement and should encompass more detailed information about the vulnerability, rather than solely identifying it.

I have been using Veracode for three years.

Veracode is stable.

I believe Veracode is scalable, but I am not certain.

I rate Veracode a seven out of ten.

I recommend Veracode. The solution only requires a one-time configuration into the pipeline and the testing is done automatically. 

Integrating Veracode with our pipelines is an easy process. We simply use VML files and the integration is done automatically for us.

We currently have approximately 55 microservices, composed of various teams. Altogether, there are about 170 people utilizing Veracode.

I recommend becoming as familiar as possible with Veracode before using it. Even watch online tutorials to ensure that the deployment goes as smoothly as possible.

I have helped other companies implement Veracode Static Analysis in their IT environment. In our company, we need to scan many .NET applications using Veracode, and we could scan our software since it is a SaaS solution, after which we process the reports to improve the product.

The most valuable features of the solution are its extensive reporting capabilities and user-friendly interface.

There are certain shortcomings in Veracode's static analysis engine. I would improve Veracode's static analysis engine to make it capable of identifying vulnerabilities with low false positives.

The product is good, and if improvements are required, then such improvements should not be significant enough. There may be a slight scope to improve the product's integration capabilities. The product can also consider improving its support of different .NET versions and other programming languages, like Java.

I have been using Veracode Static Analysis for three or four months.

Our company faced some issues with the tool, but the support team solved these issues quite quickly. The stability of the tool is high. Stability-wise, I rate the solution an eight out of ten.

It is a scalable solution. We can implement the tool in different DevOps environments and projects, because of which we can create groups of applications and apply different policies to application groups, making it an enterprise-level tool. Scalability-wise, I rate the solution a ten out of ten.

The solution's technical support helped us solve different problems related to Veracode, including some of its use cases. Veracode's support helped our company get around a problem and how to set up the scan rules correctly when we had some unexpected errors during the scanning process. I rate the technical support a nine out of ten.

Positive

I have experience with Snyk. I used Snyk a year ago. Snyk doesn't support the version of the .NET applications we use in our company, so we decided to move to Veracode.

The initial setup was easy since it is a SaaS solution and a well-documented product at the same time. In our company, we don't need to spin up a server to install something since we simply use the web interface and integrate the web interface with the DevOps environment.

On a scale of one to ten, where one is a hard setup and ten is an easy setup, I rate the initial setup phase an eight or nine.

The solution is deployed on the cloud. In our company, we use Microsoft Azure DevOps for our environment, but I don't know the environment in which Veracode gets used in our company. Veracode offers a web interface and API, so I don't know their cloud solutions.

The deployment is quite fast, but its overall quickness in terms of deployment depends on the number of applications you want to scan. If you want to scan one application, the deployment can be quickly done since we need to integrate Veracode into our DevOps environment.

The pricing of the product depends upon the number of codes or the number of applications.

I recommend those planning to use the solution check the system requirements and choose a solution that supports programming languages and .NET Framework versions that record scans.

I am not sure if it is one of the best solutions because I am not an expert in other solutions available in the market. Somehow, I personally feel it is one of the best tools in the market.

I rate the overall product a nine out of ten.

When we develop an application with source code built on Java, JavaScript, and mobile technologies such as Android and iOS, we ensure that the source code is free from security vulnerabilities before sending it to production. To achieve this, we package our source code and scan it using Veracode. This scanning process is our primary use case.

We set up pipelines for this purpose, and the warehouse operates on a cloud provider. To make the Veracode API calls for support, we utilize Veracode API libraries which use the URL that is hosted on the cloud. We then initiate a scan on our source code, which goes through different stages, including scan, upload, rescan, validation, and finally, we obtain the results.

Veracode provides visibility into the status of applications at every phase of development to a certain extent. Veracode scan reports present a comprehensive view of planned releases that are scheduled to go live in the coming days. To keep the team informed, we run a scheduled deployment, sending email notifications twice a week for each application. This alerts the team to any issues that may need fixing. However, it's worth noting that the system is not fully integrated into the pipeline and notifications. Nevertheless, Veracode offers an API. This interface allows us to obtain the XML result file, and subsequently, I can extract and analyze the values from the XML. Once the scan is complete, Veracode API will fetch the XML report and store it in my workspace within the pipeline. From there, I can execute an XML parser function to obtain the application status results.

Veracode has been helpful in reducing our developers' time by around fifty percent. For an application to meet internet safety standards, the code must achieve the VL4 level in Veracode. According to Veracode reports, our developers can focus more on resolving the issues rather than trying to identify them.

The most valuable feature is the seamless automation of Veracode via the pipeline, in comparison to other solutions like Fortify SSC, which are complex to integrate through the pipeline. Although there is a lot of coding involved in writing each end, Veracode breaks the process down into multiple steps. We first package our source code and upload it, after which a pre-scan is conducted. If the pre-scan identifies any files that don't conform to the Veracode format, it will display a warning or prompt us to correct the issues before proceeding. This allows us to have programmable control; in fact, we can program Veracode so that after the upload is completed, it automatically scans the files to check if they are all in Veracode format.

For example, my ZIP file contains a hundred files. Out of these, ninety files meet Veracode's criteria, while ten files are incorrect. I can instruct Veracode, through pipeline automation, not to wait for manual action and continue with the scan or upload the scan results. Veracode can automatically proceed with the selected files in this scenario. All of this can be controlled programmatically. Furthermore, once the scan report is generated, it becomes available in the workspace, and we can send an email with this report as an attachment. This type of report is referred to as a detailed Veracode report and can be customized. Typically, we prefer the customized report, while some developers may also opt for XML reports. The ability to manage this sequence of steps in the Veracode scan is programmable and can be handled accordingly.

Veracode's false positives have room for improvement. For example, if there is an applicant named ABC in Veracode. I have uploaded my Java file, which contains a hundred lines of code. I suspect that the ninetieth line includes a hard-coded password. Thus, during the scan, it will identify the presence of a hard-coded password on the ninetieth line and suggest how to mitigate and resolve this issue. In the next scan, I added fifty more lines of support and fixed the password-related problem. However, the line containing the password is no longer at the ninetieth position; it has moved to the hundredth line. Despite these changes, the next scan still detects the password flaw. Even though I encrypted the password and added the required string, the issue continues to be flagged. This constant flagging of the issue, even after resolving it, is one of the major drawbacks. To overcome this problem, we decided to create another application. This action was taken to prevent the recurrence of such issues. In the future, when I have a release in the coming months, I cannot keep encountering this problem repeatedly, as it still flags the issue as long as the code is in a different line. We have spoken to the vendor several times about this issue and scheduled a work order consultation call, but we did not receive a response.

In order to achieve software consolidation and analysis reports for Android applications, we need to utilize a third-party utility called SourceClear along with Veracode scanning. This complicates the market and has room for improvement. 

When scanning a file that is over one gigabyte in size, there is a high chance that Veracode will continue scanning. When we initially encountered this issue and investigated it, we raised a ticket. As a result, a Database Lock occurred, causing Veracode to become stuck.

I have been using Veracode for almost four years.

I would rate the stability at seven out of ten, considering the false positive issues we are experiencing.

Veracode is scalable.

I am not entirely satisfied with the technical support because I believe we have been waiting to send our code to production and waiting for an update from the vendor to resolve the issue. When we raise a support case, there is no response, and even after it happens two or three times, I don't know if they read the details of the issue when a ticket is raised. If someone has already attended to the same call, they will not attend again; instead, a new person handles it. Consequently, we have to explain everything all over again to the new person. We are aware that they know they don't have a solution for this problem. However, by the time we explain it to the new person, they ask the same questions again. Each consultation lasts 40 to 45 minutes, and we are billed for them, but we spend most of the time repeating what the issue is.

Neutral

The initial setup is straightforward. Even the pipeline setup is easy because there is an API, so we don't need instructions. Veracode is hosted in the cloud, so we need to set up a firewall to connect to it via proxy. The deployment took a few weeks because we had to figure out how to perform the scanning from the pipeline, enable the scan, and upload the scans for each Veracode API. Additionally, we had to seek assistance from HR to implement all the steps, which took some time.

I give Veracode a six out of ten.

We cannot simply create one policy and claim it is compliant unless all my issues are thoroughly flagged based on that compliance and the complaint. As technology improves and we move forward, bugs and certain issues may arise, and we may not always know the solutions or the severity level of their impact. Considering this perspective, Veracode is acceptable. I will illustrate this with another tool, Fortify SSC. Suppose there are newly added licenses or rules for software compliance in their security scanning tool. In Veracode, if I wish to update the new compliance tools or checks that the algorithms run against it, I must obtain approval from the architect. This approach has its advantages. However, in the case of the tool I am currently working on, Fortify SSC, there is something called a 'rule pack' for each language. I have the option to keep the existing version of the rules or upgrade to the latest rule pack. This feature works as a toggle option in Veracode.

Tuning policies is essentially the application of specific policies. When we deploy a policy, it affects all our scans and issues. The new policies applied are divided by Veracode and, when implemented, impact all the applications. Therefore, most of the time, when we apply a new policy, there is a chance that if there are three flaws, we can assume there are thirteen million flaws in my current scan. If a policy is applied, there are definitely ten to fifteen additional issues in the new scan after implementing the updated policy. Thus, there is always an increase in the number of flaws when there is a new policy update.

There are certain flaws. For example, I am releasing a package into production, and I conducted a Veracode scan against the source code, which is stored in the bin bucket. So, even if I fix the issue on my own, the same issue will be flagged again due to the change in client number. This is a significant problem because we cannot explain to the higher management that the report contains the password, and we have already taken measures to mitigate the issue. We cannot claim that this issue has already been fixed, as it continues to resurface. It is a Veracode issue, not one originating from us, but it becomes complicated when higher management sees a report indicating the same issue from the previous month. We don't know what to do. One of the ways we addressed the issue was by reducing the number of times the same issue occurs. For instance, in my previous work at a bank, we had applications specific to each country, like one for Singapore, one for Malaysia, and so on for most Southeast Asian countries. Although our master bank application was the main source, we created individual applications for each country in Veracode. As a result, the number of false positives or issues that were previously mitigated or closed and kept reappearing from month to month was reduced, but they were not completely eliminated. By switching to a different application for each country the false positives were reduced by around seventy percent.

Our organization was approached to adopt Snyk; however, it is a startup solution, and the bank prefers something that is well-established. Currently, we are using Fortify SSC. 

We have a five-person IT team that is responsible for all the DevOps tasks, including Veracode.

Compared to Fortify SSC, which has a complicated setup requiring three installations, Veracode is easier because the app is hosted in the cloud. All we need is a support license, and they will create a project for us. We can create a firewall proxy, and the API pipeline is already in place. To create a scan for another application, we simply copy and paste the code and change the application's name. 

We primarily use Veracode for static code analysis.

Veracode detects vulnerabilities. The most essential part is Veracode's PCI compliance policies. We need to make sure our code is compliant. Veracode's policy reporting features are effective at ensuring compliance with industry standards and regulations. The policy has changed here, but that functionality works quite well. It provides visibility to application status at every development stage. 

The solution helped us find and fix flaws. It ultimately saves us some time, but we still spend a long time sorting through the false positives. Every report generates a number of issues, some of which are valid. Others are mitigated by application design or network devices. Veracode improved our security overall. There is no doubt about that. 

The CSA vulnerability scanning is useful. 

The dynamic scanning feature appears to be working, however, 90%-95% of all vulnerabilities could be easily detected by any web browser.

When it comes to dynamic scanning Veracode needs to improve its functionality.

They claim that we can do this, but it doesn't work when we're scanning the applications in real time.  

Static code analysis generates too many false positives, so it takes a lot of time to review them all. The security and development teams need to work together to mitigate the false positives. It doesn't affect the developers' confidence in the solution. It still works, but it takes time. It has a significant impact on the process. 

I have been using Veracode for five or six years.

I rate Veracode support a seven out of ten. We have weekly meetings with the support representatives to discuss any issues with the tool. It's pretty good.

Neutral

I rate Veracode a five out of ten. 

We use Veracode for static web application scanning, and we've been using Vericode for our ethical hackers as well.

We have a dev, UAT, and staging environment. Veracode is included as a part of our DevSecOps in the staging environment. That means that when code is promoted to our staging environment, it automatically initiates a Veracode scan on our application.

The output and the recommendations given by Veracode are very useful. We are able to mitigate some of the vulnerabilities that the tool shows us. We are maintaining very clean applications with the help of the scanning we do with Veracode.

If any critical or high-risk vulnerabilities are detected in our code, we don't move it to production until we get a clean report. While we allow moderate and low-risk findings, we stop if it's critical or high. We do a scan on our staging whenever new code is promoted. Effectively, Veracode helps us to prevent moving the code to production if we detect any abnormalities.

Our application is an external-facing application and that means we have to proceed with the utmost caution when we promote code. Veracode has certainly been very helpful in giving us more accurate results and ensuring that our application does not have any vulnerabilities.

Veracode keeps developers aware of the possibility that issues will be identified. Once a vulnerability is detected, developers are careful to abide by the recommendations given by Veracode the next they are involved in new development. That's a positive regarding the solution. It helps improve the development process. We also share findings with the other development teams, so that they don't make the same mistake. We document the best practices so that the same flaws are not detected again. To that extent, our developers' time is optimally utilized.

Ours is a Java-based application and Veracode can detect vulnerabilities in both Angular, which is used for the UI, and also in the backend code, which includes APIs and microservices. That's one good aspect and something where other applications have a lower rating. Veracode gives us wholesome insights into the vulnerabilities in the application, both in the UI and in the backend.

Also, the false positive rate is good. I don't have any qualms about using Veracode.

The scanning on the UI portion of our applications is straightforward, but folks were having challenges with scans that involved microservices. They had to rope in an expert to have it sorted. In addition, one of my developers told me that they looked at the documentation that was given but still required the involvement of an expert to get the issue fixed. I would like the documentation to be a little more user-friendly.

Also, the turnaround times could be improved. From what I've heard, the scanning takes a bit of time to complete. If it could be completed a little more quickly, that would help.

We've been using it for five years.

There have been a couple of instances when the scan stopped or aborted and had to be manually triggered to complete. Other than that, there haven't been any challenges with Veracode

We used to have a tool called CAST, which determined code quality. It wasn't a security tool or scanner.

As an application manager, I certainly find Veracode very useful. It definitely improves the robustness of the application. It detects every single small or large flaw and helps us with the appropriate recommendations. I would go with Veracode unless there is a product that is equally capable but with a lower price.

Right now we have it on-prem but we are moving toward the cloud in the next six months or so. We've started that journey. I don't think there have been any difficulties in maintaining the pipeline. We've never had any challenges since we introduced Veracode as part of our DevSecOps pipeline.

For my application, it has definitely been a great tool. It ensures that your application is devoid of vulnerabilities. Go for it.