The initial setup, including Veracode configuration, is straightforward. During setup, we only need to provide the repository path and specify the type of project, based on the chosen technology. We also need to indicate where the project dependencies are located, with prioritization for Java projects and placement in the NPMRC file for node.js or Java security projects. Overall, the process is simple and straightforward.

The initial setup was straightforward; it took seven to ten days, including gathering all requirements, overall deployment, and the final implementation. The deployment team consisted of four to five members. 

The product doesn't require any maintenance; operations and support are primarily handled by Veracode, as it's a fully managed service. 

The initial setup is very easy. It's not that complicated.

Moreover, the false positive rate of static analysis can affect the time spent on tuning policies. It took at least one day for me to raise that mitigation and approval ticket to look into it. Veracode needed to spend, like, six to eight hours, which essentially goes up to a day to resolve it.

The solution has 100% helped our developers save time. 100% right now in terms of ensuring the code is good and deploying it safely. Veracode definitely helps us be very confident when we go for product releases. It has helped our developers save time.

As a lead developer, it takes me one or two days to set up everything in Veracode scan. Once it's set up, the junior developers don't need to do a single thing. They just push their code, and they don't even realize that a scan is running in the background. So they don't need to worry about it. However, 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.

The initial setup was straightforward. We connected to the Veracode cloud, so essentially, we are operating on their public cloud. Whenever we run any process, we send our code to them. They execute it, and we receive feedback from the execution.

I have not been involved in the initial deployment of Veracode, but I have been involved in deploying the pipelines, creating and building out the ISMs, and also administering users. Recently, we moved and integrated it with our single sign-on. Since we're using Okta, we performed the integrations, and now everyone connects through Okta.

I can't recall the deployment well, but I think it was straightforward. Veracode requires no maintenance after deployment. 

The deployment was straightforward. Three people were involved in the deployment.

The setup process was straightforward, and the Veracode team guided us through the deployment, which took about four or five hours. It only takes one person to install the solution. It doesn't require any maintenance after deployment. 

The initial setup was pretty straightforward. They have a SaaS solution and there are a bunch of API integrations that made it pretty straightforward.

As for maintenance, all the upgrades and updates are done on Veracode's side. But there is a wrapper. When we are doing the integration, there is a package that we use to upload the files in Veracode. Sometimes there is a new release for that package and we have to update it in the GitLab repo. That's the only maintenance we need to do.

The solution is not deployed on our systems. It is cloud-based and only requires logging on.

The initial setup is very user-friendly. It's got comprehensive documentation to guide teams. The platform itself is very intuitive, and that enables a swift integration into our development pipeline.

We had a team of five to six people involved in the implementation. 

The solution, once deployed, does not require maintenance. 

The deployment, if it's straightforward, takes around three to four hours. We had two to three people setting up the solution. You would not need more than that. The deployment was pretty straightforward and easy. The implementation process was exceptionally positive. 

The deployment takes too long.

I was not directly involved in the deployment of Veracode. I generally use Jenkins only.

Two people are typically involved in the deployment. 

Every week, on Friday, we put the servers down, and every Monday, we put them back up, to save on costs.

I was involved in the deployment. It was not complex to deploy. It was straightforward. The implementation strategy included looking at different flags and vulnerabilities and deploying in phases. 

We had five to seven people to deploy the solution.

I'm not sure if there may be maintenance required.

Veracode's setup was pretty straightforward, but there were a few challenges integrating it with our continuous integration system because there are lots of components. We wanted our source code scanned daily, so we had to change our build process. It's a bit tricky getting it to work with various parts of our solution. Our product is too complex, and there are lots of applications and flavors.

We did it ourselves because we have sufficient expertise. We're still tuning up our build process and reports. They have comprehensive documentation. We had help from Veracode support, who answered our questions about integrating the solution with our software. It was mostly building and tuning a little to build our software in debug mode and deploy it back into our cloud.

I was involved with the initial setup of Veracode, and it was straightforward. We had a third-party vendor who was evaluating it, so a little bit of the setup was done. However, adding a new application to the tool is easy and self-explanatory. It doesn't take much time at all, and the documentation is out there if we need to look up anything.

Setting up Veracode takes some effort. Their web interface isn't too intuitive. It's also slow, which poses a challenge when setting it up. Veracode provided some help getting it running. 

We did it ourselves with help from Veracode. If I had to do it again, I would do it all ourselves, too, because we got the support we needed from Veracode and didn't require a consultant's extra expertise. Veracode was that expertise. 

After deployment, Veracode requires routine maintenance. Their platform is down sometimes. Our nightly builds occasionally get stuck, and we must reach out to them. There is scheduled maintenance and dealing with issues as they come. I don't know if you necessarily call that maintenance, but it's time-consuming.

I was not involved in the deployment of the solution. It doesn't require any more than ordinary maintenance. That's not a big concern. 

