Veracode Reviews

We use it for static scans. It is mandatory in our company for every sort of project.

Veracode provides the organization an understanding of security bugs and security holes in our software, finding out if the software is production-ready. It is used as gate management, so we can have a fast understanding if the software is suitable for deployment and production.

My job is to help projects by getting the data integrated in Veracode. I don't own the code or develop code. In this area, I am a little bit like an integration specialist.

We use Azure and AWS, though AWS is relatively fresh as we are now just starting to define guidelines and how the architecture will look. Eventually, within a half year to a year, we would like to have deployments there. I am not sure if dynamic scanning is possible in AWS Cloud. If so, that would be just great.

The possibility to integrate Azure is very valuable because you can have every build integrated into the content integration pipeline. So, you can have every build scanned and determine when a new bug was introduced. Thus, you can keep great track of your code's security.

You can easily integrate it with Azure DevOps. This is an added value because we work with Azure DevOps. Veracode is natively supported and we don't have to work with APIs.

Third-party library scanning would be very useful to have. When I was researching this a year ago, there was not a third-party library scan available. This would be a nice feature to have because we are now running through some assessments and finding out which tool can do it since this information needs to be captured. Since Veracode is a security solution, this should be related.

I would recommend that they keep working on the integrations. For Azure DevOps, the integration is great. I am not sure what the integration possibilities are for the Google platform or AWS, but I would suggest every other platform should have this easy and great integration. It takes a lot of time for companies, so this feature is a big plus.

I have been using it for about three years.

There have been no issues at all. There has been no downtime registered.

I worked with the technical support to integrate some things. One of our private cloud providers only had old routers. It was possible only to open network connections to IP addresses, while Veracode only provided the URL in their guide. So, I asked the technical support if it was possible to provide some fixed URLs that we could give our provider since it is unfortunately against the concept of the cloud to provide the IP addresses that work just for some time. The technical support's response was within a day, and it was prompt and clear. Also, all their reasoning made sense so the support was very good. I would rate the technical support as 10 out of 10.

Positive

We also use SonarCloud, which is a code quality tool. We use both of them because both these platforms are good in some areas. While the Veracode is very good at finding security-related issues, the SonarQube Sonar suite is very good at determining code quality. Also, when I was looking into the topic, the SonarQube team answered that there is no point for them to go further into code security since there are already great competitors who have years of experience and development behind them, specifically mentioning Veracode as masters in their field. That is the reason why we use both solutions: We benefit from using them both. These solutions compliment each other.

I evaluated WhiteSource Bolt specifically for third-party library scanning, but I did not have a lot of time to create a proper PoC. I had a call with WhiteSource and told them that I would like to do a PoC, but I was not very satisfied with their support. It was like, "Just try the free solution then contact us again." However, the free solution didn't provide me enough things to make a decision. So, I just put it off until sometime possibly in the future. If Veracode offered third-party scanning, then we wouldn't need WhiteSource Bolt at all.

If you have Azure DevOps and would like to understand your code and how secure it is, then there are not a lot of better options. Also, there are not many choices in this area at the moment.

Once your code is scanned by the static scan of Veracode, you get some evaluation scores based on some criteria. For the management, when it is above a certain number, it is fine, but when it is built below, then it is no-go for production. Even though there is a possibility to create a sandbox environment for projects, they don't get it. That is understandable to me. I try to explain to them that there are no issues if you are working in a development environment and you get difficult scans. It is fine then because you can create a sandbox environment, which will not screw up or make the production releases worse because it is in a separate bucket.

We are happy using the solution. I would rate it as nine out of 10.

I used Veracode in my previous company. My role was to assist the team in identifying the vulnerabilities in the reports. I identified those and diverted them. The software team was responsible for taking appropriate actions to fix those.

We used Veracode in our environment to have account verifications or transaction confirmations. Apart from that, we had event registration as well as membership confirmation.

