We are a software company providing software to paper manufacturing organizations, and we have an extensive ERP product along with many add-on products.

With the need to increase security awareness and vulnerabilities, we decided that we needed to scan our software, so that was how we started using Veracode.

We found Veracode eye-opening because we had many third-party libraries in our application, and we found vulnerabilities and had to upgrade those libraries or seek alternatives.

Our use cases for Veracode were to make our software more secure and provide a better competitive advantage over our competitors by telling our clients that we have secure software.

What we found most valuable in Veracode is the ability to do automatic scans of our software. We've incorporated the solution into our SDLC process, so we take our builds before they get released and put them through scans to ensure any new vulnerabilities haven't occurred.

We found Veracode good at preventing vulnerable code from going into production.

We also use the Software Bill of Materials (SBOM) as we run many applications through Veracode. We use SBOM to discover all the different vulnerabilities and what that stack looks like.

We also found Veracode very good in helping us manage risks, such as supply chain, licensing, and security. The solution allows us to see where the risks are and if updates are available and identify how to remediate our software quickly.

Our company also found it moderately easy to use Veracode when creating a report via the Software Bill of Materials. There may be a bit of a learning curve, but once users have done it, they'll run the same report.

As for policy reporting in Veracode to ensure compliance with industry standards and regulations, we have not used the solution that way. Instead, we rely on the different statuses to achieve the levels we want to achieve and be able to use that on marketing material.

Veracode offers visibility into the application status at every development phase throughout the software development life cycle, but we have not implemented that. That feature is built into the development tool, so developers will get alerts as they code, but we plan to do that in the coming year.

We found a moderate false positive rate in Veracode. There were a few false positives. Veracode can identify vulnerabilities, which we found nice. We could flag false positives on Veracode so they don't continue to pop up and hunt them down, and the solution will ignore those in the future.

The false positive rate in Veracode doesn't affect developer confidence in the solution when fixing vulnerabilities because we realized that our application is huge. False positives will happen in large applications just because of the different ways of implementation and features. No toolset can handle all those different features and interactions, so we can't say they relate to vulnerability.

Veracode dramatically impacted our company's ability to have security awareness and achieve a level of confidence that we can put out to the marketplace.

We also saw how Veracode affected our company's overall security posture, explicitly being able to put the solution into automatic scanning mode, then through our SDLC cycles, and achieve a Veracode-verified status. We can use that as a marketing advantage and say that we've achieved Veracode-verified status with one of the leading vendors of security scanning software. We've reached a level of status with them, and we continually scan our software so our clients can be confident that our software has been scanned for security files before implementing a new software release.

An area for improvement in Veracode is the time that it takes to scan large projects, as that makes it difficult to fit into our CI/CD pipelines.

One of our app scans times out after two hours, which requires uploading and scanning that particular application manually. Still, there's no visibility into the CI system with the vulnerabilities found. My company cannot incorporate that into the automatic cycle and has to scan manually, so Veracode could improve on that.

I've been using Veracode for about two years.

Veracode is very stable. I have no concerns with its stability.

Veracode is very scalable from the perspective of ERP applications, though we aren't sure if other clients have applications larger than ours. For reference, we have five million lines of code in our application.

I've contacted the Veracode technical support team and found the support responsive. The team also got back to me quickly. I didn't find any issues with Veracode support.

I would rate technical support as eight, just because you still need to do manual scans, as Veracode still has not addressed that issue.

We used a product called Mend.io, formerly WhiteSource, before Veracode to look at vulnerabilities.

I was part of the initial deployment of Veracode, and it was straightforward because Veracode had excellent training programs and onboarding procedures. The Veracode team also helped along the way and was very supportive in answering questions and keeping my team plugged into any new offerings.

We implemented Veracode in-house with only three people involved.

I found Veracode very expensive, though I'm not the person paying for it. I was surprised to find out how much the subscription costs and that the executive board approved it, but it was a no-brainer because now my company has better security scans.

What I can tell others looking into Veracode but concerned about its price is that the price or cost is justified. After all, you can tell potential clients that your software is better than competitor software because you're scanning it and Veracode-verified.

The verification levels of Veracode are essential because you can use Veracode to start climbing up the ladder to say that your software's even more secure than anybody else because it achieved this level of verification.

In terms of Veracode reducing the cost of DevSecOps in our company, we find that tough to determine because we never had a real concentration on DevSecOps before Veracode. It was forced on us by the fact that the industry was becoming more vulnerable, so now we are experiencing an increase in price in DevSecOps because we're paying attention to it now. We used to skate by and weren't affected by vulnerabilities. Still, because the industry had more vulnerabilities, our customers asked if we were scanning our software, so we had to find a solution and add DevSecOps to address industry needs.

I did a Gartner search on the top three solutions and looked at their reviews, and Veracode came out to be the leader, so I just went with the leader from a partner perspective.

My company has a hybrid Veracode deployment. It's a cloud-based solution, so it's tied to the company's automatic build cycles, where you can access and do scans through the cloud.

Veracode doesn't require maintenance. The only maintenance my company performs is fixing vulnerabilities found by Veracode.

Overall, my rating for Veracode is seven out of ten.

I advise others looking to evaluate Veracode to utilize the presales marketing side first. For example, my company was able to utilize Veracode in a presales environment and do the scans to find out how vulnerable my company's software is and compare Veracode with the previous tool, WhiteSource. My company found additional vulnerabilities and was able to do that before signing the contract. It may be best to do a test run of Veracode to find out what the tool is all about and how it looks to your company.

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.

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.

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.