The initial setup was fairly straightforward, although it did take us some time. Our team lacked the necessary technical capabilities since it was a new endeavor. Before Veracode, our company didn't have any other security measures in place. Since it was a new concept, our employees also had a technical knowledge gap, which required some time for learning. However, the deployment process, on the whole, wasn't overly technical. It was done in two or three stages. The first stage involved initial queue meetings to understand the configurations we were using for deploying the code. The subsequent meetings focused on understanding the features we desired, how they would be implemented, and accessed, and their frequencies. Following that, the tech team took over and handled the deployment for us.

Six engineers were involved in the deployment, although the entire working team comprised twenty-two people.

I was involved in the deployment of the solution all the way through, from purchase to acquisition and deployment. It involved a lot of new learning. But we had a very good implementation consultant from Veracode assigned to us who made it pretty simple for us. I don't think we could have done it ourselves.

We did a proof-of-value exercise, which included educating two senior developers. The total implementation time was about two months. We focused on one area of our application and got the scanning process up and running and stable. Then we started applying it to more applications.

We only used two people from our organization to complete the work. Then we educated all the developers about using the extension with the EDI. We then found a person who would be responsible on each delivery team who ensures that their application is maintained within our policy level. Each team is responsible for keeping their application within those standards.

I was involved in negotiating with the vendor and implementing the right solution. I worked with the team members and the end-users of the solution.

Its deployment is straightforward. They have to once go through the complete application analysis and review. They need to sit with the product development and the engineering team to go through the requirements, development environment, and IDE environment of an application. Once done, it is perfectly implemented in one go.

It took one month to have initial discussions, do the requirement analysis, and finalize the requirements. It took 15 days to get it implemented. So, it took 30 to 45 days.

The initial deployment is complex because our system is huge, consisting of hundreds of different binaries. Dozens of teams contribute to the releases, and as a result, a large number of changes are deployed at the same time. This makes it very easy to break something, and there are many people involved in the process.

The deployment required a core team of five, with some additional people on hand to support if anything went wrong. The maximum time for deployment was one day.

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. 

Deploying and implementing Veracode is straightforward. Things get complex when you want to use it.

It doesn't require any maintenance.

The initial deployment was straightforward and took two of us five days to complete the deployment.

Deploying Veracode is straightforward. I did it with one other colleague. 

Veracode is an easy-to-use browser-based solution. It isn't a standalone product like Fortify, so there's no installation. You put in the credentials and start the scan. 

Veracode is straightforward to deploy. It's not hard to connect it, and we had support from a local vendor to help us integrate it into our dev lifecycle. It required only one person from my team. 

I wasn't involved in the initial deployment of Veracode.

The solution is deployed on the cloud.

Veracode is a SaaS solution. We just connect it to the customer's environment. It's very simple. We have plugins for the most popular CI/CD tools and, for other tools, it's one or two lines of code to implement. Generally, we just need one person who has edit access to the pipeline. So one or two people are sufficient to implement it.

There is no maintenance of the solution because it's SaaS.

The initial deployment was pretty straightforward. We ran into some issues, but honestly, nothing out of the ordinary. I would definitely put it toward the easy side. I found the documentation to be appropriate.

The deployment time was days.

We are using Jenkins as our CI/CD. We're using Amazon Cloud K8 deployments.

We integrated it in two different ways. The original way was with AWS CodePipeline. For that, we used Veracode's Docker service. Once we had it hooked up and could send the file, that was pretty easy to use. The second way is we now actually use Jenkins for our code build. We do the same thing although we're going to change to the Jenkins plugin here shortly. But it was still the same, with the ability to use Docker to send the file to Veracode. Once we wrote it, it was really easy, which is why we did it that way on Jenkins. Through both of them, the implementations worked easily.

From the time of deployment, we saw the benefits within one to two months, which was fairly immediate.

There is maintenance required because, sometimes, the pipelines for our code review essentially stop. I have to go and check that, as I mentioned earlier. The second piece of maintenance is that if there are any flaws or false positives, you have to mitigate those results. We have two people involved in the maintenance.

The initial setup was very easy. Because it's a cloud-based service, we were able to do it without the help of Veracode. We just read the recommendations and followed them. We had three guys involved, two developers and one security guy.

It took three months to implement. Our implementation strategy was to do a pilot and then everybody in the organization copied the reference implementation.

We deployed the solution in about three months. We had a team of eight working on the implementation. During the process, I was in charge of, IT was in charge of security, and the AI algorithm.

We don't require any maintenance.

The deployment was complex.

Ten people were involved in the deployment.

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.

The vendor handles the deployment, and we simply need to install the ISM agents on our network. The deployment time depends on the size of the application. Large applications may take up to five days to scan, but on average, it takes one or two days.

The initial setup is straightforward. I deployed the solution myself.

The initial setup was straightforward. I deployed the solution myself within three days.