Veracode provides visibility into application status at every phase of development. My role was to analyze the vulnerabilities and pass them on to the software team. The severity of a risk was provided by us, and the software team was responsible for mitigating that. It helped us a lot in mitigating the vulnerabilities. We were able to proactively react to anything malicious.

It helped with early vulnerability detection and automated security testing. These were two things for which I usually used to use Veracode.

The static analysis and the dynamic testing methodologies for security vulnerabilities helped us in our development process. It allowed our developers to address issues before they became complex or expensive to fix. That was one of the things that helped us a lot.

Veracode helped us with the Log4j vulnerability. At that time, we relied completely on Veracode.

Veracode helped our developers save time. Proactively fixing the vulnerabilities saved a lot of time. It saved 50% to 60% of the time. Fixing them after the sprint is over takes more resources and time and also costs us. Veracode saved time as well as the cost.

Veracode helped us with the shift-left security strategy, but we did not rely much on Veracode for that because we already had something for that. Veracode was good enough overall.

The scanning is most valuable. The scans given by Veracode are one of the key features that I like.

The integration with DevOps pipelines is seamless. 

The scans were sometimes not accurate in version 2022. There were some false positives in the vulnerability reports. We used to get false positives, and we were responsible for checking all of the alerts and determining whether they were true positives or false positives. They might have already improved it. If they have not, they can look into how to mitigate false positives.

I have used Veracode for almost two years. 

It is stable.

It is scalable. The agents were deployed on about 2,000 machines. For administration, we had a SOC team. It was filler work for them, but we had a team of 13 people.

Dennis from Veracode helped us right from the deployment. If there was any critical task, he used to help us with that. We hardly had to reach out to their support for any issues.

I have used different solutions. I have used Darktrace. I have used CrowdStrike and Carbon Black. In my current company, I am using CrowdStrike.

When I was using Veracode, each agent needed to be deployed on each machine. I do not know what they are using now. CrowdStrike is a single platform with a single agent. You can deploy it on all the machines. That is one of the advantages. Moreover, I have become used to the GUI of CrowdStrike over the last year or so. I am more comfortable with CrowdStrike, but it depends on person to person. I would rate Veracode an eight and CrowdStrike a nine out of ten. I am a bit biased toward CrowdStrike because I am currently using it in my organization. I am not using Veracode here.

I was involved in its deployment. It was super easy. The support that was provided by them was fabulous.

There was a delay from our end. It took us almost 90 days to deploy it, which included approvals and other things.

We had a consultant from Veracode. His name was Dennis. We were satisfied with his job. 

I used it for two years in my last organization, and we saved a lot of costs. It was not related to the product; it was related to the risks that we used to get. On the technology side, it surely saved a lot.

They keep on working on their product. They keep on upgrading that. The threat landscape keeps on evolving, and there are new threats every day. The Veracode team helped us in mitigating and remediating them and guiding us with those particular threats. I would surely recommend Veracode. I even tried to recommend it over here, but I am not one responsible person for that decision over here.

They have recently introduced a feature called "Veracode Fix" that produces AI-generated fixes. I read about it somewhere. It does vulnerability identification and prioritization and some behavioral analysis. It does dynamic analysis of any malware or any abnormal or malicious behavior. It is evolving. One more thing that I read was pattern recognition. The AI algorithm that has been provided recognizes patterns. It can assist in recognizing patterns and trends in security data.

It has policy reporting for ensuring compliance with industry standards and regulations, but we did not use that.

To those who want to use Veracode or any similar solution, I would advise being aware of their environment and security posture and seeing where it fits into their security posture. If they proactively work on the alerts provided by Veracode, they will surely save a lot of money, time, and resources. I would suggest working proactively on the alerts given by Veracode.

Overall, I would rate Veracode an eight 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 it to scan our web applications before we publish them to see if there are any security vulnerabilities. We use it for static analysis and dynamic analysis.

