Share your experience using Synack

My use case for Veracode includes utilizing the SSA and SAST modules as part of improving the code that we are developing in the company, and we have 130 developers that we are trying to onboard in this platform. We have been able to onboard 100 more or less in these months, and the idea is to change the way they are developing because we want them to heavily use the IDE integration. 

We mostly use Visual Studio Code, and we have them using the integration plugin with Veracode so that they can fix the security issues at dev time. When we have the product in the pipeline, and we run the scans again, it's a green light.

Veracode Fix has affected our time to remediate security flaws in cases where we've been able to use it correctly because the proposals were on point, and it's been great. 

We've seen that in the same sprint that we were developing the features, now those features are implemented without any technical security debt. What happened before was that we needed another sprint to solve those technical debts. So we haven't seen an increase in time, and the speed of development of the teams is better, and now the product is being delivered with less technical debt.

One of the aspects I appreciate most about Veracode is that even though we have a license for developers, we don't get charged by the users who don't develop code but are only trying to access the platform to see the reports or the dashboard, such as architects who do some code reviews but don't develop. That's a nice feature that doesn't happen on other platforms that we analyzed. 

Another feature that we appreciate significantly is Veracode Fix and how it's integrated with Visual Studio Code. Even though it has some room for improvement, the key usage for us is to be able to solve everything. The developers also learn how and why they have to solve the security vulnerabilities detected. At the same time, they are developing the feature. Veracode Fix has affected our time to remediate security flaws in cases where we've been able to use it correctly because the proposals were on point, and it's been great.

Regarding room for improvement, we have some problems when onboarding new projects because the build process has to be done in a certain way, as Veracode analyzes the binaries and not the code by itself alone. If the process is not configured correctly, it doesn't work. That's one of the things that we are discussing with Veracode. Something positive that we've been able to do is submit formal feature requests to them, and they are working on them; they've already solved some of them. This encourages us to propose new ideas and improvements. Another improvement that we asked for this use case is to be able to configure how Veracode Fix proposes and fixes because sometimes it makes proposals using libraries that go against our architecture design made by the enterprise architecture team. For example, we want them to propose using another library, and that's something we already asked Veracode, and they are working on it. We want to specify when you see this kind of vulnerability, you can only propose these two options.

I have been using Veracode for nine months.

It's not that easy to onboard, but once they have been onboarded on the platform, and the pipeline configured alongside the product configured, it works effectively.

I have contacted the technical support and customer support. With Veracode's technical support, for some issues, it has been really difficult for them to understand the problem, and they ask us to do some tests we've already told them we completed in the first ticket. I think there is room for improvement there. However, we are also working with premier support, where we have an engineer assigned to our account. When we work with him on one of our problems, it gets solved much faster. Now we always try to add this engineer to all of our tickets so that we can solve everything faster. That's because we have the premier support as part of our agreement.

Positive

The initial deployment was difficult. We had some problems with the SSO integration. But Veracode found a fix, and they are delivering the final solution to production. It took us a lot of time to get that mitigation, and it's not that fast to onboard the dev teams. We are having meetings with each team depending on the language they are using and the type of application; it may be really fast or take up to a week for them to have the product integrated. My expectation was that it was going to be faster.

For us, it wasn't the most expensive solution proposed. Part of our decision to get Veracode was that when we evaluated against other products, Veracode was cheaper. What they need to measure is that you need a tool that is efficient and works for your products and how you develop, which has a nice level of detection and a low level of false positives. We make an evaluation and only choose tools that offer a good balance between providing good detections and a low amount of false positives. What was happening with SonarQube was that we had lots of false positives, making teams not care about the vulnerabilities because most were false positives. Regarding price, the evaluation should focus on how efficiently they will recover their investment, considering the time saved through the use of Veracode Fix, for example, and the ability to fix code at dev time compared to the problems faced when fixing after the product is already deployed.

