Veracode Reviews

My company produces a SaaS application that is used by very large customers for pricing analytics and sales workflows. The data that our customers put into our software is very sensitive and confidential. This means that they want a high degree of confidence that our solution is secure.

We use Veracode as one of the pillars that we can point to as helping us to deliver on the promise of having a secure product. We have a multi-dimensional security program and Veracode is one important aspect of that.

Veracode provides guidance for fixing vulnerabilities. It provides guidance to help us understand what it flags, and what we can do about it. It still takes some interpretation and insight on our side, but we aren't generally security experts, so we get good information from Veracode to help inform us.

The developers are able to understand the types of issues Veracode looks for, and then as they see that happen, it helps them to learn. It's good because they consider it the next time and hopefully, we don't need Veracode to flag the issue because there is no issue.

With respect to efficiency when it comes to creating secure software, Veracode is able to help us with very low overhead. There's not a lot of work needed on our side unnecessarily. Once we've wired everything together, it's seamless to get the scan done and get the results back and know what we need to do about them.

We use Veracode for some of our older, more monolithic software, as well as for our newer solutions, which are designed to be cloud-native. We've found Veracode useful in both use cases; first, with our huge monolithic software, as well as with our microservices cloud-native solutions.

In terms of AppSec, there are a lot of benefits that cloud-native design brings in terms of not only cost and scalability, but testability and security. Certainly, the design patterns of cloud-native are well aligned with delivering good security practices. Working with products that support cloud-native solutions is an important part of our evolution.

Using Veracode has helped with developer security training and skill-building. It's definitely a good way to create awareness and to deliver information that's meaningful and in context. It's not abstract or theoretical. It's the code that they've written yesterday that they're getting feedback on, and it is a pretty ideal way to learn and improve.

The static scan capability is very powerful. It's very good in terms of the signal-to-noise ratio. The findings that we get are meaningful, or at least understandable, and there's not a bunch of junk that some other code scanning tools can sometimes produce. Having results like that make it hard to find the valuable bits. Veracode is highly effective at finding meaningful issues.

The speed of the static scan is okay. It meets or exceeds our expectations. For our monolithic application, which is a million lines of code, it takes a while to scan, but that's totally understandable. If it could be done magically in five minutes, I wouldn't say that's bad. Overall, it's very reasonable and appropriate.

Veracode has policy reporting features for ensuring compliance with industry standards and regulations. We have one such policy configured and it's helpful to highlight high-priority areas. We can address and help focus our effects, which ensures that we're spending our time in the best way possible for security movement. The policy is a good structure to guide results over time.

We use Veracode as one metric that we track internally. It gives us information in terms of knowing that we are resolving issues and not introducing issues. I cannot estimate metrics such as, for example, Veracode has made us 10% more secure. I can certainly say it's very important when we talk to our customers about the steps we follow. We do external pen tests, we do web app pen tests, and we also use Veracode. It's certainly very helpful in those conversations, where we can state that it is one of our security practices, but there's no outcome-based quantitative statistic that I can point to.

The static scan is the feature that we use the most, as it gives us insight into our source code. We have it integrated with our continuous integration, continuous delivery system, so we can get insight quickly. We're doing scans daily, so that's the most important feature for us.

The interface is great. It allows us to look at our different applications, understand all of the different types of scans, as well as the results. The types of testing include SAST, DAST, and SCA, and it pulls all of the information together into a single view. It also produces reports that we can give to our customers when requested.

Veracode certainly provides a quick and intuitive way to understand the results, to see the context of them, and to identify what we need to do to address them. In general, it's a pretty quick way to get the information that we need in the most useful way possible. Then, we can turn around an action plan.

We have it integrated with our build pipeline and that works well. It's very important because we don't have to complete a separate, manual step of sending the software up to Veracode to scan it and get the results. It's great. the more things that we can integrate into the build pipeline, the better. It's a very positive thing.

Veracode is very good in terms of not having a lot of false positives. It would be very frustrating if a tool gave you 10 good results but 50 false positives. Even with the issues that we get that we choose not to address, we can still understand why they're being flagged. We have found that the results are meaningful and accurate, which gives us confidence in the solution when fixing vulnerabilities. 

We may choose not to address them for different reasons. For example, it could be because it's an issue about input sanitization, but we have another layer on top of that component to handle that task. We can recognize that it's important that Veracode is flagging those things at that lower level, and that they're bringing that additional insight and consideration to the designs that we're choosing. Overwhelmingly, even the issues we choose not to address are still valuable and meaningful, so the actual false positive rate is quite low.

This is a very useful and powerful tool that ensures our code is well-designed and correctly implemented. It is important that it's only one aspect of a security program and not the only insight or the only test. That said, it provides us with some pretty important feedback and insights that we wouldn't have a great way to get otherwise.

The ideal situation in terms of putting the results in front of the developers would be with Veracode integration into the developer environment (IDE). They do have a plugin, which we've used in the past, but we were not as positive about it. The pricing model was expensive and the results were not the same as the full solution analysis. It gives a differently scoped "just in time" analysis within the context of the IDE, so it didn't speak to the same problem space.

The best situation would be the one where the developers don't even need to log into the web portal, and the results from the scans would be delivered into their IDEs. It would be an asynchronous job, but if they could see the results right there, while they're working on the code, then they wouldn't need to go to a separate tool to look at the information to figure out what to do next.

The workflow today on the build side is optimal, so imagine that's still doing the same thing but then in the backend, whenever a developer has that project open in the browser, if they chose to, they could enable a view to see the most recent Veracode results of that module. That scan might be from last night or six hours ago or any other point, and that's fine. It would be the best possible situation to put the results and the actions right in front of the developer, in the tool that they're already using when they're touching the code.

The only other thing that we've found a reasonable workaround with is how to work with microservices in the context of Veracode. This was necessary because Veracode's licensing model and the interaction model are built around an idea of an application. When you're talking about a section of business logic that's being delivered by possibly dozens of microservices, there is some friction with Veracode in terms of how that application gets defined and how the scans occur and get reported on.

When we reached out to Veracode about this, I got a slide deck that provided us with different options of how they recommend proceeding in this context. It was helpful, and clearly a question they've considered and they had answers ready to go on. The ideas helped us and essentially reinforced what we were already thinking. It's getting the job done, but it still feels like a little bit of a square peg in a round hole and it could be a little smoother in terms of that interaction.

The problem boils down to how we fit the microservices architecture into the Veracode notion of an application. We need to be able to get a holistic view across the microservices, which is extremely challenging, especially when those microservices are owned by different teams who have different needs to see and respond to the scans. 

I have been using Veracode for between five and six years.

The stability is great. They've probably had some downtime, but I don't know about them. From our perspective, it's been solid.

I know the web portal has some planned downtimes because I see the splash screens about them. They're good about warning you, but they're also performed at very weird times, like the middle of the night, so it's never blocked me from getting in when I need to get in.

We use Veracode for all of our software development. We have more than 100 engineers, and our entire engineering team is using it. Obviously, every team has some designated people who look at this more than others, so not everybody's in there every day, but in terms of the software we write, we know that it's all being scanned constantly.

Over the last few years, we've made a couple of acquisitions of other companies and when we've done that, we very quickly brought those solutions in as well. We've seen the value and because of that, it's part of our onboarding process when we integrate other companies into our environment.

