We used it for static and dynamic testing to check if there were any vulnerabilities in the code. If there were any vulnerabilities, we would check the report downloaded from the Veracode portal and try to fix the code before deploying it.

Veracode helped me remove errors, and it didn't take a long time to fix any issue because I had an answer regarding where the code needed to be fixed. That feature helped us test our cases and get them deployed. It helped me fix vulnerabilities and any other errors before deployment to the applications.

The SAST and DAST scans—we used it both before code was deployed and after it was deployed—helped us run through the issues and keep track of their status. It was deployed in the pipelines, through Jenkins, and checked the logs in Kubernetes.

The solution also saved us time. I really liked the automatic scanning because there was no way to know where an issue was. Human tendency is to make mistakes, but Veracode helped us find the exact spot where an error was and change it. The reporting helped us do that in a short amount of time.

For our team, it had a very good impact. My manager used to suggest that before taking code to the next level, it was a really good idea to scan it.

I liked that I could easily find out where my errors were. Instead of going through the whole code and the scripts, it showed me where the errors were and gave me an idea of how to fix them.

The reporting was detailed, but there were some things that were missing. It showed us on which line an error was found, but it could have been more detailed.

Also, with upgrades, we had quite a difficult time tracking the reports, so there was some maintenance around that.

I used Veracode for 13 months.

I had a situation that was due to a slow network, and I couldn't get results within a specific time. Because of that, there was a lag in production; we couldn't deploy the code on time. There was a crash, and because of that, we couldn't meet our production deadline.

The downtime happened two or three times. I thought it was due to a network issue when it happened once, but then I came to understand that it was a maintenance issue.

Veracode is really not difficult or complex to understand. The whole concept is simple. It takes some time to get used to the tool, but it is a very simple tool to work with.

It was quite fast. Scanning my code took 25 to 30 minutes, which was quite good.

We use Veracode for static application security testing (SAST). We also use it for scan or software composition analysis (SCA) testing purposes. We mainly use it to triage the flaws or vulnerabilities that are found in our coding standards so that we can enforce secure coding practices at the developers' end. Because we are a part of the security team, we provide mitigation for the development team on all the SAST vulnerabilities that we come across.

We use it for static application security testing. It helps us with proactivity. Before the product or the application is deployed on the production environment, we have a DevSecOps pipeline that kicks in, and we are able to triage the flaws or vulnerabilities that Veracode shows based on our policies using the Open Web Application Security Project (OWASP). Veracode definitely helps us to go through the vulnerabilities and fix them before they go into production so that bad actors cannot exploit them.

In terms of software composition analysis or SCA, we have come across several libraries and packages that were vulnerable and detected by Veracode. We work on getting the latest updates or packages so that we do not fall back on the security front.

When it comes to visibility, I am not sure whether it is through Veracode, but we have our pipelines built on Azure. We do get to see whenever a scan is kicked off and whether the Veracode check has passed. There is no direct visibility in Veracode apart from the dashboard, which does have information about what type of scan has been performed and whether it is a policy sandbox or just a testing sandbox.

Veracode has been fairly decent for fixing flaws. We have mainly been using it for SAST. For DAST, we have our AppScan from HCL, but Veracode is fairly decent for fixing flaws or trying to be proactive and ensuring all of our applications have been securely developed.

In terms of policies, it works fine. Our policies are mostly predefined. They were defined by our previous team. We look into the policies based on the scan dates.

From a developer's perspective, Veracode's greenlight feature on the IDE is helpful. It helps the developer to be more proactive in secure coding standards. Apart from that, static analysis scanning is definitely one of the top features of Veracode.

Recently, I came across a new workflow, which I had seen in Checkmarx, that shows how a vulnerability flows from the start point to the end point of a function.

There can be a lot of improvement. It does not have a reporting structure for an OS-based vulnerability report, whereas its peers such as Fortify and Checkmarx have this ability. Checkmarx also provides a better visibility of the code flow.