The initial setup was pretty straightforward. The best way to handle it is to get the Java JAR file for the upload, use the terminal on any given laptop, like a Mac or a Linux, and create a small script that uploads a couple of JAR files up to the platform.

Once that's complete, once you have a proof of concept that works with just a couple of lines, then the next step is to move that into a pipeline. Preferably something like Jenkins. Jenkins allows people to run scripts. You can just run Dash straight in a pipeline. Once you have that setup, you pull all that down into the Jenkins pipeline.

Once that's done, you now have all of the binaries that need to be scanned, and you can set the pipeline to run a scan on a weekly cadence. If you want to take it a step further, you could actually move that into a build pipeline and really follow shift-left practices where you're moving the security aspect of the development cycle further up the pipeline. Flaws are being found before they go into production rather than after they're in production. So that would be my recommended approach for working through that problem.

I went through and I actually added container scanning now, so in Veracode at this point, we're running software composition analysis, static code analysis, and on top of that Docker container scanning. So it's a pretty big product. The thing that would be more helpful is better Jira automation since that aspect keeps track of what's getting done. Then essentially you have a full pipeline setup that automates the generation of tickets, scanning, and just takes care of itself. It's a self-service security tool.

The setup took around a week.

Deploying Veracode is easy. I had the best customer success manager at Veracode helping me. After deployment, Veracode requires little maintenance. 

The deployment was somewhat complex because some of the documentation was outdated, which caused some problems. There was confusion about how to implement the static pipeline scan. It took some time to find the correct articles and speak with the support team to implement Veracode.

The deployment took a couple of hours and required one DevOps and one tech person.

It took us one day to get ready to use the solution. We built the image and copied it during the night to several machines. The following day, we were ready to put it into the container registry in Azure, and then it could be used. We had a huge procedure and scripting. It was not simple.

The team that did it had about six engineers involved.

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.

Two people deployed it from the sandbox to live production. I and a colleague were able to deploy it. Deploying is easy because what I love so much is they have documentation that makes you do things straight away. So, deployment is not hard. It's straightforward.

It doesn't require any maintenance from our side.

Veracode is a SaaS solution. Setting it up isn't simple, but it isn't too complex. We deployed Veracode with a three-person in-house team. Veracode requires a decent amount of maintenance. You must perform periodic validation checks on how the engine is performing. 

The initial deployment was quite easy. All SaaS solutions are quite easy to implement, understand, and deploy. That is the core advantage of SaaS and cloud-based solutions.

Veracode doesn't require any maintenance. It is fully updated by Veracode.

The solution’s initial setup was very easy. Only one or two people are needed for the initial setup of the solution.

Veracode’s initial setup was easy and straightforward.

The deployment is a little complex. There is a small learning curve, but it isn't too difficult. The installation isn't hard, but we need to configure the dynamic analysis where it connects to a hosted application and performs checks. We have to configure the console and set a schedule. It takes a couple of hours to configure a new application.

The initial setup is straightforward. The deployment time depends on the size of the built solution. If we consider a relatively modest number of apps, I would say that they can be up and running within a day or two. We first completed a good analysis of what our customer wanted and because Veracode is a cloud solution, we can have a code scan running within minutes. It is easy to integrate other frameworks and work with applications that are already integrated with Veracode. One product owner or software developer can handle the deployment.

I know how hard it was for our DevOps to set it up.

The deployment process is different for each application. There are a lot of different things that we need to set for this solution. If we have a standardized system, not only using JAR but also other things, then that would be very helpful and make it easier for us to integrate. Currently, there is a lot of preparation that goes into setting up Veracode for integration with our existing applications.

Depending on the pipeline, it takes about five working days to deploy.

Initial setup is very complex, requiring security knowledge, but it’s easy when experts guide you through all the process. Even after months of use, the Veracode experts are always there to help you on both the workflow and the dashboard tool.

The initial deployment was pretty straightforward. It's on-prem so there was no deployment strategy to follow. It took one to two days to deploy and check everything. A team of three to four people worked on the deployment. It depends on the project's complexity as well. As a DevOps engineer, I support a lot of projects within our organization, and the deployment varies from project to project.

In my department, we handle six to eight projects and each one needs a Veracode scan before deployment. As a company, we have multiple locations and departments but only the DevOps team of eight people has access.

The way we work with Veracode is that we have integrated it with Jenkins. We upload the artifacts to the server, trigger the Jenkins job, and the Veracode scan is generated. We have set everything from the Jenkins pipeline. The scan is automated using Jenkins, which means there is no need for maintenance. If there are new steps implemented in the pipeline, there might be some overhead, but it doesn't need any maintenance. We just set the port and everything works fine.

The initial setup is straightforward. Veracode is a virtual platform, so all we need to do is upload the code, and it will be ready to use. The deployment was carried out by one of our senior product managers.

The process of setting it up was fast and easy. Integrating it into our ecosystem was much faster than expected. That was one of the biggest ways it improved our ability to get the code analysis done. 