If we create another solution or we acquire another company, we will certainly expand our use of Veracode to match within our current solution stack.

The support has been good at understanding issues. There are two aspects of technical support. One concerns issues with the platform in terms of functionality, and the other is that they will provide you with assistance in terms of interpreting your findings.

Our experience from the technical side is that they helped us with figuring out how to best use the platform for microservices applications. They were very helpful in that conversation.

We also have experience with the other layer of technical support that Veracode provides, which is where you can get consultations about the findings. We've done a few of those where you set up an appointment with a Veracode engineer. It helps to understand the results if the platform isn't totally clear on why something is a problem or what we need to do about it. For us, that's been pretty good.

Obviously, the Veracode engineer doesn't have the full understanding of what our application does and in a short call, you can't possibly do an architectural deep dive to understand the context of an issue, but their conversations have been useful when we've had them in terms of understanding issues and context and if we need to do anything.

Prior to using Veracode, we used other code quality scanning tools, but not anything at the level of Veracode for security issues.

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.

We implemented the solution in-house. It is not that complicated.

In terms of maintenance, there is certainly some overhead involved for each team. They have to make sure that the build pipeline integration is still working and essentially, that we're still getting results. Occasionally, for whatever reason, it breaks and somebody has to go in and fix it.

I can't say that there is no staffing required for maintenance but it's rare. In total, a few hours a month across the company is spent keeping it going. More time is spent evaluating and resolving the findings, which is part of our development work. That's not imposed by the solution but rather a positive outcome from using Veracode. As such, I wouldn't count that as maintenance. 

We have seen a return on our investment with Veracode. I can't point to a dollar figure, but I've been directly involved in customer conversations where we can talk about our security program and how Veracode is an important element. We've distributed report summaries and talked about results with our customers and having this information in those conversations is definitely valuable.

It's also very useful that we can talk about it with our security auditors. We have SOC 1, SOC 2, and ISO 27001, and they don't specify that you must have a static analysis tool. But when we need to maintain secure engineering practices, having a tool like Veracode is very important for us to demonstrate that to auditors. There's certainly value there as well.

There is also a tremendous value on the marketplace that we get from having those security audits and certificates, which is a second-order of value that Veracode drives.

I can't say with certainty that Veracode reduces the cost of application security, although I would say that it focuses our effort. It gives us guidance and prioritization on where we should spend time. Otherwise, we might not know about particular issues. We might inadvertently spend time on things that aren't that valuable. So, the value is more about focusing on where we need to spend time.

From a cost perspective, it seems okay, although we will probably evaluate alternatives next time it's up for renewal because for us, it's a relatively high cost, and we want to make sure that we are using our resources most appropriately.

I like that the platform provides you with some flexibility. We had to revise our licensing because it did not fit our environment. We wanted to license based on the number of applications, rather than another measure such as the number of lines of code. There was clearly some complexity that led us to be in that situation, although it seems preventable. Ever since our last renewal, the licensing has been smooth and clear. There is a certain amount of flexibility in that regard but also, they allow us some leeway in our current model.

There have been times when for some reason, we spin up a new application on a temporary basis. It may be because we're trying a new configuration. Even though we're licensed for a certain number of applications, the platform lets us exceed that. Consequently, we receive an email stating that we can't do that forever, but it's very useful to have the flexibility for the couple of times that we've used it to briefly exceed the application account.

I am not sure what other solutions, if any, the company looked at before choosing Veracode initially. We have renewed it since that time and we pretty quickly decided to stick with Veracode, rather than switching. However, because of the relatively high cost, we will probably evaluate other options next time it's up for renewal.

We see at least quarterly updates about new features or things that have been fixed. It happens without our involvement, which is great.

My advice for anybody who is considering Veracode is to test it. Although I have not compared Veracode against other products as part of an evaluation process, it would be very useful and very easy to actually try it. Top-load your application, get the results and take a look at what Veracode finds. This is the most useful activity somebody could do.

This is a product that lives up to its promise. It's easy to use, and it's predictable. There are some improvement opportunities but on the whole, it's very good at what it does. 

I would rate this solution a nine out of ten.

There are three areas where we started using Veracode immediately. One is static component analysis. The second is their static application security test, where they take a static version of your code and scan through it, looking for security vulnerabilities. The third piece is the DAST product or dynamic application security test.

We also use their manual pen-testing professional services solution in which they manually hit a live version of your product and try to break it or to break through passwords or try to get to your database layer—all that stuff that hackers typically do.  

One of the big things for us, and something that I realized because of my experience with engineering teams for more than 20 years, is that when it comes to security, changes are happening so fast. The vulnerabilities are being uncovered so quickly that we cannot go at this alone. No matter how big an army of engineers you have internally, who scan systems, study security engineering best practices, and do a lot of research, there is no way for an individual organization to keep up with everything that's going on out there. Leaning on an expert like Veracode, a company where this is their only job, is absolutely critical for us and game-changing. It really took it up a notch for us in terms of identifying challenges before they occur.

We were using best-coding practices already, but the question was, is that good enough? The first thing we got out of Veracode was a quick validation of our processes. They said, "Oh this is great. What you've been doing is extremely good. Now keep doing what you're doing from a design and development perspective." But, yes, the world is changing so fast that we also want to make sure that we stay ahead of best practices.

When OWASP, which is the main group that puts out lists of the top ten security issues, updated their list recently, Veracode provided it to us, even though it was something that was right off the OWASP website. When you're with Veracode and you're talking about it, your engineers pay extra attention to it. They look through it and they think about what they can do better when they code. We felt we couldn't go at it alone. We needed a partner. Veracode has been a great partner so far for us.

The four products we have from Veracode give us visibility into application status and help to reduce risk exposure for our software. That is one of the things we like about Veracode a lot. There is a single area on the dashboard where you can get a full view of all of the tests and the results from everything. There is a nice, very simple graphic that shows you the types of vulnerabilities that were found, their severity, the scoring, and in what part of the code they were found. All the details are together in one place. Having one area where we get all these results, rather than having to run around and pull reports together from four or five different places, is very helpful to us.

The solution has also definitely reduced the cost of application security for our organization. But the point is almost moot. Thinking about security engineering costs in a silo doesn't make sense anymore. You need security to be integrated completely into your product. Ten years ago, or even five years ago, we would have hired a couple of security engineers who would have been solely and entirely responsible for software security. They would have done their best using some integrated tools and some manual tools. But in no way would they be close to being as efficient and capable as Veracode's tools.

Hiring engineers would be a bad idea because, aside from their being more expensive than Veracode's tools, guaranteed, two security engineers are not going to come close to identifying all of the issues and challenges that Veracode is uncovering for us. Veracode has a large team that is constantly learning, growing, and engaging the industry as a whole, to understand the latest and greatest for security best practices and security vulnerabilities. Two engineers don't have the time to do that much work. To me, it's not even a question of budget. It's more a question of leveraging an industry leader that has core competency in this area. We need a partner like that to work with us.

With the static component analysis, they scan your code statically and they look specifically at third-party libraries and at any third-party code that you have in your product for vulnerabilities, updates, and changes in licensing. For example, if one of them changed from a license that allowed for more changes on your side to something that is more restrictive, they would flag that for you so that you can evaluate it and know immediately that you need to take some action. They keep abreast of the latest and greatest regarding third-party components. That has been good and very helpful for us to know how secure our product is as a result of using third-party libraries, as we didn't write that code.