Veracode is 75% or 80% accurate. At times, we do come across a lot of false-positive cases, but this is an issue with all security tools. Unfortunately, we do not see an option to set the policies because policies are predefined. Overall, when comparing it with its competitors, Checkmarx is better than Veracode in false-positive rate. Veracode's false-positive rate is decent. It is not too good and not too bad, but there is a lot of room for improvement. I personally found Checkmarx to be more accurate than Veracode. This false-positive rate has an effect on the security team because, for a false positive, a developer raises a ticket for us, and our job gets a little bit more hectic because we have more vulnerabilities to create rather than focusing on the positive ones. It is daunting when too many false positives are being reported by the development team for triaging purposes. However, in one of the calls related to their roadmap, I saw a feature where you can go through the code, and it provides you with some mitigation.

I used Veracode at the beginning of my career from 2017 to 2019. I then switched my job, and my next company used Checkmarx, which is a competitor of Veracode. I changed my job again in 2021 and have been using Veracode in this company. Overall, I have close to three years of experience.

It is pretty stable. I would rate it a nine out of ten in terms of stability.

We are using the SaaS offering, so it is pretty scalable. I would rate it a nine out of ten in terms of scalability.

Whenever there is a flaw that we cannot understand, we have something called Veracode consultation. We raise a ticket and follow up on the ticket. That is it. They are well-versed. The only challenge I face is that I am based out of Ireland. The time zone is a pretty big issue for us most of the time. Whenever we have a code support call, the majority of the time, it happens late at night. That is one of the reasons why we tend to skip the consultation calls. I would rate their support a nine out of ten.

I have worked with Checkmarx in another job. I prefer Checkmarx over Veracode. Checkmarx provides a better visibility of the code flow. Veracode also has code flow, but it is in IDE, so you need to manually jump through the code and check the flow. It is easier for someone with experience, but someone new to the security domain will find it tough, especially when there is no clear picture of the workflow to know what is going on. This is a feature that I would like in Veracode.

It is a SaaS or cloud solution. It is definitely not on-prem. We sign in using a single sign-on.

I was not involved in its deployment. There is no maintenance as such.

To those evaluating Veracode, I would say that unless you get hands-on experience, it is difficult to evaluate. So, I would advise getting hands-on experience with the tool. I would also advise checking out other solutions such as Fortify and Checkmarx.

Overall, I would rate Veracode a seven 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.

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.

Veracode is our primary tool for identifying and resolving security flaws in our web-based applications. When I started at Advantasure, I worked on a claims product, using the tool to remedy coding issues and identify high-risk security flaws. I did that for a while before transitioning to a role as an application security engineer. In this job, I don't fix any security flaws. I help operate the environment.

We have integrated Veracode with Jenkins so that we can automate building and scanning code. Jenkins uploads the build to Veracode for static and SCA scanning.

I'm working remotely through a VPN. When I log into Veracode, I check the various applications out to ensure everything's running. If we have any issues, I report them to the appropriate teams.

We are in the health insurance industry, so compliance with security and privacy regulations is essential. Veracode is the industry standard. We use Veracode when we do internal audits and that sort of thing. You won't be in business for long if you don't have an industry-standard static security tool.

I have only worked at this company for two years, so I can't comment on what it was like before I joined, but Veracode does a good overall job of interfacing with us and giving us advice about areas we can improve. The company has used Veracode for a while, so it's not about improving per se. It's about maintaining and learning to use the tool better or making better use of dynamic scans. Our security doesn't depend on one feature. We're implementing multiple features, such as static and dynamic scans.

Their policies are relatively helpful for compliance. The policy configuration tool works well. We try to use one policy to cover all our applications. Once we've configured the policy correctly, it does an excellent job of applying that to each application and ensuring compliance. Veracode provides good visibility, and the reports are integrated, so we get insight into each type of scan.

Veracode's false positive rate is decent overall. The biggest challenge isn't a C or C++ call, but it's tricky to follow the data flows when using a web interface. You get a few false positives every once in a while.