Veracode has helped immensely with developer security training and in building developer security skills. Before we implemented it, we would find a lot more vulnerabilities in our applications. Now, with Veracode, the developers have started doing a lot more secure coding and they have much better coding practices.

It has also helped our organization to review code quicker, about 50 percent quicker, and to deploy more secure code.

And when it comes to the solution's ability to prevent vulnerable code from going into production, so far, I haven't seen any instances in which we've had false negatives. So it's pretty effective at that.

Among the most valuable features are the ability to 

• submit the software and get automated scan results from it
• collaborate with developers through the portal while looking at the code
• create compliance reports.

Otherwise, we would have to do working sessions with developers and pull together all the different findings and then probably manage it in a separate mechanism like Excel. And to have to go through source code manually would be quite time intensive and tedious.

The solution also provides you with some guidance as well as best practices around how vulnerabilities should be fixed. It points you in that direction and gives the developers educational cues.

In addition, the policy reporting for ensuring compliance with industry standards and regulations is pretty comprehensive, especially around PCI. If you do the static analysis, the dynamic analysis, and then a manual penetration test, it aggregates all of these results into one report. And then they create a PCI-specific report around it which helps to illustrate how the application adheres to different standards.

The solution also integrates with developer tools such as Visual Studio and Eclipse.

It's pretty efficient, but sometimes the static analysis is prone to a lot of false positives. But that's how it is with most static analysis tools. In some cases, they might have other mechanisms which would deal with a particular vulnerability, but it wouldn't be captured in the code. I would estimate the false positive rate at about 20 percent.

Upon review, the developers understand the solution. But when they get the initial list of findings, it can be a bit daunting to them if it's not managed appropriately.

Also, the static analysis can sometimes take a little while. The time that it takes to do a scan should be improved. There are times when we need a quick turnaround but it will take a little while. We might have something scanning and not get a result until the following day. It's not too critical, but it does increase the delay. Most of the time, when developers submit their code, because of the way that we use it, it's because in their minds they're ready to have that code deployed into production. But the security testing, especially with the feedback, introduces additional time into the project, especially if a security fix is needed.

I have been using Veracode for about two years.

There have been no issues with the stability. We haven't had any outages or any unavailability of the system, so far.

We have about 40 developers but we use this product per project rather than per developer. All our projects will pass through this product. At any given time we have about 10 to 12 projects going on. Outside of developers, it's just the five security team members who also use Veracode.

Any increase of usage will be based on the business and if there are more software projects. Whenever there are additional software projects, we will then increase our usage.

Their technical support is good, but we haven't really had to use it much, so far.

The initial setup was pretty straightforward but, depending on the type of applications or the types of code that you're using, the setup requirements may be a little different. It takes a little getting used to, based on the environment in which you're working.

For example, for Visual studio, it might have specific requirements that are needed to package an application for scanning, whereas an Angular application would have different requirements. For me, as a non-developer, the issue would be around understanding those different requirements for each development environment.

Our deployment didn't take long; it took a couple of days. There were three people involved in, including a developer, someone setting it up, and a code reviewer. By "setting it up" I mean putting in the applications, saying what the application does—providing the business rules of the application.

We didn't have a specific strategy for deploying it. The software is pretty straightforward, once you have the application bundles to be scanned. There's not a whole lot to do after the packaging.

Maintenance-wise, it doesn't take much because it's SaaS. We don't really do much on our end.

We did it in-house with Veracode. Working with Veracode for the deployment was pretty easy, pretty straightforward.

We've seen ROI in that we've cut down on the number of penetration tests we've been doing by about 50 percent, and also because of the stage at which the vulnerabilities are found, before they get into production. That means the risk has also been reduced.

It has reduced the cost of application security for our organization, but more than it has reduced the cost, it provides better software assurance.

In addition to the standard licensing fees there's a support cost and an implementation cost at the beginning.

This year I looked at other vendors in the market, including Synopsys, Contrast, and Checkmarx. What I didn't like about them is that their licensing models are based on how many developers you have. That wasn't a good fit for me. In addition, Checkmarx didn't have a SaaS solution.