The SAST component looks directly at our own code and any best practices we haven't followed and whether there is a security challenge or loophole. We get immense value from that as well. They've been able to flag items and say, "While this is a low-risk item, we would suggest you refactor it or add it to your roadmap to close that loophole, just in case a very clever hacker tries to get around your system. That has been very helpful to us too.

And the SAST is very quick. It sniffs through the product very quickly and almost immediately gives us the results we need. Static analysis is something you do every once in a while, in a very regimented and rigorous way, so you don't need it to be super-duper fast, but you need it to be efficient. You don't want to wait days for them to give you an analysis. And Veracode's static analysis comes back in a very short period of time.

With the DAST, you provide their product with a dynamic instance of your operational product, by pointing the dynamic testing tool at your product. It beats it up, pokes around, and tries to find ways to penetrate its defenses and find security issues and challenges within your product.

Veracode also has a very good report that gives us best practices regarding ensuring compliance, and we can go back to them for additional consulting. We've not had to do that. We typically scan through it and say, "Okay, it's good that it meets those best practices." We rely on them to make sure that their products are kept updated, so that we don't have to review a lot of these standards issues.

Also, as we did our analysis of Veracode, we loved the fact that they are completely integrated into GitHub. You can trigger everything using GitHub Actions. You don't want to go too far out of the application, move something into another repo, and have to write or copy and paste it over. Veracode easily integrated into our GitHub repos.

One thing I would strongly encourage Veracode to do, early on in the process—in the first 30 days—is to provide a strong professional services-type of engagement where they come to the table with the front solution engineers, and work with their customer's team and their codebase to show how the product can be integrated into GitHub or their own repository. They should guide them on best practices for getting the most out of Veracode, and demonstrate it with live scanning on the customer's code. It should be done in a regimented way with, say, a 30-minute call on a Tuesday, and a 30-minute call on a Friday.

I would ask Veracode to be a lot more engaged with the customer and set up live sessions where they force the customer to engage with Veracode's technical team. Veracode could show them a repo, how they should do things, this is what these results mean, here is a dashboard, here's the interpretation, here's where you find the results. And they should say, "If you don't understand something, here's how you contact customer support." A little bit more hand-holding would go a long way toward the adoption of Veracode's technology.

I'm familiar with Veracode from a couple of companies. One is my previous company. We had examined the platform and trialed it for use. When I joined my current company, about six months back, I looked at various platforms that we could use for both static and dynamic testing of our code and I naturally picked Veracode. I had familiarity with them and experience with them. We did some research on them and we did a couple of reviews with my engineers, and then I decided to sign up with Veracode.

It's a very stable solution, absolutely. We've had no issues with it. We have not had to poke around and report bugs or anything of that sort.

We have not had any scale limitations thus far, not even close. Maybe it's the size of our repositories and what we do, but for our needs, it has been super-scalable.

It's being used by all my teams now. I'd like it to be used even more often by building a tighter integration into our regular SDLC practices. I'm hoping that that happens over time. That is one of my focal points as I start to plan for next year.

We bought their premier service package and that allows us to have access to their consultants, their customer support, and their customer success manager so that we get a higher level of service from them. We took the premier package from day one because we needed the consulting hours, help, and training from them.

Every month or so we have a call with their customer success group. Sometimes we come prepared and say, "Hey, we want to talk about these specific five things," and other times we just ask them to give us their latest and greatest and to update us on what has happened since the last time we spoke: What did you add to the product? What did you find? What should we be watching out for? They alert us to new vulnerabilities and things that we should be looking for.

We also do a hands-down, tactical Q and A, where we ask questions like, "Hey, we tried to do this and it failed," or about challenges we had and how they suggest we go about resolving them. I pretty much have my entire team on these calls and that helps us stay on top of things. As VP of engineering, I'm a big believer in shift-left practices. I would like to make sure that my team takes full responsibility for quality assurance and security.

We did not have a previous solution for application security testing in this company.

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.

In terms of implementation services, we didn't go to any third party. Veracode was pretty good. They were very responsive and answered questions. We were able to get the help we needed.

If Veracode thinks that it's best to bring in an integrator for the first 30 days, they should build that into the cost of the contract. I don't think I would have blinked if they had told me, "We suggest paying a little bit extra for the first year because we want you to purchase a professional services contract from this company. They will work with you for a month and guarantee to get you up and running with best practices within 30 days."

I was impressed with the pricing we got from Veracode. I was able to make it work very well within our budget.

When I came to my current company, I looked at a few options for security testing, and then zeroed in Veracode as the best option for us and for what we needed to do. We didn't go through too many competitors. Because I had experience with it, I said we should use it. I felt that it was the right product for us.

One of the advantages of Veracode is that it is a one-stop shop for everything you need. I did not want to hunt around for five different solutions and have to put them together and have to use five different dashboards. I really wanted a single solution for all our needs, and that's what I got from Veracode: static, dynamic, and the manual pen testing.

My advice would depend on the size of your company and whether you have dedicated security engineers. For us, given the size of our company, Veracode has been very important. We needed a turnkey solution, and one that integrated directly into our product. We wanted something immediate. We couldn't take the time to hire a bunch of security engineers and have them figure it out and then do an RFP. That was not us.

If you're in that position, where you need something that really meets all of your software security needs during the development life cycle, check out Veracode for sure. Look at a couple of their competitors. It's fine to kick the tires a bit and then what you can get from others, but I would definitely recommend that one-stop-shop type of thinking. You really want to get your solutions from one vendor, a partner that is strong in this area.

For the manual pen testing, there's a full day where they engage your product. It takes us about half a day of planning and putting it together, and then providing them with a live website. They then bring their team together and go through all the reports about what they saw and, typically, within a period of three days from the time of the manual pen test, we get results from them. Along with that, they also offer any kind of service you need to interpret or understand the results. You can also get some follow-on from them in terms of best practices and how to fix things.

In terms of false positives, I like my security scans to be a little more conservative, rather than being aggressive about eliminating things without me seeing them. I'm okay with the fact that, every once in a while, they flag something and bring it to our attention, and we see that it is really a non-issue. The reason that is my approach is that, when you do a static scan or a pure dynamic scan, these products don't completely understand your application environment. They cannot guess that this or that code is not used in this fashion. They can only flag something to bring it to your attention, and then you make the judgment call.

Veracode has flagged a few issues for us that we decided were non-issues. In their dashboard, you can actually provide a dispensation for each of those items. So we have gone in there and checked a box and put a comment saying, "Not applicable to our workflow." I was very happy that they caught those things. It gives us some confidence that they're looking deep into our product. We haven't had any major issues with false positives. What they flagged to us was reasonable, and we were able to decide that they were not really an issue for us.

Our confidence level is very high, thanks to Veracode's solution and our internal focus on shift-left methodology. I push my engineers to make security a part of the design, development, and testing processes. It can't be something that is done as an afterthought. We need shift-left thinking all the way to the left. You want to tackle an issue before it occurs.

Overall, Veracode has affected all our application security in a very strong, positive way, and I look forward to using their products and technology to continuously improve our security best practices.

I would give it a 10 out 10. It really is a strong solution for the industry. I'm looking forward to engaging Veracode in an even stronger way in 2022. I want to tightly align what we're doing, from a security best-practices perspective, even more with what they have to offer.