The reason why it was straightforward is that everybody knows how it has to be set up. All the developers and the testers are well-educated, from a Veracode standpoint, because they have experience with it from the past. It was not a new tool on the block.

I was not involved in its deployment. I am in the quality team. The DevSecOps team takes care of its deployment. That team has 8 to 10 people.

It does not require any maintenance. Everything is done automatically by the vendor.

I was involved in its deployment. It was super easy. The support that was provided by them was fabulous.

There was a delay from our end. It took us almost 90 days to deploy it, which included approvals and other things.

The setup is very simple. I deployed it alone and it took me five hours.

And it doesn't require any maintenance.

Our deployment took a while so I would say the initial setup was moderately complicated. We gradually moved into the pattern we are in today and displaced some other vendors along the way. So it was a slow ramp for us because of our business needs.

We were up and running and operational within a couple of months. And then, over time, we broadened our footprint with Veracode.

Setting up Manual Penetration Testing wasn't complex. None of these solutions are complicated. You get it, set it up, and run it. It has been deployed. They're already scanning, and more developers are being onboarded. 

We followed the implementation strategy provided by Veracode. One person is probably enough to onboard people and set them up. We need one person to concentrate on the strategy and ensure the systems are set up correctly.

The initial setup was straightforward. That was something I really liked about it in my previous job, and it bore fruit right away in what we are doing in my current company. That's one of the reasons I chose them. It's very easy to set up. You can get going quickly and you don't have to learn a whole lot. We were able to integrate it into our system fairly quickly, and start, almost immediately, to generate the results we needed to improve our product.

They do an immediate kickoff right after you sign the contract so you can ask questions like, "How do we set this up? What do we do?" We went through that and, once they trained us on those things, we did not really have a reason to go back to customer support. The product is pretty intuitive. They sent us a couple of videos and provided some early consulting for setup. They have a good process, including a 30-day check-point. Very recently, there was one small thing we needed in terms of knowledge and education and they came back to us with a quick response.

We were ready to run tests within two weeks of setup, and we accomplished running it within a month of buying the product.

It does require much maintenance at all. I love the fact it's a SaaS product. Every time we use it, we're getting the latest version. It's updated automatically. We get decent updates about product management and the roadmap.

Deploying Veracode was straightforward. There weren't many steps. We needed to prepare our API specifications and set up our system. 

Deploying Veracode was straightforward, and we had help from the vendor's support team. Our deployment team has six members, and the whole process took about three weeks. 

After deployment, the product requires some maintenance. We sometimes face some networking challenges that require repairs, and we need to periodically update some tools.

It's only deployed on the cloud. Although I was not a part of the initial deployment, I know for a fact that the deployment can take a long time.

As for maintenance, there are software updates, but apart from downloading the software updates, there isn't any other maintenance required on our side. It's a cloud platform so it self-maintains.

We had some challenges initially, but I think that was due to a lack of training. After deployment, Veracode doesn't require much maintenance. 

We put Veracode in our pipeline, so the process runs automatically during development. It isn't something we can run manually. There are scripts that run when we start. There isn't any maintenance on the developer side. A designated team takes care of all this.

The initial setup of Veracode Static Analysis was reasonably quick.

The IT team set up Veracode Static Analysis, but it's a bit complex.

The deployment can be done in approximately 10 minutes. We use Bitbucket Pipelines and Veracode Static Analysis is integrated into our deployment pipelines.

I rate the initial setup of Veracode Static Analysis an eight out of ten.

I was not heavily involved in the initial setup and deployment, although I understand that it was straightforward. We were able to start using it and scanning our code on day one.

It's all on the web, so there is not much to set up. We just have to configure the access so that the web tool can connect, and it takes it from there.

Except for the Lab component, we didn't have to keep contacting our Veracode account manager.

I was not involved with the initial setup. When we were uploading new applications to their solutions it was very straightforward. Their documentation is really good and very detailed.

In the worst case scenario, if the implementation engineer just runs through the material, you can go on the website for resources. The way they have everything documented is very good. Veracode is very well documented.

We are using the SaaS version of the solution. The initial deployment was pretty easy. The CI/CD pipeline has a lot of dependencies, like connecting with Jenkins and Jira. If we directly upload the code to the cloud, we can deploy the product within a single day. If we do it in the CI/CD pipeline, it will take some time.

I was involved in its deployment. It took me one week to implement Veracode. The process was straightforward. If you are lost or have any issues, you can read the documentation.

The initial setup was straightforward. It was pretty easy to get going and we've incrementally gotten better and deeper as we've used it over the years.

The initial setup was manual uploads of applications, and then it was about incorporating it into our build pipelines and using the sandbox to support our microservices architecture. We've gotten more mature over time, but time to initial use and results were very easy.

Only a very short time is required for deployment, as there is very little that has to be done. Ours was completed within a couple of days and that's a matter of coordination in terms of getting our teams to upload a solution and figure it out. It was a learning experience for us but there was no time or delay brought on by the solution.