If you are doing pipeline-based implementation, it would be more complex than the way that I'm doing this, but I didn't see any real challenges that would be tool-specific or vendor-specific, with implementation.

Your development model will really determine what the best fit is for you in terms of licensing, because of the project-based licensing. If you do a few projects, that's more attractive. If you have a large number of developers, that would also make the product a little more attractive. But if you have maybe one or two developers doing many projects, then you might look more towards software that has a developer-centric model.

We don't use the Static Analysis Pipeline Scan because of the build process that our  developers use. They don't really have an automated build pipeline in which they push the code to production. Also, with the false positive rate, it's a bit tricky when you implement that into the pipeline, as it might stop a developer from pushing code out to test. We use it more like a gate. The developers submit the code to us and then we scan it and review it with them.

The biggest lesson I've learned from using Veracode is that you need to manage it with the developers, so that you speak through the findings with them. It's not just a tool that you throw down their throats.

Overall, I would rate it at seven out of 10. Ideally, I would prefer a product that had the interactive testing, as well as the ability to scan a little faster.

We utilize Veracode in three primary ways. The first is through Dynamic Scans, followed by Static Scans, and Software Composition Analysis Scans. I find this tool to be highly effective. We have various forms of support available. For instance, we can initiate our scans through the CI/CD pipeline or manually if needed. Additionally, we can create separate sandboxes for each of our code modules. Since development involves distinct code modules, each catering to different functionalities, we can conveniently set up corresponding sandboxes within Veracode. This allows us to scan any module whenever required, which is quite advantageous.

From a SAST perspective, Veracode can prevent vulnerable code from entering production by adhering to our manual checklist.

We haven't utilized the Software Bill of Materials; however, we have employed Software Composition Analysis. Whenever we scan a codebase, any third-party applications or libraries that have been incorporated into the code are automatically analyzed. Subsequently, a comprehensive report is generated. This report outlines the third-party libraries and applications that have been utilized in the codebase, along with their respective versions. Additionally, if any of these versions are found to have vulnerabilities, they are promptly detected.

Veracode is efficient. I have used various other tools such as DAST or SAST, and employing those tools usually takes between five and eight hours. In contrast, Veracode completes the task in two to three hours. For each scan, there is a consultation button available. Clicking on that button allows us to schedule a call with a Veracode support team member. During the call, they explain any issues, clarify why certain problems are false positives, and discuss the reasons behind issue detections. There's also a consolidation part and a support button, where we can raise tickets. I have found that their maximum response time to these tickets is within one day. Before starting the scan, Veracode offers a pre-scan functionality. This functionality performs connection and server checks in the pre-scan phase. It's similar to the SAST side of things for all the tools, where the code base is examined before initiating the SAST application to determine if it's sound. However, in Veracode's case, this is implemented in the DAST system. It checks whether the server is operational if the provided call scripts are correct, and if the provided login scripts are accurate. This pre-scan functionality doesn't run during the actual scan but rather at the very beginning to ensure that all prerequisites are met. Once everything is verified, then we can proceed to initiate the actual scan.

Using Veracode policy regulations, we can offer predefined rules. When setting up any application, we establish the application name and other necessary details. Following this, there is a section where we can input this information. Essentially, there exist predefined regulations which we can either directly utilize if they suit our needs, or adjust them based on the requirements of our project team. Therefore, we have a pre-existing set of rules and functionalities available.

We do have a dashboard in Veracode that offers visibility into the status of applications. There is a section where we can view the application names, and next to each name, there is a status report such as "The SAST has been completed" or "in progress," and the same goes for DAST.

After the scanning is completed, with other solutions from a DAST perspective, we would receive a report. If there are any false positives, we would have to identify them ourselves. However, with Veracode, one of their engineers or a support team member will verify the information, which helps to minimize the number of false positives.