We use Veracode for static code analysis, dynamic code analysis, and software composition analysis. In our organization, we have a bunch of applications that are running on a monorepo or microservice level. We have to do SAST on those applications so that we have a code review done on a bit level. 

Going forward through the application pipeline, we do it on the dynamic level, as well, where we are scanning the public URLs of those applications to see what people can see externally. It's a type of out-to-in scanning in which we are analyzing the traffic that is sent out and even the traffic that is coming in, the response and request headers of the URLs, whenever someone is at a single URL. 

Finally, for the software composition, Veracode uses a third-party analysis tool in which it has the libraries and the functions that are being used at a source code level. They are open source or dependent files that are used for building that in-house application.

As a company, we have moved from using contractors and third-party consulting companies to creating our software through more of an in-house model. We are moving more into the DevOps realm with more of our own teams developing our software. Veracode fits that DevSecOps ideology. It is definitely helping us build more secure software than we previously had.

We have a bunch of applications into which we have integrated Veracode and we have seen that, in the final phase of production delivery, there are fewer vulnerabilities than we used to have.

And because Veracode has remediation and tracking within the platform, it becomes a good single pane of glass where the developers and the security professionals can operate and govern the flaws in the software. And they can take the necessary steps to remediate them.

In the metrics that we generate every month, we have seen the numbers go up with respect to remediation as well as the number of flaws that we catch. The word is spreading, and more and more application teams are using the static code analysis tool inside their pipelines. Overall, we are moving from reactive mode to proactive mode in remediating vulnerabilities through Veracode.

Veracode also helps our developers save time, in the big picture, compared to a situation without Veracode. Let's say there is an application on which no static analysis was done and the audit team says, "Hey, you don't have any static code analysis in your pipelines. You need to do something about that." They could scan the code that is already running in production and find flaws, but those flaws would take a lot more effort, time, and resources to mitigate compared to if they had been detected in a static analysis prior to the code going into production. In that way, it has definitely saved time. But if we are talking about short-term planning for sprints, it takes a little more time than usual because security is coming into the picture, as well. But overall, it helps save time.

Our security posture has gotten better since 2020. It takes time to do the integration of the platform and educate people about how to use Veracode, and then move on to remediating and validating things. But the journey that we had with Veracode has definitely helped us a lot, overall, with respect to bettering our security posture.

The static analysis is the most valuable aspect for us.

It also has the ability to block a build. In pipeline scanning, there is a configuration that can be set with respect to the security level of the flaw. If there is a high or a critical issue, there's a way the build can be failed and blocked before going into production. But the best case that I have found for blocking builds is in the staging area. You don't really want any blocking done on the production environment because there are business SLAs that the enterprise has to fulfill. The best case would be blocking the builds in the staging phase, the pre-production environment, so that everything is taken care of before it is pushed to production.

There are three integration points for Veracode. One is the IDE plugin. Whenever a developer is writing code on their IDE platform plugin for Veracode—whether IntelliJ or Visual Studio, et cetera—it tells them if that piece of code has any vulnerabilities and if there is a better way to write the code.

The next point is the pipeline integration in which, whenever a build is getting pushed from a standalone branch to the main branch, a scan is done on that commit to see if there are any vulnerabilities.

Finally, when the build is published with the whole module, it can do another scan, as well. These three scans have their own pros and cons. The policy scan, which is a build scan, does the scanning on an overall basis with regard to the different standards out there, like OS and Spin5. It scans the first-party and third-party code, which is the most holistic scan that there can be. But the point is that it scans at three different integration points or stages, so it helps developers to remediate their vulnerabilities before they have moved far in the pipeline. Shift-left is definitely possible through Veracode.

Veracode's false positive rate is a little toward the higher side. We understand that Veracode doesn't have the business context. I advocate that people look at their code, even though there is a vulnerability, to see exactly what it is. For example, a randomize function is being used to create an ID that is not being hashed. Veracode marks it as a false positive because it doesn't know if the ID is being used for cookie generation or some random ID in the log generator. We, as dev or sec people, have to go in there and analyze what the ID is being used for. But the false positive rate is definitely a little bit on the higher side.

The effect of the false positive rate on developers' confidence in the solution depends on the maturity level of that particular application team with respect to learning Veracode. In the initial stages, obviously, when developers see that, whenever they're writing code or pushing a build, there are a bunch of vulnerabilities, it may affect their confidence. But a couple of months or a couple of quarters down the line, when those same developers have already used Veracode and have raised their maturity level from one to at least three, it doesn't really affect them because they know that they have to go in there and check the vulnerabilities for themselves to determine if it's a false positive or a real vulnerability.

It has definitely taken a little more time to validate the false positives, but I would say there are a lot of true positives, as well, which have been remediated and which have been mitigated for the betterment of the security posture. But it has definitely taken a little more time to mark or validate those positives. Hence, I definitely advocate that people shift a little more to the left. They should do ID and pipeline scanning before they hit policy scanning because, with ID and pipeline scanning, you scan small chunks of code. You remediate that code faster, before it goes to the whole package and there's a bunch that you have to deal with.

Also, container security is slowly becoming a prevalent part of the development realm. Veracode's SAST, DAST, and SCA are pretty good with respect to industry standards, but with regard to container security, they are in either beta or alpha testing. They need to get that particular feature up and running so that they take care of the container security part.

In addition, there is a new concept out there, the IAST, which is interactive assessment security testing. It is a little more proactive than SAST. So if Veracode can combine that feature with their current technology, they would definitely be a front-runner again for the next five to six years.

I've been using Veracode for the last three and a half years.

Once or twice a month there is maintenance on the Veracode side because they're updating some signature in their database or something else. I have seen maintenance coming up, but it's not an issue because the pipelines and integrations that we are running keep on running in the background. It's just the GUI that we are not able to access at that particular time.

It's pretty scalable if our enterprise has the licenses for scaling the applications. I haven't faced any issues with regard to scalability, apart from licensing, of course.

We have contacted Veracode's tech support a bunch of times. The only downside is the time needed to schedule a consultation call with the pro services team, keeping in mind that enterprises need to buy pro services licenses before they can use it.

When someone is scheduling a meeting with them, the issue type should be as precise as possible. In that way, they can rope in the exact SME for that particular topic, because in the development realm there are so many languages and so many types of issues out there. There are different personnel for each of those categories. So the more precise the details are for the meeting, the better the SME will be for that particular consultation.

Positive

We have only used Veracode, right from the start.

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.

They have made it worth the price with the kind of discount and the kinds of modifications they made for us with regard to licensing. Previously, it was per profile. But they have adjusted according to our requirements because we are a big company and we handle a lot of applications. There's a tiered discount that they have provided us, so the cost is justified.

If someone looking at Veracode is concerned about the price, it depends on their requirements. I wouldn't really recommend Veracode for a small firm, because it might be a little pricey for them. But for a large organization, with more than 1,000 applications in the enterprise, there are tiered levels of pricing. Obviously, there are other cutting-edge solutions that have become available recently, but Veracode is something that a big organization should look at.