When we first began with Veracode, the initial strategy was just to get our first solution uploaded and scanned and see what the results looked like. We didn't have a systematic history of doing that, back then.

With approximately 500 employees, we're not a huge company. Deploying it in an enterprise company would be a different situation but for us, it was just a matter of understanding how we needed to configure the platform and how we needed to provide our software and states and get good results.

It probably took a couple of uploads of trial and error and we were running.

The initial setup was moderately complex. The onboarding of the tenant, single sign-on, and access control were easy, but when it came to the real work of integrating the Pipeline Scan and our ticketing system, that is broken at this point. I spend most of my time manually doing this, and if they could fix that portion, that would save me another two hours worth of my time with every release.

The deployment took two to three weeks.

Because this was a SaaS service, we just onboarded one team, then looked through some of the gotchas from login and access perspective. Once the pilot users were all cleared up for any potential issues, we then onboarded the rest of the team. We have a small team of 40 users from a development perspective.

It's pretty straightforward from an onboarding perspective because it is all SaaS. We just needed to whitelist some IPs from Veracode for scanning some of our code, which are not publicly available. Beyond that, everything was pretty straightforward.

At the time that we set it up, it was quite complex. Now, they have made it pretty simple to use and a brief process. However, we felt the process was quite complicated when we did it. For example, when we initiated the static scan for the JavaScript, we needed a lot of instrumentation. That specific instrumentation that needs to be done at the JavaScript layer. Now, they can accept the bundle as it is and still identify the issue at the line number level. So, that is an enhancement.

They have done some improvements on the triage screen where you can look at all the issues. You can perform various actions over there, like mitigations or adding comments. They have simplified that interface a bit and made it a little faster. Earlier, we used to take quite a time for the check-in and check-out operations. However, now, it is quite fast. If we had to redeploy it from scratch, it would take around 30 minutes.

To start a static code scanning, do an upload, and start a scan, it hardly takes 10 minutes.

It was easy. It's very straightforward. There's nothing complicated about it.

The product is deployed on the cloud. We have a multi-cloud environment.

It is pretty much straightforward. It is a cloud-based solution. So, creating a user in Veracode is pretty much easy. It involves just a few clicks. Uploading the code is also pretty much easy. It is user-friendly and developer-friendly.

It was pretty straightforward. The problem that we had was mostly about our solution's architecture because the solution itself is big and heterogeneous. Some parts or regions are using the Java platform, and some parts are in the .NET code. The main problem was to correctly build our solution for Veracode. This was the only challenge. Veracode provided us with good functionality with their Jenkins Plugin that made it possible for us to automate our daily development. So, the main problem for us was mostly related to properly building our solution and using it in Veracode. It was pretty straightforward. There was nothing complex, but it needed some work from our side.

The strategy for Veracode implementation was pretty straightforward. From the very beginning, we stuck to the idea that it should be automated because all modern DevOps practices and approaches, such as Infrastructure as a Code, are widely used in our company. So, from the very beginning, we decided that it should be coded, and it should be stored in source control and uploaded. Veracode became a part of our process of everyday deployment, and it was a part of our strategy to make it a part of our life and use it as much as we can.

The number of people involved depended on the stage. At the initial stage, when we were evaluating it, there were somewhere around six or seven people who were making the decision of buying Veracode and other stuff. We have different companies and products inside our organization, and each and every product team is responsible for implementing it. We were the pioneers in using the solution from Veracode, and later on, it spread out to other projects. Now, we're acquiring additional licenses and so on. We planned everything with the help of the developer team. We follow the agile approach in our development, so everything was planned. User stories were created, and we just acted on them.

The setup was easy and straight forward. We had some issues with API calls from our build automation tools, but this was related to networking issues in reaching the Veracode servers on the Internet, not the Veracode product itself.

The initial setup very straightforward and integrations were up and running in a matter of days after purchase.

The initial deployment took around four months and required five people.

It is a SaaS solution. Its initial setup is straightforward. I started with the most critical applications and automated the scanners inside the pipeline. After getting the results, I aligned the security policies. I prioritized the most critical vulnerabilities and assigned these reports to different groups and teams. I also integrated the other plugins into the IDE.

The initial deployment was not very complex. It took us around 15 days because we were trying to understand the policies and many other things. Our team has 15 people and everyone was involved in making some decisions regarding the solution.

We have only needed help with the product itself. That's what we have reached out to their team for. But there hasn't been any maintenance of the product for us.

There isn't much of an implementation. We upload binaries to the Veracode platform and they are scanned and processed according to certain policies and security requirements. Then we get the results.

We are working on implementing Veracode SCA with our biggest product.

We want to integrate the software composition analysis with our CI pipeline and we are working on it, but because of the size of the application we have encountered some difficulties, things we have to tackle technically.