Before using Veracode, we used to perform many tasks manually. We had a checklist for the SAST. We would go through each line of code, attempting to determine its compliance and level of security. Even with the DAST, we used to carry out this process manually. Completing the DAST scan took a considerable amount of time. For each module, we had to dedicate at least two to three days. However, since adopting Veracode, we can now not only perform this process for each module, but we can also initiate scans for all the modules simultaneously. As a result, we can obtain the results within a maximum of three to four hours. Time-saving for fixing flaws is one of the significant benefits that Veracode has provided us, helping reduce the time by almost 60 percent.

Regarding Software Composition Analysis, an exceptional feature is that during a SAST scan, SCA is seamlessly conducted in the background. Once we scan all modules and obtain SAST results, switching to the SCA section reveals the associated reports. This integrated approach eliminates the need for separate SAST and SCA scans, as is required by other tools.

The reporting feature is noteworthy. The reports are well-structured, providing comprehensive details for each vulnerability. Information about the vulnerability itself, its origin, the specific section of code it pertains to, and even the exact line of code involved are all included.

I've found that Veracode is not particularly suitable for Dynamic Application Security Testing. Unlike other tools equipped with their own crawlers, Veracode necessitates the use of a Selenium script for crawling. However, the tool's compatibility with all functions is limited, which can be frustrating. For instance, functions like upload, download, or those triggering new tabs are challenging to handle within the DAST section due to Selenium's inadequacies when used with Veracode.

In contrast to other tools where we can monitor requests and responses during a scan, Veracode lacks this capability. The scan initiates, and we must wait until completion to see the results. There's no opportunity to check if the right requests are being sent or if certain components are being excessively targeted. Once the scan starts, we're essentially locked in until it concludes, and only then can we access the results. Furthermore, even after the scan, we're only provided with a summary of scanned URLs and the number of requests made, without the specifics of the request or response contents.

I have been using Veracode for four months.

Veracode is stable, and we have not encountered any issues.

The cloud version of Veracode can scale according to the file size.

I have engaged in two different types of experiences with technical support. One involves the ticketing system, and the other involves consultation calls. The consultation calls revolved around static analysis. During these calls, we presented all the vulnerabilities we discovered. We conducted our analysis and demonstrated how Veracode identified certain vulnerabilities. However, we also explained instances where these were false positives due to specific reasons. During the call, they acknowledged these issues. They pointed out some of Veracode's limitations, highlighting that it solely scans the code and doesn't consider the framework side. This implies that they accept these limitations. Furthermore, they provided us with insights into how they plan to implement fixes in the future, which is quite beneficial.

Additionally, whenever we had inquiries or doubted Veracode's detection of false positives, they provided detailed explanations. They shared the specific Veracode setup and rules within the SAST side that led to the detection of certain vulnerabilities. They also explained that by incorporating certain mitigations at the code level, these vulnerabilities could be addressed. 

Regarding the ticketing system, for minor issues or questions, we would raise a ticket. They consistently responded within a maximum of one day, providing us with the necessary information.

Positive

Before transitioning to Veracode, the client had been utilizing a free community version tool. However, the count of false positives was exceedingly high with that specific tool. This prompted the client to seek a solution that could deliver superior results with fewer false positives. As a result, the decision was made to switch to Veracode.

I would rate Veracode a seven out of ten because the DAST has room for improvement.

The maintenance is completed by the Veracode team because we are using the cloud version.

For individuals seeking exclusively SAST and SCA capabilities, rather than DAST, Veracode stands out as the most suitable tool. However, if someone intends to utilize Veracode solely for DAST, I believe they should explore alternative tools. The effectiveness of Veracode's DAST functionality is limited, and using other tools might yield better results. Additionally, Veracode provides comprehensive training resources through its portal, including a list of documents and video tutorials. These resources are readily accessible and offer adequate guidance for initiating the use of Veracode.

I'm using it to troubleshoot and know the issues in my code and resolve them as soon as possible.