I always tell our developers to verify all false positives because Veracode cannot follow your code flow. It's up to the developer to follow the code flow and check whether it's a false positive. The initial report is an excellent place to start. I don't think the false positives affect developer confidence. I never hear anybody complain about false positives.

The biggest challenge isn't Veracode; it's getting our developers to be compliant. Our organization is undergoing some changes, and we must remind the developers to do their jobs. As an application security engineer, I struggle to get developers to do these tasks because they don't want to do them. At the end of the day, the false positive rate doesn't affect developer productivity.

Veracode doesn't really help developers save time because we're already a mature organization. Their support team has helped us optimize our scan configuration significantly. Regarding the regular developers' goals, we have existing documentation and hold meetings with them. They do support consultations when developers have an issue.

I like Veracode's static scanning and SCA. We use three static scans, software composition analysis, and dynamic scans. We haven't used dynamic scanning as much, but we're trying to integrate that into our environment more.

For the most part, we've had good luck with the static scans as well as the software composition analysis scans. Veracode does a decent job of catching most vulnerabilities from making it into production, but it doesn't catch everything.

I have a few pet peeves and minor areas of irritation. Their customer success team does an excellent job, but getting their internal engineering team to do things isn't easy. They seem to lack a focus on maintaining the solution and improving it in the next generation.

It's a common problem in the industry. Software developers are always thinking about the next big thing but lose sight of what's happening right now. If you have an idea for a feature request, you must submit it to be voted on by the Veracode community. I don't like this. No one will look at it unless enough people vote for it.

Another issue we have concerns entry points. You must select the entry points for a static scan of your stuff. However, you can fix this by having templates in Jenkins. Things can sometimes change, confusing Veracode. I want to lock those entry points in. Eventually, our DevOps team will create templates for everything. If I want a new template, I need to submit it to the community and get my peers to vote on it. It's a waste of time.

I have used Veracode for two years.

I've been impressed with Veracode's stability. The solution doesn't go down often. The dynamic scans went down the other day, but that was a problem with the infrastructure, and AWS rarely has outages. Overall, it's dependable.

We haven't had any scalability issues with our current scan volume, but we're a medium-usage client. We have more than 30 static scans and 12 to 15 dynamic scans and don't seem to have issues with performance.

I rate Veracode support 7.5 out of 10. Overall, our technical support is decent. You have to find someone who works well with you. My biggest challenge is dynamic scanning and getting up to speed on that. You must find out who's good and stick with them as much as you can.

Our ROI comes mainly in the form of compliance. We get a star rating when we're automated, and we need to maintain that. We currently have a fairly high rating, so it's not so much about gaining stars. We need to avoid losing them. By maintaining our high rating, we can also gain more clients.

Veracode is expensive, but other solutions cost as much, if not more. For example, Rapid7's dynamic scan tool was at least as expensive as Veracode, and Rapid7 wasn't willing to negotiate. We are a reasonably large user.

It's a fair price. If you're worried about getting your money's worth, you could ask Veracode for a trial license and compare it to other tools in terms of pricing versus features. That's how I would do it. It's crucial to do your homework. At this point, we're somewhat locked in and won't change unless we find something significantly cheaper or better.

The company looked at other options, and we try to do one-stop shopping when possible. We looked at other tools like Rapid7 but decided against doing a proof of concept because it doesn't offer static analysis. I don't think they could do software composition without static analysis.

We could use Rapid7 for dynamic scans, but then we would have issues with report integration. One of the primary reasons we use Veracode today is that they have solid support. They typically respond to almost any ticket within 24 hours. Veracode also does an excellent job of integrating its various tools for static scanning, dynamic scanning, etc.

At the end of the day, we stay with Veracode primarily because of the solution's integration. Our license is up this year, and we currently have no plans to seek out another vendor. We may consider switching next year.

I rate Veracode seven out of 10. Before you evaluate Veracode or any other solution, you need to sit down with other specialists and decision-makers to develop some criteria. See if Veracode will give you a free trial license, and start testing it out. You can also check Gartner.