It's problematic if you want to integrate it with your pipelines because the documentation is not so well written and it's full of typos. It is not presented in a structured way. It does not say, "If you want to achieve this particular thing, you have to do steps 1, 2, and 3." Instead, it contains bits of information in different parts, and you have to read everything and then understand the big picture. Hopefully, then, you can integrate it.

Regarding the recommendations provided by Veracode scanning engine, we have our own way of dealing with the software composition issues. We plan to change them, but not very soon because it was really hard to impose Veracode on our whole group and for all product lines, as Veracode is a relatively new technology for us. We have had it for one year, but the change has not been so easy. We will try to combine all of our strategies in the Veracode platform in the future.

The initial setup was straightforward for us, and minimal, since it is a SaaS product.

The major component is being granted access to the tool. They then engage a customer success manager to help you understand and give you an overview of the interface itself and to walk you through some example setups. We were able to work with the CSM to configure a couple of our production scans. He did some hand-holding for us through the process until we felt that we understood it enough and had repeated it enough to do it on our own. He also provided detailed reviews of reporting, et cetera.

Deployment took less than an hour, although we have a small environment today. It would, obviously, take much more time with a larger organization.

Because we were migrating from one solution to another, it was an easy migration path. We just needed to collect the information from the previous solution and replicate that within Veracode.

One thing that can be difficult—and it was in our previous solution—is creating the login component for the scans. The learning about how to create that was a little daunting at first, because you have to create what they coin a "login script," but it is really just a recording of a login. Once you get it down, creating those "login scripts" takes less than a minute.

One of the struggles we have had with that recording process is that we have had to redo it more often than not if our developer has changed, even in some minor way, the way they collect information for the login. That does affect the script. That can be a little frustrating at times, but unfortunately, it is a known behavior apparently. It's just the nature of the beast if you do make any modifications to login.

As for admin of the solution, we have one person involved and it probably takes a quarter of their time or less. There is no maintenance since we have the SaaS product, other than ensuring that the scans that we have set up are still scanning successfully and that we don't have any failures.

The initial configurations were okay, but then the integration to the CI/CD pipeline was not so smooth. We had multiple rounds of calls with the Veracode engineers to get it up and running.

The initial setup was somewhere between straightforward and complex. I am not a developer, so I would not know how to package these codes and send them in for a scan. What I prefer is if there could be some mechanism where if I am a layman, then I just need to run a scan of the application. After that, there should be some option where I can get the project details. Instead of doing the packaging or some changes in the uploading part, this change would really help anybody who had to run the scan.

We have multiple applications developed at our organization, but it didn't take much time to deploy the solution to each. If a new application comes into picture in our organization, we provide access, so they can start running the scan in one or two days.

The initial setup was pretty straight forward. That is part of it being an easy solution to get started with.  

The deployment started smaller in employing the product to analyze a subset of our applications. It initially was being employed to look at the vendor applications that we had. I would probably say that initial period was about three to six months. That effort was focused on one group and did not really include all of the technical people and developers.  

Once we saw what it could do, it got adopted and we rolled it out to more people. So we kind of employed it in stages. The first part, which was essentially a test period, was three to six months. Then pushing it out for broader adoption in the next part was another three to six months.  

The setup was straightforward. It takes some time in the beginning to onboard, but our onboarding process was easy from the moment that we actually connected the Dev team with Veracode. It's normal to have a certain degree of difficulty in the beginning but we didn't have any major problems.

Our deployment took between a month and 45 days.

We migrated from another vendor, so we first picked the services that we needed and the type. We started with the same scans that we had with the other vendor, and then we divided the work between the different teams. We had to have the iOS team onboard and the Android team onboard. I presented the new tool to them and created the accounts and, after that, we had parallel projects to onboard the different scans. It was definitely easier because I had different teams taking care of each one of the scans, meaning I could do everything in parallel.

For the dynamic scans we had one person involved from the technical support team. It was super-straightforward and super-easy to do. It took us a couple of hours to do it. The static scan takes a little bit more time because you have to prepare the packages. But we already had the packages ready because we migrated from another vendor. It took us some time to adjust the scans, but the actual work of uploading the packages took less than a week.

The initial setup is straightforward. It took us three months to deploy the entire solution across all the squad at our site via Pipeline Scan as well as have the squads adopt it. If you are familiar with security, you can be up and running with the solution in a week's time.

Our implementation strategy was to give the Greenlight ID plugin to all the developers and enable the microservices. Then, we wanted to let the non-human account use the new unlimited account and all the source code. This has helped us in last year and a half, as we have over 150 microservices being scanned by the Veracode platform.

It was a bit complex initially when we started, because we had not been previously exposed to any such tool.

It is a SaaS tool. So, towards the end, we did not have to install anything. We just needed an account for the platform to upload the build. There was an initial issue, because people were not previously exposed to this type of process, and it was something new that they were being asked to do.