Veracode helps me to understand and resolve vulnerabilities in my code. It's very good to have, and what's most interesting is that the Veracode Greenlight gives me real-time output and resolution. I can also schedule calls with the security experts for any resolution. It's good for understanding and resolving issues that my code might have.

Veracode definitely helps in creating a secure environment for both the company as well as the clients. Our clients require their data to be secure. They also require a stable solution. Veracode is helping me in developing a good product. It provides full information and also helps in a quick resolution.

Veracode is secure, and it has coding standards. It helps me in penetration testing and application security consultation. It exposes common vulnerabilities. The static scan is very good, and it gives me valuable information and a very good recommendation of how I can fix it.

We can integrate Veracode for both static and dynamic analysis to reduce the risks in the application and prevent vulnerabilities. A significant benefit is that you have a risk-free code. It minimizes the risks.

It gives visibility into the application status at every phase of development. There is Veracode Static Analysis, Dynamic Analysis, Software Composition Analysis, and Manual Penetration Test throughout SDLC.

Veracode has been very important and helpful in creating stable products because we are able to identify issues in the code and then create powerful and stable products for clients.

Veracode provides all details regarding the issues and the way to resolve them. It makes it easy for me as a developer to understand the issue in a better way. It improves a developer's confidence in the solution when fixing vulnerabilities.

Veracode has saved a lot of our time. It has saved us about 45% time.

Veracode has enhanced security. We are able to identify what is missing and what are the issues in the code. When we know that the code has an issue, we are able to make sure that we correct it. Veracode has helped us a lot in providing a stable, secure solution to our clients.

Veracode has helped us to develop faster because it's so straightforward. It has clear documentation that you can use to create a very good and stable environment for developers to collaborate and create a unique solution.

IDE Scan is the most important feature, and then you have SCA and Platform Scan.

I like the fact that it can be used at any stage of application development. I use scanning with a particular piece of code. There is an extension that helps me to create my code easily in Visual Studio and then find flaws before deploying the code. It's definitely benefiting me and the organization. It's so quick and easy to create a code and then deploy it live.

It's easy to create reports. It works very well. It's straightforward, and it does not require a lot of time. It's a straightforward platform that you can use for performing scans or mitigating issues. It has a very good user interface. FAQs are also helpful in case you are not familiar with it. It's good and straightforward when you integrate it with machine learning platforms.

It's very expensive for a small organization.

I have been using it for a year and a half.

It's a very stable solution.

It's scalable enough. Veracode is being used in the engineering department. It's being only used in one department by two people. It's a developer tool for developing solutions faster, troubleshooting, and debugging.

Their support is good because there is an option to request a consultation. If you face any issue or any difficulty with the scans or mitigation, they can help you out. The support service for me is very costly, but you also have a well-organized FAQ and a very big community for asking questions and getting a solution. I'd rate their support a 10 out of 10.

Positive

I haven't used a different solution. This is the first solution I've used.

I was involved in its deployment. It took me one week to implement Veracode. The process was straightforward. If you are lost or have any issues, you can read the documentation.

I implemented it.

It's not so huge to provide a lot of return on investment, but it's helping us to have a stable solution. It's a secure platform, but in terms of the return on investment, it hasn't made a very good impact yet. We have only seen 10% to 15% ROI.

It has reduced the cost of DevSecOps for the organization because we can use one platform to develop, troubleshoot, and debug faster, so it has helped us a lot.

It's very expensive, especially when you are a very small organization. If you're using Veracode at an individual level, for example, you're a developer or you run agents, the pricing might not affect you, but if you're using it at a company level to troubleshoot security issues, the pricing is not quite favorable. It may affect ROI.

Veracode is good. It's for organizations that want to give their customers both security and privacy. It's good in case you want to dive deep into the code and get the flaws that could be dangerous to both the organization and the customers using an application. If you are looking to create a good application that is also secure, I'd recommend Veracode.

Overall, I'd rate Veracode a 9 out of 10.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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