When it comes to managing risks, we use the remediation feature that Veracode has. Whenever there is a flaw, we do have tickets open up for it and the application owner or the developer goes through the vulnerabilities. There are times when the vulnerability is a false positive and you can mark it as such within the Veracode platform itself. And we, as security professionals, do the validation for whether the business justification is good or not. And we either have a source code review for the vulnerability or have an exception open up for the remediation step that the application or the owner is asking for. We do risks via the platform, as well as through the ticketing tool that we use.

We are also using SBOM (Software Bill of Materials) for inventing all the different kinds of modules and libraries that we are using for an application. Using the SBOM feature, you would have to leverage the API to get the inventory from the API calls that Veracode has. But in our organization, we use the GUI report generation more than the SBOM report because there is an executive summary in the GUI report with regard to first-party and third-party flaws. It also has the mitigation steps. SBOM would only give you the list of softwares, libraries, and versions that are being used. It is not as detailed as the GUI report that Veracode provides.

Things to consider when looking at Veracode include the different integration points where you want to integrate Veracode, how big your organization is, and how many applications you want to do security analysis on. If it's a big organization, Veracode is obviously a solution to evaluate, but for a small organization, below 500 apps, it might be a little pricey. Also, you will need a couple of Veracode champions on your team who know it inside out. You will need training provided by Veracode, so make sure that is included during the procurement stage. That will help you implement the tool within your organization faster and much more efficiently.

I would have given Veracode a nine out of 10 a couple of years back, but given the tools that are coming out on the market, and the scope of development, which is increasing, I would place it at eight.

We use it for security validation. As a company, we need to make sure that our code is secure. Not only do we need and want to do this for ourselves, but we also need to do it because of our security obligations to our clients.

It has been helping us capture security vulnerabilities that we would not catch otherwise.

When it comes to our ability to fix flaws, Veracode has given us more visibility into certain flaws that could show up, flaws that can be subtle and not seen in the code. For example, though it was not obvious, there was a case where a developer naively added the authentication into the code, which we're not supposed to do, obviously. It was not seen by our review process, and Veracode caught it and we were able to eliminate it.

It has also helped us to save time. The example, and where I see the most benefits of that, is in the Security Labs, where I have the developers training and constantly improving their security, and remembering their security techniques. That way, they are more proactive and make sure things are correct. They're faster because they're doing it in the first place.

Overall, in terms of our security posture, Veracode has made us more reliable. We're finding those flaws and our clients trust us more because of it.

And when considering whether it has reduced the cost of development, security, and operations for us, the short answer is no. But the long answer is yes. It clearly has added more procedures in place, which we needed to have, and that has definitely increased the cost of development. But in the long-term, how much have we saved from the intangible of a flaw not being exposed?

The Security Labs feature, in particular, is valuable, and I have been using the static code analysis as well.

I do have two pet peeves with the platform.

1. The user interface is slow as a dog; really slow. You go to any modern interface and it's a lot more snappy. Even though I understand a lot of what they're doing and why it might be slow, it is really slow. You click on something and it takes two to three seconds. That doesn't sound long, but it just feels super clunky.
2. There are many times when their product goes to check my code and it dies, and I don't know why. I've contacted support and they're not really helpful with this particular problem. I go to the logs and I look at what I can but I can't tell why the check process has essentially just died in the middle of checking.

Other than those two complaints, I still find it very strong and powerful.

In terms of additional features, the big one I would like to see is that, right now, I have to click through too many things to get to the triage report, which is the main thing I want to see for anything. I have to click through this one screen that doesn't give me any information and I really just want to get to the mitigation review screen quickly. Anything that would save me going through clicks and four or five different screens, because the interface is slow, would be fantastic. I want to get to that mitigation screen because the summary screens are not all that interesting to me. I need to know, "Is this mitigated? Is it not?" and get it checked off and reviewed.

I've been using Veracode for two years.

It has been a very stable product. I don't think the issues that we're having are related to its stability.

The scalability is "medium" because one of the things I've been having to do now is scale out more of the microservices by tier so that I can verify that the code is correct per tier. For me to scale up like that seems to be taking a lot of effort. I might be doing something wrong. Maybe it could be solved in a different way. But the scalability is average. On a scale of one to 10, I would put it at about five.

We do have plans to use more of Veracode. We are expanding into the SCA, where it is scanning the containers, and we've also just contracted with Veracode to do penetration testing.

The one time I had to use their technical support for the bug where a code check dies, I found them a little off-putting. They have never really fully answered the question. I got tired of asking because they didn't understand what I was saying.

During installation, their support was fantastic, a 10 out of 10. But in dealing with this one issue, I would give them a two.

Neutral

We haven't used another solution. Veracode is the first solution of this kind that we have worked with.

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.

I did the original Amazon CodePipeline implementation by myself and got it hooked up. As we went to more complex things, with Jenkins, that was done through an integrator DevOps team. On our side, it was just me involved.

I'm sure we have seen ROI, but I do not have a direct metric on it. There are a lot of intangibles in that. For example, what would be the cost of a particular flaw that we caught with Veracode, if it had gone live?

When I looked at the pricing, it was definitely a value. In terms of the service and what it's checking, the cost was very reasonable, particularly because we could have multiple code bases as part of a project.

Make sure that you're comparing apples to apples if you're concerned about the price of Veracode versus what you're reviewing. Some of the stuff that Veracode does and applies is not the same for other services. When I really compared apples to apples, I found Veracode to be rightly priced.

There were no costs in addition to the standard licensing fees, although we just signed up for a couple of other products.

We looked at other solutions but one of the big things that made a huge difference with Veracode had to do with pricing. Because we're moving more and more toward a microservices architecture, and we have about six code bases that make up our entire product, they made it clear that as long as something was a part of our product, it was the same price. That was amazing to us because competitors charged per code base. It was definitely a more economical solution and the one that made more sense, and is more in line, with our product. That really simplified the thought process for us and was a huge competitive advantage.

Veracode is a valuable tool to have in the toolbox to prevent vulnerable code from going into production. Veracode's false positive rate has been very good. It's reasonable. False positives take more time, but I have not noticed that time to be a significant burden. Its policy reporting for ensuring compliance with industry standards and regulations is adequate. 

In terms of having visibility into application status at every phase of deployment, Veracode doesn't provide that. It doesn't control the whole deployment cycle, so there's no way it can report on all of it.

The platform's interfaces look slightly antiquated but don't let that stop you from using it, because it has been a good solution for us.

The biggest lesson I have learned using it is that it's really nice to have these security checks in a single place in your code pipeline. We have multiple security companies at this point, but having the code review and product review security in one place helps us know that that part is "containerized." Having everything dealing with code review in one place is nice.

We use both the static and the dynamic scanning. What we do is run the code through the scanner once we make any modifications. And periodically, we also run the dynamic to connect several applications. We use Veracode to check for specific vulnerabilities such as cross-site scripting. When we are checking for those vulnerabilities, we take a portion of code that is going to be generated and we run the scanner.

We work a lot with open sources. Using the Static Analysis, the Dynamic Analysis, and the scan module, we can control everything we do via Veracode. Moreover, because all our applications are security applications, keeping a high security standard is really important.

The visibility into application status across all testing types in a single dashboard is helpful because, even if you are running different types of scans, you have everything in one place. You have a unique dashboard to control all the applications, and that is good.

Overall, we've never had any problem with vulnerable code going into production. It's quite a solid tool. We have a really good feeling with this solution.