The implementation is straightforward in the sense that there are a lot of APIs to integrate, and they have a lot of connectors that do that for you.

The initial setup was somewhat complex. The deployment took a couple of weeks because we needed to resolve numerous technical issues that we had to understand first. We had six people involved in the deployment.

Initially, the setup was complex for those who had not done solution integration. However, my team was able to pick up after the refresher course. 

The initial setup was pretty straightforward but, depending on the type of applications or the types of code that you're using, the setup requirements may be a little different. It takes a little getting used to, based on the environment in which you're working.

For example, for Visual studio, it might have specific requirements that are needed to package an application for scanning, whereas an Angular application would have different requirements. For me, as a non-developer, the issue would be around understanding those different requirements for each development environment.

Our deployment didn't take long; it took a couple of days. There were three people involved in, including a developer, someone setting it up, and a code reviewer. By "setting it up" I mean putting in the applications, saying what the application does—providing the business rules of the application.

We didn't have a specific strategy for deploying it. The software is pretty straightforward, once you have the application bundles to be scanned. There's not a whole lot to do after the packaging.

Maintenance-wise, it doesn't take much because it's SaaS. We don't really do much on our end.

The initial setup was straightforward. What I recall is that it was not really difficult and we had optimal support. They also provided us with documentation to help set up integration with tools such as Jenkins.

The initial setup of Veracode Static Analysis is in the middle range of difficulty. We had some minor issues but we had some guidance and support. It took us approximately one month to scan all of the microservices.

The initial setup for manual scan uploads is straightforward. Pipeline uploads can take some effort to get to work right. Setting up policy rules and charts for results is reasonably easy.

The initial setup has a moderate level of difficulty. It's neither simple or complex.

The initial setup was straightforward. It was extremely easy and took only a few hours to deploy.

The SAST tool is pretty straightforward; there is very little complexity. The pipeline works very well. The SCA tool is more complex to set up, and it doesn't integrate very well with the SAST tool. At the end of the day, you have essentially two separate products with two separate setups. Also, you have two different reports because the report integration is not quite there. However, I'm hopeful that they are going to fix that soon. They acquired SourceClear less than two years ago, so they are still going through growing pains of integrating these two products.

The setting up of the pipeline is fairly straightforward. It works a lot of the main languages, like Java, Python, etc. We have deployed it across several development teams. Once we create a pipeline and hand the code to the developers, they have been able to make a little adjustment here or there, then it worked.

The APIs are a bit nonsensical, but otherwise straightforward.

The initial setup is easy and quite well documented. I was really impressed by the quality of the technical support. When I had problems, that the product wasn't good enough for me, they were always there to help and give suggestions.

Being a service, there wasn't really much of an implementation. It's not complex to use.

It is a pretty easy implementation. As you know, with anything like this, which is very human-oriented, change is people, not necessarily the products themselves. The services they provide and the training and some of the "hand-holding", if you will, have always helped make this the bright, shiny object for the coders, so its implementation has always been pretty smooth for me.

The setup has been more of a phase-in approach, and it's been gradual. It's been kind of a "trial-by-fire" setup with a lot of our development teams because most of our development teams aren't used to doing this. So, it's been a trial, I guess more so on our side, to get the adoption going on. It's just part of training our team to actually know there's something they need to do on a regular basis.

It was very straightforward. Veracode was very helpful, hand-holding - anything that we needed - they were right there and made it very simple.

To get into the solution, it took some tries to understand the structure of our repository and the code that we were using to write dependencies, etc. So, it took a bit of time, but then in the end, the solution was easy to connect.

It took about a month until we completed integration of Veracode tools into our own systems. Eventually, the tools needs to scan our code that resides on our machines in our on-prem environment. The integration of Veracode on the cloud with the on-prem repository and our processes took time. We worked with the Israeli representative of Veracode to help us. However, it was about a month overall until we stabilize it.

The initial setup is very simple. The Veracode guy who accompanied us made it appear really straightforward.

It's a SaaS solution so once it's prepared on the Veracode side, to deploy onsite may take up to a couple of hours to get everything prepared, mainly due to the configuration, for a simple implementation. Overall, setting up the product is quite straightforward. 

In terms of managing the code, it's quite simple for us because we are all technical guys. Once we saw it working, it was really easy to manage. We have three people who use the solution and they are all developers.

I was involved, on a cursory level, with the setup. Our implementation strategy was to focus on our main web-based application. The way that they developed the application here was under one static set of code, so we could scan this code and, in essence, be able to check the vulnerability of most of the applications from the different business in our agency.

This solution was already deployed when I was hired. I can't speak to what the deployment process was like. 

The maintenance is minimal. I just need to create accounts for people who want to scan by themselves and that's it. It's easily maintainable.

Straightforward. Just add the applications in the portal and start scanning.

The initial setup was very straightforward.

