In terms of readiness for the production release, Veracode definitely helps us be confident and quickly identify the risks. There's a huge benefit in that area.

Before Veracode, the application was deployed to the production server and there would be a lot of bugs and issues. Once we implemented the Veracode scan, the full deployment issues were drastically reduced. In a month we do 10 releases and we used to get five or six post-deployment issues. Now, we barely get one or two.

Veracode does a great job of preventing vulnerable code from going into production.

Veracode can block vulnerable code from going into production.

We do not receive many threats. The threats are very minimal. Therefore, I have never been in a situation where Veracode had to save me from vulnerable code entering production. However, it is still helpful for us and our managers to access our code to see what is happening and what can be improved using Veracode.

Veracode's ability to prevent vulnerable code from entering production is comprehensive and effective.

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

Veracode's analytical capabilities are very good, but I'm not sure if they have prevented security vulnerabilities from going into production in our case because we haven't been using them optimally. We're now working on integrating them into our development pipeline so that we can test applications before they're released. This will also allow us to familiarize ourselves with the sandboxes during development. I believe that if we start using Veracode correctly, it will be very beneficial in preventing security vulnerabilities from going live.

Veracode's ability to detect security vulnerabilities is excellent. We can feel confident that none of the vulnerabilities will make it into production. It doesn't take long to realize the benefits from it. The

Before integrating Veracode, we were getting so many security vulnerabilities on higher branches. We integrated it to fix that. It prevents vulnerable code from going into production. We have fewer vulnerabilities and bugs.

Veracode does a great job preventing vulnerable code from going into production. For enterprise-level companies, saving time is paramount. Previously, manual testing took days and still didn't uncover as many issues as Veracode now identifies. Despite having a skilled testing team, their workload has been reduced by 70 percent thanks to Veracode. This newfound efficiency has revealed vulnerabilities we wouldn't have found otherwise. Veracode excels at showcasing issues and their severity, extending beyond violation errors to encompass potential security risks and logic-related issues. Its user-friendly interface simplifies the process for all users, regardless of their technical expertise. As a developer, I recognize the immense effort behind Veracode's seamless operation. It automates the grunt work, freeing up our developers to focus on other tasks.

Veracode effectively identifies vulnerabilities within the code. My role is to analyze these vulnerabilities and assign a severity level before forwarding them to the development team. This allows them to address the issues before deployment to production.

The solution effectively prevents vulnerabilities from entering production. We've drastically reduced our third-party VAPT-reported issues. Before Veracode, the third-party VAPT analysis reported hundreds of issues per application. Now it's down to about 20, and Veracode can address most of them.

Veracode's ability to prevent vulnerable code from entering the production environment is good.

The way we are using Veracode now means that since we haven't finished the rollout yet, we are not putting any restrictions on our pipelines so that they can only go to production if Veracode didn't find any critical vulnerability. Now, we are not using it as a blocker, so it depends on the team. Some teams don't want to appear in red in the reports from the last pipeline scan, so they are delivering much more secure code to production. Other teams don't care and still deliver with the same vulnerabilities, but that's something that varies from team to team.

Just before production, we did a scan and ensured that there were no critical or high-criticality issues before going to production. I think that helps to sanitize the code without going into a peer review.

During the development phase, we can identify vulnerabilities in the application. This process occurs in the staging environment during development. When we're ready to go to production, we conduct a final check. Essentially, this tool helps identify vulnerabilities during the code development stage, including both high-level vulnerabilities and those related to open-source software composition.