The most valuable feature is actually the support provided by Veracode. Once you start to use the platform, you can mount the IDE plugin for your script. The advantage is that you can run the scan and check what the problem is and you can fix it yourself. Support could be used to address something that could go beyond your skills. If you use Veracode Greenlight, you have a small pop-up that you can use to interact directly with the team and you can ask a consultant to advise how an issue can be fixed. One of the good things about the Greenlight plugin is that it is very simple. There are several guides that tell you how to install it. It's a matter of one or two minutes and you are ready to go.

Once you check something, they provide links, not manually, it's all automated. When you want to check into a vulnerability you click and open the website where there is a description. If this is not enough of an answer, you can ask directly by scheduling an appointment with a Veracode guy.

Another feature of Veracode is that they provide e-learning, but the e-learning is not basic, rather it is quite advanced. They don't teach you how to develop in Java, Python, PHP or C#, but they instruct you about the best practices that should be adopted for secure code developing and how to prevent improper management of some component of the code that could lead to a vulnerability. The e-learning that Veracode provides is an extremely good tool. And as far as I know, there are no other competitors that offer it.

The best stuff is the training: this enables your team to adopt the same programming approach, although these people have a different background or joined the projects in a different phase. Doing that, they can take the training and be aligned so that they all write code in a good way.

We also use the Static Analysis Pipeline Scan and it's quite good. They provide several of the most common templates for pipelines. You see the process, while you program, right up until you package an application, and that the platform is able to detect things that are a blocking point. Before deploying to the production, you already know what is doing. And the speed of the Pipeline Scan is quite good.

Another good feature is the policy reporting for ensuring compliance with industry standards and regulations. We test compliance for medical devices, for GDPR, and for payment methods. These are all good. If you are not correctly prepared on one of these sets of regulations, you know that Veracode is going to take care of it using pre-prepared templates. But we can also customize our own policy if we are facing a unique use case. Even if it's not really common, we can take a regulation and build it the way we want it to look.

In addition, you can check everything from the dashboard. Veracode provides a web portal that is connected with your account and through that you can check the status of all the deployments that were run. And suppose you also have an application that is quite complex. You can deploy and upload it through the portal. When it is ready, you receive a notification from the portal that the job has been done and that you can check the results. When you go to the dashboard, you have the OWASP vulnerabilities. There is a really simple graphic with the colors showing how many vulnerabilities have been found and how much these vulnerabilities are repeated in your code. It also tells you the potential effect, if it is a backdoor data breach, for example, etc. It also suggests what you can do to remediate. It might suggest modifying code or changing the status of some part of the development, or updating a third-party.

And if you have people on different projects, there is also a role management feature, so you can select, for example, that people who are working on a given project can only see that project. If you are running something with different levels of classifications, for example, if you have an external consultant, it does not affect the confidentiality of the system. When people are collaborating, not all people are at the same level of an NDA. It is good that each person can see only their part implementing Need-To-Know.

It also integrates with developer tools. We use IntelliJ and Eclipse, among others.

They should invest in mobile security.

I have been using Veracode since 2017.

We have never faced a problem or any downtime.

We haven't perceived any issue when it comes to scalability. But it's true that if you have more tenants, the response of the scanners is going to get released quicker.

I would rate Veracode's technical support at nine out of 10. They would probably deserve a 10 but it is not as quick as it should be. They need to increase the support workforce. The support people are well-prepared, but it can sometimes take one or two days to get the right guy to do support.

The previous solution that we were working with was mainly focused on the quality of the coding. We are happy with Veracode because it's focused on security.

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.

The Veracode team is replying fast and the proved a strong expertise in every challenge.

We could save some money having an on-premise solution, but the fact that this is a SaaS means we can be sure that it's updated. It's outsourced. In terms of cost, I don't see a big advantage, but in terms of operations there is because we don't have to take care of it. We know that if, somewhere else in the world, somebody detects a vulnerability, a few minutes later we will already have a patch. This is extremely important for us. Nobody in our company has to touch anything to get this.

If we had to designate one or two people to take care of maintenance of an application, at some moment one of them might not be updating things. With Veracode, we know that we don't have to worry. We just have to focus on our development. We don't consider maintenance at all because it's all managed.

The pricing is quite standard. It's not cheaper, it's not more expensive.

We looked at other vendors but we selected Veracode because it had a top rating in industry reviews. For us, that was like a warranty.

We were skeptical about running scans with a cloud-based solution, but then we saw the benefits. Everything is up to date without us having to lift a finger. We know we don't have to take care of maintenance. 

Also, if you work in the domain of medical devices, payment methods, or other things that are related to privacy, Veracode provides all these modules. This is a big advantage.

Sometimes the scans are not done quickly, but the solutions that it provides are really good. The quality is high, but the analysis is not done extremely quickly.

False positives are not a main problem. The platform does try to overprotect but, of course, a system like this can only understand the syntax and not the semantics. So it's overprotective when there is a doubt. Sometimes, we ignore some of the advice received.

We use it primarily for our application security concerns. We use the dynamic, static, and SCA scanning tools. We run our static scans after the code is compiled, and that gets uploaded automatically through our DevOps tool. We have installed an agent in one of our cloud servers that is behind a firewall to run the dynamic scan against the runtime. We run our SCA scans when we do the static scans, which is after compilation.

Prior to using Veracode, we hadn't really looked into security features or thought about security in the same way that we have since we started using Veracode. We were focused on what you hear about in the news, such as making sure that it is HTTPS secured. We hadn't really dug into the nitty gritty of application security and scanning our source code, running it against a runtime environment, and looking at the actual third-party solutions that we integrate or use in our code. Veracode has helped with our mindset as an organization to start thinking about things more securely by design rather than as a reactive measure. We're being more proactive with security.

Veracode's integration with our continuous integration solution is what I've found to be the most valuable feature. It is easy to connect the two and to run scans in an automated way without needing as much manual intervention.

We feel very confident about Veracode's ability to prevent vulnerable code from going into production. Having the stamp of approval helps not only from a marketability standpoint but also from an overall good feeling within the organization that we're doing our part to help keep our code free from vulnerabilities.

This solution provides visibility into application status at every phase of development. It goes from compiling the code all the way to running it in production. It covers all major aspects of the SDLC. We run static scans and SCA scans early on in the process to make sure that we catch any code that is insecure by design. If we are able to catch it earlier on, before it's actually out in the production environment, it reduces costs. The dynamic scans are run further along in our QA process. That is, once we've deployed the code and have it in a runtime environment, we run weekly scans in a dynamic environment against the code runtime to make sure that there aren't any new vulnerabilities that got introduced. We are looking at doing manual penetration testing in 2023, where we would be using a spinoff of the code that was released to the customers to make sure that there aren't any holes through which a nefarious actor could get in and exploit what was built.

Veracode's false-positive rate is low. The few instances when it looked like there were false positives, the issues were found to be either true vulnerabilities or things that were that way by design. If a developer thought that there would be a ton of false positives when using the tool, it would then diminish the value of actually using the tool. Veracode touts itself as being a tool with the lowest false-positive rate in the market. It gives inherent confidence in the tool itself, and developers are more inclined to think that if it found something, it's pretty likely that it is not a false positive. They would then work to prove it wrong rather than discounting it without even looking into it.

We haven't really found many false positives with static analysis, and there hasn't been a significant impact on our time and cost related to tuning, leveraging data, and machine learning.