1. It is SaaS, so we did not have to install anything locally.
2. We were able to give our privileged users better roles because it is role-based, and to do multi-factor authentication. All we have to do, once we set up our trust relationship, we have single sign-on and we white-listed everything. So, it is everything that we wanted from a security point of view, and it is easy to roll out.

I would rate my experience with the initial setup a six out of ten, where one is difficult and ten is easy to set up. 

I wasn't that involved in the setup. I was basically a reviewer after it was all done.

The initial setup was straightforward. As it's a SaaS solution, it took no time to set up. But because I didn't take training, I spent a bit of time figuring out the product. No implementation (or strategy for implementation) was required, beyond some simple configuration settings.

Setup is really simple, just use Jenkins, JIRA, Visual Studio, and Eclipse connectors for on-premise. The rest is online.

It was very easy. The cloud instance got turned on, we had a support rep dedicated to us to help us get up and running. It couldn't have been easier.

The initial setup can be a little complex for people or for organizations that don't have technical skills. Another small thing is that you need to have one person who's fluent and technically knowledgeable to help during the upload process. But otherwise, it's pretty much straightforward. It's not an issue, it's perfect.

The initial setup is difficult. For example, in Android, if I need to scan an ordinary APK Android application, we need to generate the APK and when you are working in GitHub, you need to do a lot of work to make these combinations able to be scanned by Veracode.

The initial setup was pretty complex. We had to integrate it with our CI/CD pipeline. This required writing custom code. Once it was integrated there, we had to have the development team make some changes to how they pushed a release to a special branch so it would go to Veracode on a weekly basis. And once it started raising the issues, we had to work on that JIRA-Veracode integration, which was not straightforward at all and required a lot of debugging help from the Veracode engineering team. They provided that and that was great, but ideally it would show you the error messages so that you don't need their help.

The initial deployment took about two or three weeks and then we had to come back and tune it several times, so there were another two to three weeks of tuning. Altogether, it was about six weeks of effort on our part.

Initially, we had one person working on the deployment, and then I started working on it as well. Later, there were four of us working with Veracode during these calls to try to do the policy tuning and figure out if we could make it work better for everyone.

We had six people using the solution: four software engineers and two security engineers.

It was already implemented when I joined the organization. However, we have expanded greatly.

It was straightforward. We went from signing a deal on December 30th, to performing that first scan on January 5th, to completing that scan and starting to remediate issues on about January 15th. And that is one of the fastest wrap-ups of any technology that I've been associated with.

Without the API, it would have been extremely complex. It would have been very painful because it would have been a very manual process of submitting applications. 

I am fortunate enough that I have a pretty strong development background, so I do a lot of coding myself. For the person without development experience, using the API would have been very difficult. Where I work, we're a little unique in that sense.

But the rest of it, it's a cloud-based solution. I'm kicking off all my stuff over to Veracode and it's running in their environments and producing results. There's not a whole lot of setup besides that. It's not a big cost on an any infrastructure that we have to run or support. So, pretty painless really.

The initial setup was extremely straightforward.

Easy.

We've had no comments from our customers other than that it is an easy setup.

Setup is very straightforward. Since everything is SaaS, everything is uploaded to the cloud. It's very simple to do. There is no setup on the back-end, initially. Once we start getting a little more sophisticated with integrations we are going to be just fine. Currently, we are early in the program so everything is done manually. So there is no setup. Everything is just done in the cloud.

It was pretty straightforward.

I manage the Veracode suite for my company, and I was personally walked through the various steps. Once I was up and running, we had another two-hour session to explain to us how a proper Veracode assessment should be planned (developers, code reviewers). As a result, I believe we have not only a pretty solid code review process up and running, but this was all provided to us at no additional cost.

What we felt is that the Veracode guys want to enjoy and use their solution first. They are not pushing to get consultancy time if that can be avoided. If you need consultancy time you can have it and the prices are convenient. We did not. All the help came at no additional cost.

The initial setup was not complex. It was pretty straightforward. However, the integration and automation of the CI cloud was a nightmare. 

Deployment varies. sometimes it takes three months. Sometimes it only takes one hour. The average is one hour, but we have experienced much, much longer deployment times.

Straightforward.

We have a few team members that specialize in the solution.

Our team handles the maintenance of the solution.

The initial setup is pretty straightforward.

I think it's simple, but sometimes it would help to have more training for developers to help them set it up.

It was very easy to setup. Everything on the website was clearly explained.

The installation was straightforward.

Straightforward to set up, but the configuration of the rules engine is difficult and complicated.

We just use it as a cloud service for third-party developers.

Setup is straightforward.

The initial setup of this solution is straightforward.

The initial setup is a little bit complex.

It seemed straightforward. I didn't actually do the work, but from what I was told, it seemed like it was fairly easy to get going.

Somewhat straightforward. There was a little confusion about "missing modules" that are third-party files that we couldn't upload because we don't actually have them. That really confused us, but the technical support resolved the confusion.