We have used some alternatives to Veracode for some of the use cases. For example, for SAST, we've been using SonarQube from Sonatype and also some IDE plugins that we've asked the developers to use, but we didn't have any centralized platform to manage and false positives or findings. For SSA, we've been using Renovate Bot and also SonarQube and some of the GitLab integrations that we've been using for some use cases. The only one that we've used as an enterprise solution for all the products was SonarQube and Renovate Bot; the other tools were tested with a small number of teams.

We don't use some of these tools because we don't have the license for them. We are not using Veracode for DAST or for manual penetration testing, but we are using the other ones, and they give visibility through the process. I think that Veracode does it, but since we are not using DAST, we are only part of the development process before going to the runtime environments. So we are not checking anything on runtime. That part of the process, where you have the product running and you make real tests on the running product, we are not solving with Veracode, but that's mainly because we don't have the DAST licenses. 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. Generally, most teams have improved a lot, for example, by updating all the libraries and reducing all the critical and high vulnerabilities, delivering to production only with low or medium vulnerabilities.

The primary use case for the NodeZero Platform is as an extension to existing vulnerability management systems. Initially, it complemented solutions like Qualys or Tenable. However, there has been a shift towards using NodeZero to replace existing vulnerability management solutions altogether. The motivations include cost savings and addressing issues that traditional vulnerability managers might report but do not actually affect system security.

Deploying the NodeZero Platform is straightforward for me as it involves just a Docker container in a network or a network segment, saving time and eliminating the need for agents on every endpoint. Its autonomous operation, safe for production use, makes it practical to schedule pen tests during business hours. The tripwires feature acts like a honeypot, providing network alerts for potential threats. These factors make it an effective tool for enhancing security in organizations.

One of the areas where improvement is needed is in the visibility and reporting for large enterprises. The existing GUI or NodeZero insights provide better visibility, but there's still room for enhancement. Moreover, there is a need to automate interactions with other systems, particularly in triggering or opening tickets in ServiceNow. Adding the application layer would also be valuable for clients.

I have used the solution for 1.5 years.

No issues were encountered in deploying the NodeZero Platform. Once the firewalls are open and communication with the cloud is enabled, it's a matter of installing a Docker container or VMware and opening the ports for smooth operation.

I rate the stability of the NodeZero Platform a ten out of ten. We have not encountered any issues on the platform regarding accessibility, performance, or stability.

I rate the scalability of the NodeZero Platform a ten out of ten. We have conducted pen tests in environments with hundreds of thousands of IP addresses without any scalability issues. The platform is built for large scale deployment and operation.

I rate their support an eight out of ten. The support is skilled and effective, although there are sometimes delays due to bandwidth issues, possibly due to the size of the team.

Positive

Initially, NodeZero and similar solutions were used alongside existing vulnerability management solutions like Qualys or Tenable. However, there has been a shift towards replacing these existing solutions as businesses seek to address vulnerability issues more efficiently.

The initial setup is very easy, rated 10 out of 10. It involves straightforward steps of installing a Docker container, configuring firewalls, and ensuring communication with the cloud.

The deployment process involves an initial meeting with the client to choose the deployment method—either on a VMware or Docker container. This is followed by defining and setting up firewall rules. After preparing everything, deploying the Docker container or VMware takes a few minutes, and the pen test can begin.

I rate the pricing a six out of ten. Pricing is moderate compared to competitors but depends on the solutions in comparison. While cheaper than XM Cyber and human pen testers, it's more expensive than vulnerability managers.

I evaluated Pentera and XM Cyber alongside the NodeZero Platform at various points. Pentera was assessed about two years ago, and we have clients currently using XM Cyber.

I rate the NodeZero Platform an eight out of ten. The platform is scalable and stable, suitable for large enterprises and businesses. It needs improvement in areas like visibility, reporting, and automation with third-party systems. The overall product rating is eight.

Hybrid Cloud

Amazon Web Services (AWS)