Continuous integration linking definitely saves a lot of time because it takes away the step where a developer needs to manually upload the code every time to do a scan. It can run in the background, and having the Visual Studio plugin includes it directly in the development environment. If developers do get assigned a bug that they need to fix, they can pull it right up in their development environment and not have to log in to the portal. It will all be right there.

I'm primarily the one who has been involved in DevSecOps, and Veracode has definitely reduced my time. If we had gone with a conglomeration of open-source tools, it would've taken me a ton more time. Whereas with Veracode, all the documentation is out there, and I'm able to integrate everything that I need from a usability standpoint. I don't have to learn a new tool every time I need to integrate a new security scanning option. It has helped me tremendously and has saved me a lot of time.

I do expect large applications with millions of lines of code to take a while, but it would be nice if there was a possibility to be able to have a baseline initial scan. I know that Veracode touts that there are Pipeline Scans that are supposed to take 90 seconds or less, and we've tried to do that ourselves with our ERP application. However, it actually times out after two hours of scanning.

If the static scan itself or another option to run a lower tier scan can be integrated earlier on into our SDLC, it would be great. Right now, it takes so long that we usually leave it till a bit later in the cycle, whereas if it ran faster, we could push it to the time when a developer will be checking in code. That would make us feel a lot more confident that we'd be able to catch things almost instantaneously.

I've been using Veracode for a little over a year now.

I haven't had any stability issues, bugs, or glitches.

The scalability is really good. I recently added to the solution some new applications that I learned about late in the game. There were probably 10 that I had to add in rapid succession and scan as well. It was very quick and painless.

Veracode's technical support is very responsive, and I've heard back within 24 hours regarding a couple of issues I've entered. We have actual consulting calls, which are a scheduled event, and I like the way they handle those as well. I have nothing but good things to say about them and give them a rating of ten out of ten.

Positive

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.

We implemented it with the help of a third-party vendor. They had two people on their team who were working on the deployment along with me. My responsibilities included adding all of our software to the tool to run scans against it, integrating it with our DevOps solution, discussing the tool itself with internal stakeholders as to how they can use it and showing programmers how to use the tool from an internal adoption standpoint.

I know that Veracode is a semi-pricey solution. If you are serious about security, I would recommend that you use an open-source option to learn how the scanning process works and then look into Veracode if you want to really step up your game and have an all-in-one solution.

We evaluated a couple of open-source tools such as Snyk and SonarQube against Veracode with the help of a third-party vendor. We didn't use any of those and landed on Veracode because of the Veracode Verified seal. This, along with Veracode being the market leader, gave Veracode an edge over the others.

The main difference between Veracode and the solutions we evaluated is that Veracode is an all-in-one solution. Though an open-source solution would've been more cost-effective, we would've had to use a bunch of different tools. It would have required more knowledge to do the integration piece and would've taken a lot more time and effort. There would have been invisible costs associated with it just by the virtue of time. In comparison, Veracode's dynamic scan, static scan, and software composition analysis are all in one place.

My advice would be to look at the open source tools out there and see how far along you are in your security journey and what your needs are. If you're looking for the best in the market, Veracode is a great option, as far as paid solutions go, because it's a one-stop shop. If you have more time at your disposal and you don't mind integrating some solutions, then I'd recommend an open-source tool. However, if you have the resources, I would definitely recommend going for Veracode.

On a scale from one to ten, I would rate Veracode at nine.

We utilize it to scan our in-house developed software, as a part of the CI/CD life cycle. Our primary use case is providing reporting from Veracode to our developers. We are still early on in the process of integrating Veracode into our life cycle, so we haven't consumed all features available to us yet. But we are betting on utilizing the API integration functionality in the long-term. That will allow us to automate the areas that security is responsible for, including invoking the scanning and providing the output to our developers so that they can correct any findings.

Right now, it hasn't affected our AppSec process, but our 2022 strategy is to implement multiple components of Veracode into our CI/CD life cycle, along with the DAST component. The goal is to bridge that with automation to provide something closer to real-time feedback to the developers and our DevOps engineering team. We are also looking for it to save us productivity time across the board, including security.

It's a SaaS solution.

Our needs are primarily foundational and Veracode provides the efficiencies that we need.

The product is being used to replace another solution and we recognize in our early implementation that Veracode DAST is identifying more vulnerabilities in application code than our previous solution did.

Also, at this juncture, I have received no feedback of false positives from our development team. It seems to be fairly good in that regard and probably has minimal false positives. We haven't gotten feedback one way or another from developers about how the false positive rate affects their confidence in the solution, but if there were significant false positives, or even one in our environment, we would certainly be engaged with the vendor to discuss it. But that has not been the case so far.

Overall, I think that if it's implemented correctly for the business, Veracode is highly effective in preventing vulnerable code from going into production.

The visibility into application status helps reduce risk exposure for our software. Today, any findings provided by the DAST are reviewed by the developers and we have internal processes in place to correct those findings before there can be a release. So it absolutely does prevent us from releasing weak code.

Because we're so early in our implementation, we have had minimal feedback in terms of room for improvement. We have seen some minor things within the interface itself that we would love to see some improvements on.

One of those is scheduling, which can be a little difficult. For instance, if you set up recurring scheduled scans and a developer comes in and says, "Hey, I have this critical release that happened outside of our normal release patterns and they want you to scan it," we actually have to change our schedule configuration and that means we lose the recurring scheduling settings we had. We have to change that over to a one-time scan. It would be lovely if we could run ad hoc scans without changing our recurring schedule. That can be a little painful because it happens a lot, unfortunately. I think that will change, so I don't want to knock them completely. Right now, we run a manual configuration setup, but once we integrate this via API into our CI/CD life cycle, that issue should go away.

We have been using Veracode for four months.

So far, my impression of Veracode's stability is very good.

It appears to be very efficient when it comes to scalability. We're a smaller shop, so I may have a different interpretation of what scalability is. We're under 100 licenses at this point, but so far we have had success.

There are some great, positive things about Veracode and the relationship they try to form with the clients.

Regarding tech support, I've mostly had positive engagements, especially because they have one engineer who is, frankly, a rock star. I cross my fingers that I get him every single time because he's very thorough, he's educational, and he is quick. For the most part, it has been positive, especially when I do get assigned that particular engineer. I had a little frustration in the early days because they didn't quite understand the situation, but that was the only time I had a negative engagement with Veracode on support.

Positive

Our previous solution was difficult to configure. Setting up the login process was very difficult, as it was tied to your browser and there were a lot of hoops you had to jump through. The reporting was also hard to follow sometimes and didn't provide a good view into previous findings versus new findings. That made things difficult too. Once we did the evaluation of our old solution against Veracode, it was very clear that it was finding fewer vulnerabilities, which lowered our confidence level in that tool.

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.

Veracode has not reduced the cost of AppSec in our organization yet, but that's only because we are very early in the implementation.

We primarily looked at Netsparker as an alternative. 

My advice would be to understand how you want Veracode to function within your environment from a workflow perspective. That way, you can potentially start taking advantage of a lot of the functionality it offers out of the gate, which is something we are not doing yet. We're on a delay until 2022. That is really important. 

Also, in introducing the product to those who will be receiving the output, the findings reports, it would be great to include them in some conversation and collaboration on the move down that Veracode path or, frankly, any path that leads to scanning applications.

