What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
Buyer's Guide
Veracode
April 2024
Learn what your peers think about Veracode. Get advice and tips from experienced pros sharing their opinions. Updated: April 2024.
769,065 professionals have used our research since 2012.
For how long have I used the solution?
I have been using Veracode for almost four years.
What do I think about the stability of the solution?
I would rate the stability at seven out of ten, considering the false positive issues we are experiencing.
What do I think about the scalability of the solution?
How are customer service and support?
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.
How would you rate customer service and support?
How was the initial setup?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.