Veracode provides guidance for fixing vulnerabilities, although we haven't actually had to utilize that. But as a part of our licensing model, they provide us a certain number of opportunities to engage with someone for consultation.

We are not focusing on using the solution to enhance developer security training right now, although it is a part of our roadmap. We are banking on being able to utilize that aspect of Veracode because we are an Agile environment and we want developers to be able to engage that training. Also, when there are findings, we want our developers to get that assistance in real-time. That is a part of our 2022 strategy. 

We have started out with a much more narrow policy for ourselves because we are just learning about how the tool works and how it functions. But we did evaluate some of Veracode's policies, out of curiosity, and they seem to be very aligned and very helpful. However, I would not be able to speak to whether they are on the money for utilization against compliance frameworks.

In our company, we have various projects, and before beginning the development process, we utilize Veracode to scan the repository for any potential security issues. For instance, if we are using a third-party API or client dependency, such as a payment system, we require a third-party dependency. Once we have implemented this feature and scanned it using Veracode, any security vulnerabilities or code issues are highlighted. It is imperative that we resolve any Veracode issues to ensure our build is successful. To solve these issues, we may need to upgrade the version of our dependencies or investigate any security issues with the versions we are currently using.

The code is checked for any security issues, as well as any potential code issues or code smells that could cause major critical blockers. In this context, blockers have the highest priority, and if any are identified, they must be addressed urgently. The bugs or code smells are analyzed, and priority or severity is assigned accordingly. Dependencies used in the code are also checked for security issues.

Veracode's ability to prevent vulnerable code from being deployed into production is crucial. Typically, if a dependency we use has security issues or concerns, Veracode suggests upgrading to a more secure version. For example, if we're using a PayPal dependency with version 1.3 and it has a security bug, Veracode suggests upgrading to version 1.4 which fixes the issue. We usually make our project compatible with version 1.4, but sometimes Veracode recommends removing the dependent code altogether and adding the updated dependency from another repository. Veracode provides suggestions for resolving security issues and we implement them in our code after resolving any conflicts. We run the Veracode scan again and if it fails, we do not deploy the code to production. This is critical as it ensures that security issues such as bugs and fixes are addressed.

Veracode consistently assists us in identifying security issues in third-party dependencies, while also ensuring the maintenance of code quality. Preventing security bugs and threats in our code improves the overall code quality of our company, which is essential given the significant concerns surrounding security today.

Veracode's policy reporting is helpful for ensuring compliance with industry standards and regulations. Veracode's solution plays a major role in achieving compliance, including HIPAA compliance. Without Veracode scans, identifying security threats and third-party dependencies would be a tedious task for DevOps professionals.

Veracode provides visibility into the status of our application during every phase of development, including continuous integration and continuous development CI/CD pipeline stages. This includes builds, package creation for deployment, and various enrollment stages such as develop, queue, stage, above, and production enrollment. Prior to each stage, a Veracode scan is run. This can be accessed through Jenkins or the CI/CD pipeline by clicking on the Veracode scan option, which provides a detailed report highlighting any security issues and concerns.

Veracode performs statistical analysis, dynamic analysis, software composition analysis, and manual penetration tests throughout our software development life cycle. Veracode scans not only for third-party security issues but also for possible issues in our own code. This occurs in every phase of development, including the SDLC. For example, if we use an encryption algorithm with a private or public key that is easy to decode, Veracode will identify this as an error or warning in the report and suggest using multiple layers of encryption for the keys.

The entire CI/CD process is part of DevOps. Therefore, the responsibility of configuring the Veracode tool usually falls on the DevOps professional. It is essential to integrate Veracode with the CI/CD pipeline within the project to ensure it is always incorporated. Whenever there is a priority or mandatory check required before deployment, Veracode should run beforehand. This integration is carried out by our DevSecOps team.

Veracode's false positive rate is good, as it helps us identify possible security concerns in our code. In my opinion, it is advisable to run a Veracode scan on all codes. I have worked in the IT industry for five years, and I have observed that Veracode has been implemented in every project I have worked on. If a tool is improving our code quality and providing us with insights into potential security issues, it is always beneficial to use it.

The false positive rate boosts our developers' confidence in Veracode when addressing vulnerabilities. Veracode also provides suggestions when there is a security issue with a dependency in version 1.7, prompting us to consider using version 1.8, which does not have security issues. This process involves the developers, and it leaves a positive impression on our managers and clients, demonstrating our commitment to security. We can show them that we were previously using version 1.7 but updated to version 1.8 after identifying the security issue with Veracode's help. Unfortunately, there is no centralized platform to check for network issues or problems with dependencies and versions. Veracode provides a centralized solution where we can scan our project and receive results.

Veracode has helped our organization address flaws in our software and automation processes. Its positive impact has been reflected in our ROI, which increased when we started using Veracode. Without Veracode, we would be susceptible to security issues and potential hacking. However, after implementing Veracode scans, we have not encountered any such problems. It is critical for us to use Veracode because we capture sensitive data such as pharmacy information for real-time users, including patient prescriptions and refill schedules. This sensitive data could pose a significant problem if our code or software has security vulnerabilities. Fortunately, Veracode scans allow us to prevent such issues.

Veracode has helped our developers save time by providing a solution that eliminates the need to manually check for dependencies or search the internet for information on which dependencies have issues. Instead, Veracode provides a detailed report that identifies the issues and recommends the appropriate version to use. Using Veracode ensures the quality of our code and also saves time for our developers. In my career of five years, Veracode has helped me resolve code issues eight times.

Veracode has reduced our SecOps costs by identifying security vulnerabilities in our code. Without Veracode, if we were to go live with these issues, it could result in a breach of our encrypted data, potentially causing significant harm to our organization. This would require significant time and cost to resolve the issue and restore the data. Veracode has improved the quality of our code and reduced the risk of such incidents occurring, thereby minimizing their impact on our organization.

The most valuable feature is detecting security vulnerabilities in the project. This is especially important when choosing third-party dependencies since we may not be aware of any potential security concerns or issues in the code. Veracode can help identify security issues in third-party dependencies, including code fixes and bugs. By focusing on our own security issues, we can also address potential security issues in third-party dependencies. Before going into production, we typically conduct a record scan in each department to ensure security measures are in place. 

The scanning process for records could be faster and there is room for improvement in Veracode's performance. Currently, it takes around 25 to 30 minutes to scan a standard repository, even for a small one. This is not ideal, especially since we are using a microservice architecture with eight repositories. If each repository takes 25 minutes to scan, it would take a significant amount of time to scan all of them. Therefore, I would like to see some performance improvements in Veracode to reduce the time it takes to scan our code and generate detailed reports.

I have been using the solution for two years.

The solution is stable.

Veracode is scalable but the performance can be slow when running scans so the larger we scale the slower it can be.

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 implementation was completed in-house.

We have seen a return on investment.

I give the solution a nine out of ten.

All coders should have Veracode since it helps prevent security issues in applications, thereby safeguarding critical data. As we know, all applications contain sensitive information. If we only store some of our data online, we have to rely on applications that meet industry standards and compliance requirements. Veracode can help achieve these standards and compliance. To ensure this, Veracode must be set up to scan and integrate with the Jenkins CI/CD pipeline.

We capture the health and pharmacy data of users, so Veracode is deployed in various countries and running live. We have over ten million users.