Veracode Reviews

Because Veracode is more interactive than Secure Code Warrior, the big benefit for our organization will be that the developers will not just get the blue team excited, but they will learn to think like the red team, like an attacker. The interactive labs will help developers see that some of the red team attack methods aren't that hard to do, and that will bring them more security awareness. 

Because developers will see exactly how you do a certain type of red team attack or exploit, they will understand that it's important that they don't think, "Oh, this could never happen." And when they realize that some of the attack methods are not so hard to implement, they will secure the code base and fix the vulnerabilities that already exist.

For example, when I tried SQL injection labs, I learned new ways to make those, and that is extremely valuable for me because. If I'm working with a code base, I can know exactly how to mitigate SQL injection, because not all systems are using Hibernate. I've been on code reviews where I could actually point out things related to injection, which is something I wouldn't have been able to do without Veracode.

Another big benefit for our organization is that it is more interactive and fun, in a way, than Secure Code Warrior. Developers will engage and spend more time in Veracode.

It has had a good effect on my security posture because the labs are very informative with current information, showing you some of the things that could be done by attackers if your code is done incorrectly. I have retained more useful information in a fast manner.

And if we talk about scanning, we will see advantages there as well. For example, I'm working on a Java project and because Java is a high-level language, it's hard to make code errors. But if I worked with C or C++, the scanner tool would be very good. If you take the OWASP dependency checker, for example, it goes through all the third-party dependencies which are often where the trouble is in a Java project. However, I have heard that you can upload the necessary files and it will go through the third-party components as well and, in that case, it's very beneficial for the organization to have such a tool.

It can be very hard to make a good lab environment with a console with log windows and code bases. What I like about Veracode is that they managed to do that. It has a very responsive graphical user interface and has worked very well. I was very pleased with that.

I like the web interface of the interactive labs and the information there. It's very well done by those who developed it, and it works very well. It's very fun and you get to learn new things and think like an attacker. It's not like on TryHackMe, but the information I got from doing the labs here was information that I didn't have before. The quality of the information was really good.

When I started to use Veracode, there were a lot of policy documents and I actually have a habit of always reading those. I haven't made a list of all the regulations and policies and how well it complies with all the security regulations, but from what I could see, it is aligned with security regulations and certifications. And in the lab environment, they have divided things into different topics like OWASP top-10. That is very actual and follows the security guidelines that are commonly accepted by organizations today.

I would like to see more AI features. It's a current subject because with ChatGPT and other solutions being developed all the time, IT attacks will increase. I actually talked to the CEO of an IT security company in the United States because he ranked the top-10 IT security risks this year, and one of the biggest risks was new vulnerabilities or attacks would occur because of ChatGPT and similar services. To defend against those it's very important that the good guys use AI in ways that are good instead of bad.

I have been using Veracode for about two weeks. I recently got access to Veracode to test it. I've been spending a lot of time on it, working with it in the lab environment. I have also tried out the scanning tools for code bases, but I mostly have experience working with it in the lab environment.

I haven't used it for very long, but I have never experienced any problems with the stability.

We are an enterprise-size company and I know that our security employees are using Veracode and some of the developers as well, but I don't know to what extent developers are using it. It's pretty widely used across our organization.

I give their technical support a very high grade. I was in contact with them with an inquiry I had, and there was a very fast response time. They took my request and prioritized it. They were nice as well, and that's how you want support to be, although not every support team is like that.

Positive

I was previously working with Secure Code Warrior which is very different, but it's within the security field.

I've been using the security platform TryHackMe a lot, which also has a web console, but I wouldn't pay for the kind of console window that TryHackMe had. It has a lot of good aspects, so no disrespect to them; I learned a lot from it. But I understand how hard it is to create that and Veracode has managed to do so in a responsive way that works well. It's very impressive.

Scanning tools are a big safeguard for getting vulnerable code out of production. It's almost mandatory today to scan applications because there are so many attacks happening in the world right now, no matter which solution you use.

I was very pleased when I tried Veracode because I hadn't heard about it before, but it was much better than I thought.

We're using Veracode Static Analysis for scanning security vulnerabilities.

Once the image is built in the container, we send it to Veracode Static Analysis for static analysis assessment, and the tool scans it. The tool then provides us with information on vulnerabilities in our code and the third parties, then provides recommendations on how to solve vulnerabilities, and that's helpful.

What I found most valuable in Veracode Static Analysis is that it categorizes security vulnerabilities. My company is mainly worried about security vulnerabilities, so it's beneficial that the tool identifies security-related vulnerabilities.

Veracode Static Analysis lacks penetration testing, so that's a concern. The tool is also unable to scan when it's a C or C++ model, so that's another area for improvement.

I've used Veracode Static Analysis for one and a half years, and I'm still using the tool.

I didn't find any stability issues with Veracode Static Analysis. It's a stable tool.

Veracode Static Analysis is a scalable solution. My company has between one hundred fifty to two hundred microservices, yet the tool can scan cost-efficiently without issues.

Veracode Static Analysis has good support. There's a channel where my team communicates with support, raises tickets, then support will give you a call, though there were a few times when support struggled on specific cases.

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

We deployed Veracode Static Analysis in-house.

We have not reached the point where we see ROI from Veracode Static Analysis because we're still assessing it, but there are so many vulnerabilities. If we fix some of the high-priority vulnerabilities not reported by the customer, and zero them out or reduce them, then we see value from the tool. Those high-priority vulnerabilities are less than manageable because they have multiple levels or layers.

To my knowledge, licensing for Veracode Static Analysis is paid yearly by my company.

We compared Veracode Static Analysis with other vendors, including SonarQube, and went with Veracode because it had more value than others.

Twenty-five to thirty people from the development and QA teams use Veracode Static Analysis, but my company is still learning the best way to reduce the load. There's no plan to increase the tool's usage for now.

Based on my initial analysis, I'd recommend Veracode Static Analysis to anyone looking into implementing it, as it's a good tool.

My rating for Veracode Static Analysis is eight out of ten.

For every application we develop, we want both static and dynamic security scans done before deploying them.

The solution helps us to verify if our code is error-prone or has any OWASP security flaws. It has also reduced our scanning time, but it's difficult to say by how much.

Also, the scanning process helps a lot when it comes to improving standards and best practices. If we scan multiple times and we get the same warnings again and again, it helps us to identify that there's something we need to rectify, overall, in our standards and processes.

In addition, the solution has helped to increase our security and development teams' productivity.

On the whole, Veracode has improved the quality of our code and the end product. It has reduced our security debt by 40 or 50 percent. It helps protect our application from external attacks.

It scans for the OWASP top-10 security flaws at the dynamic level and, at the static level, it scans for all the warnings so that developers can fix the code before we go to UAT or the next phase.

It also gives us a centralized view of issues and that is important because security is key to any application. We want to identify the flaws as early as possible. The centralized view means that everybody can see the report and remediate accordingly.

I would like to see improvement on the analytics side, and in integrations with different tools.

Also, the dynamic scanning takes time.

We have been using Veracode for more than six years.

It's a stable product.

We have about 30 to 40 developers using the solution. We use it on a weekly basis but I can't comment on whether we will increase our use of it. That depends on our product.

Technical support is average. They take some time to respond.

Neutral

We didn't use anything prior to this.

The ROI for us is that it improves our code quality and helps remove security flaws. It is an essential tool.

It does root analysis, but fixing things is up to us. Also, it doesn't require much maintenance.

I would highly recommend it.

We use it for static scans. It is mandatory in our company for every sort of project.

Veracode provides the organization an understanding of security bugs and security holes in our software, finding out if the software is production-ready. It is used as gate management, so we can have a fast understanding if the software is suitable for deployment and production.

My job is to help projects by getting the data integrated in Veracode. I don't own the code or develop code. In this area, I am a little bit like an integration specialist.

We use Azure and AWS, though AWS is relatively fresh as we are now just starting to define guidelines and how the architecture will look. Eventually, within a half year to a year, we would like to have deployments there. I am not sure if dynamic scanning is possible in AWS Cloud. If so, that would be just great.

The possibility to integrate Azure is very valuable because you can have every build integrated into the content integration pipeline. So, you can have every build scanned and determine when a new bug was introduced. Thus, you can keep great track of your code's security.

You can easily integrate it with Azure DevOps. This is an added value because we work with Azure DevOps. Veracode is natively supported and we don't have to work with APIs.

Third-party library scanning would be very useful to have. When I was researching this a year ago, there was not a third-party library scan available. This would be a nice feature to have because we are now running through some assessments and finding out which tool can do it since this information needs to be captured. Since Veracode is a security solution, this should be related.

I would recommend that they keep working on the integrations. For Azure DevOps, the integration is great. I am not sure what the integration possibilities are for the Google platform or AWS, but I would suggest every other platform should have this easy and great integration. It takes a lot of time for companies, so this feature is a big plus.

I have been using it for about three years.

There have been no issues at all. There has been no downtime registered.

I worked with the technical support to integrate some things. One of our private cloud providers only had old routers. It was possible only to open network connections to IP addresses, while Veracode only provided the URL in their guide. So, I asked the technical support if it was possible to provide some fixed URLs that we could give our provider since it is unfortunately against the concept of the cloud to provide the IP addresses that work just for some time. The technical support's response was within a day, and it was prompt and clear. Also, all their reasoning made sense so the support was very good. I would rate the technical support as 10 out of 10.

Positive

We also use SonarCloud, which is a code quality tool. We use both of them because both these platforms are good in some areas. While the Veracode is very good at finding security-related issues, the SonarQube Sonar suite is very good at determining code quality. Also, when I was looking into the topic, the SonarQube team answered that there is no point for them to go further into code security since there are already great competitors who have years of experience and development behind them, specifically mentioning Veracode as masters in their field. That is the reason why we use both solutions: We benefit from using them both. These solutions compliment each other.

I evaluated WhiteSource Bolt specifically for third-party library scanning, but I did not have a lot of time to create a proper PoC. I had a call with WhiteSource and told them that I would like to do a PoC, but I was not very satisfied with their support. It was like, "Just try the free solution then contact us again." However, the free solution didn't provide me enough things to make a decision. So, I just put it off until sometime possibly in the future. If Veracode offered third-party scanning, then we wouldn't need WhiteSource Bolt at all.

If you have Azure DevOps and would like to understand your code and how secure it is, then there are not a lot of better options. Also, there are not many choices in this area at the moment.

Once your code is scanned by the static scan of Veracode, you get some evaluation scores based on some criteria. For the management, when it is above a certain number, it is fine, but when it is built below, then it is no-go for production. Even though there is a possibility to create a sandbox environment for projects, they don't get it. That is understandable to me. I try to explain to them that there are no issues if you are working in a development environment and you get difficult scans. It is fine then because you can create a sandbox environment, which will not screw up or make the production releases worse because it is in a separate bucket.

We are happy using the solution. I would rate it as nine out of 10.

When code is being developed by our developers, the testing team runs through the static code application scanning and takes a look at how it is working out.

There are multiple code check-ins happening. When check-ins occur, we want to make sure that anything that needs to be tested, whether in that particular unit, or whether in the end-to-end functionality, is scanned and that the code is certified as usable. That's the first step we do, and it's a very important one. The scanning process helps our security team and developers fix flaws in the code and increases our fix rate.

Veracode SCA also reduces scan times because it scans incrementally. There is an initial baseline when the code is being created, but it does any additional delta check-ins fast and gets us the information.

We have been able to handle the overall code review process faster, because of Veracode's static code analysis. For example, we were able to onboard around 120 applications in seven to 10 months.

Another benefit is that it helps reduce security debt. It becomes much easier to run through the overall code. We have predominantly used it for shift-left, testing code much earlier from a security standpoint. Compared to when we started versus now, we have done a phenomenal job. Year on year, our security debt has been continuously decreasing by 10 to 12 percent.

Veracode takes the burden out of manual code reviews, helping to create secure software. The Greenlight feature helps the developer, at his desktop, before his code is even checked in. He gets a good understanding of how things look from a security standpoint, meaning how secure his code is. It will mitigate a lot of basic vulnerabilities at the start. And then, during the source code analysis, once it has been checked in, we have seen a 30 to 40 percent reduction in dynamic vulnerability identification because of the static code analysis that precedes it. Our vulnerabilities are at the dynamic standpoint. It's one of our most important requirements because we want to make sure that we provide a secure product and services. It's of paramount importance.

And as an educated guess, it has increased security and development teams' productivity by 7 to 9 percent, and that's a month-on-month increase.

The main feature we have been using is the software composition analysis, which provides us with a scoring system in terms of version 3 of the CVS. A lot of vulnerabilities are typically detected, but, at the end of the day, we also want to check how well they are being targeted, based on the Common Vulnerability Scoring system. Not every vulnerability is high-severity, because some of them do have fixes. That particular feature is helpful for us.

It gives you JSON output. When you do agent-based scans, at any point in time, there are multiple check-ins of the code. We have to look at it from the perspectives of how important it is to fix something and when it should be prioritized for fixing. The JSON output from the agent-based scans gives us the CVS core, and that makes things much easier. It's available on the new version of the Veracode SCA agent.

It also has a decent support system for audits. From that perspective, they did a very good job.

The mitigation recommendations are the standard ones, but if there are specific activities that come into the picture, Veracode should provide more remediation solutions. Since all of our team members are pretty good at what they do, they're able to do a good job with the information they get. But if somebody had to start off from the ground floor, they might need some help to understand things.

Veracode doesn't really help you so much when it comes to fixing things. It is able to find our vulnerabilities but the remediation activities it does provide are not a straight out-of-the-box kind of model. We need to work on remediation and not completely rely on Veracode.

Also, there are certain third-party libraries that might be called up by the code and that might have vulnerabilities. I haven't seen that Veracode is able to deal with that aspect. 

Another area for improvement is when the code's logic might have certain flaws that can result in a security vulnerability. Veracode doesn't handle that as well. Improvement in those areas would help us determine things much faster.

I've been using Veracode Software Composition Analysis for about five years.

It's pretty robust.

The scalability is very good. 

Our users are developers and security testers, predominantly. The number of people using it depends on the project. Sometimes we have 10 people on it and at other times we might have only five.

The teams that work on it take care of maintenance, so we do not need any additional team to do that. We also have a center of excellence that takes care of things.

The solution's technical support is good.

Positive

We did not have a previous solution.

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.

The cost has been an important aspect for us, but we have run with the additional cost of the overall code analysis. One of the major reasons is that developers get a better understanding of where their code stands before a security tester gets into the picture. The cost-benefit for us is that, rather than having to build up a whole security testing team, developers get security insights earlier in the development lifecycle. After that, we can introduce the testers to get things finished, and that reduces the manpower cost.

Compared to the typical software composition analysis solutions, Veracode is not so costly, although the static analysis part of it is a little costlier. It depends upon the ecosystem you are using, whether your application is a web application or a custom, non-web application. It can support all of them. The pricing depends where you are at with your overall security strategy.

If you have multiple applications and you want to scale it at an enterprise level, this is a good tool. But a very small shop might not want to go with it because there are a bunch of alternatives that work well. Again, it depends upon where you are at on your overall software AppSec journey.

In terms of security breaches, the static code analysis is what we use to try to ensure that an application is free of vulnerabilities. But when you deploy it in the environment, there are multiple aspects that might contribute to a breach. It could be either due to the infrastructure or another application or even through endpoint network solutions. So, we cannot completely rely on Veracode to prevent security breaches but it can reduce them.

Veracode SCA reviews the code and allows us to provide overall information in terms of vulnerabilities. It does a pretty decent job. We are used to Veracode, having used it for a long time. Compared to when we started, all the developers are comparatively more confident and happy with it.

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.

At this moment in time, in my project, we are mostly using Static Analysis from Veracode. We automated it and added it as a step to our daily pipeline. We also tried using the pipeline plugin from Veracode that gives an immediate evaluation of your code. We're also using agent-based Software Composition Analysis. I have not exactly used it in my project, but I participated in investigating it and setting it up.

I know two flavors of doing Software Composition Analysis. The first one is a part of a daily static scan where you're uploading all your third-party libraries. The second one is by using agent-based, which gives more reporting capabilities but not doesn't affect policy scans, etc. We use both of them.

We use Software Composition Analysis as a part of our daily build pipeline, so we use Jenkins Plugin from Veracode. Every night, we upload our sources to the Veracode platform. In the morning, we receive results of Static Code Analysis and Software Composition Analysis. 

We are able to receive results for vulnerabilities in other libraries. We can then react to it and fix our code and those dependencies.

We do have a policy in regards to security. As a part of that policy, we cannot have very high-end issues. Usually, when you change third-party libraries, you need to do some level of regression testing. Our release cycle is long, and it could be half a year between releases or sometimes even more. By using Software Composition Analysis, we're checking our sources on a regular basis, and if needed, we change our libraries in our code, So, we are checking and mitigating any vulnerabilities if they are not applicable to our solution.

We use static scanning. This is the main use of Veracode for us. We package our application every day and send it to Veracode. We receive static code analysis results and also the software composition analysis results every day because the first focus for us is on quality improvement. The security improvement is definitely static scanning. We do have a process for analyzing and mitigating results around this static scanning. So far, we have been able to comply with our internal policy. At this moment in time, we are at the stage of releasing our product, and according to our internal policy, certain important issues from 2017 had to be addressed and fixed.

Veracode gives the possibility to find different vulnerabilities and flaws in code, and it also makes things relatively easy because everything is automated. Implementing such a high-quality tool like Veracode, immediately made us aware of a lot of issues, but the volume of issues that we had to address was really high. The support from top management made it easy to fix the issues that Veracode identified in the product that has a long history of more than 20 years. Without the support of higher management in organizing and defining a process of fixing those issues, it wouldn't have been possible to fix all those issues. We took the reports received from Veracode, planned our activities, reviewed everything, and started acting on it as a result. The new release that we have is according to our policy, which is an important thing for us.

It definitely helps in reducing the risk of a security breach, which is rather important for us for providing our customers with a secure product. Among our customers, there are a lot of big companies that take security seriously. So, for us, it is really important. The fact that we have executive sponsorship shows that security is very important for our management. This initiative started because we're treating security really seriously.

It is improving our productivity significantly. We just finished a big chunk of results processing, and we are still in the process of setting up our processes. When you're first doing that scan with Veracode, you receive a bunch of results and an overwhelming amount of flaws in your code. All those results need to be investigated. For some of them, it is sufficient to have mitigations, but some of them need to be fixed. We just finished those fixes, and there were a significant amount of security findings from Veracode.

Considering that in my project, we are mostly using Software Composition Analysis as a part of Static Code Analysis, for me, the main part is reporting and highlighting necessary vulnerabilities. Veracode platform has a rather good database of different vulnerabilities in different libraries and different sources. So, finding vulnerabilities in third-party libraries is the main feature of Software Composition Analysis that we use. It is the most important feature for us.

The results of agent-based software composition analysis are not connected to policy scanning. So, for me, the only thing that Veracode can improve in Software Composition Analysis is to connect it with the policy scan because, at present, it is a bit inconvenient for those in our organization who use agent-based Software Composition Analysis. In the end, they need to make a static scan with all those libraries in order to receive that report. If Veracode implemented a connection between agent-based static scan and static scanning itself, it would be great because it would lead to fewer operations in order to prepare release documentation and release reporting from Veracode. We recently had a conversation with Veracode about it.

I believe it has been about two years because Software Composition Analysis is a part of the policy scan, and our journey with Veracode has been for about two years.

It is stable. I didn't feel that many problems with it. We did have a few glitches with the platform, but they were not that many. So, I can say that it is stable.

I can't say anything about the scalability of this solution because we are not bothered about keeping its infrastructure up and running. We use Veracode Cloud, and we are not supporting or deploying it. It is just a service for us, and we consider it as a service. We submit the information and receive reports back from that solution.

In our project, every night, we are currently scanning our development branch and three versions of our releases. We have four applications, and I believe that from my team, at least 15 scans happen every night. We have a partnership with another company that provides a part of our functionality. They provide releases to us to embed in our solution. We also do the scanning for their part and inform them about the issues that we've found.

We will increase the number of scanned versions because with each and every release, during the support period, we're supporting versions of our product, and we're also fixing the security stuff. We will be increasing the volume of scans, but it will come to a logical point. When a version is no longer supported, we will definitely remove it from Veracode. So, all in all, at any moment in time, I foresee four or maybe five versions to support multiplied by four applications. There is also a development branch for each application, so there will be around 20-25 automated scans per night.

I am very pleased with the Veracode support because so far, there were no issues where they were not able to help us. Sometimes, in our questions to Veracode, we ask about the deep aspects of functionality, and so far, we've received answers for all those questions, and they were mostly good. I would rate them a nine out of 10 just because I didn't like some of their answers. Because of our approach of having each version as a separate sandbox in Veracode, we had questions about the consistency of results between different sandboxes, but then we realized that these are peculiarities of the platform. It is nothing serious or special. It was mostly related to our expectations from those algorithms, but it actually works perfectly. I can give a 10 for Veracode's support, but then they will have no growth to improve.

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.

I participated in the review of tools. We reviewed not only Veracode. There were also other candidates for our main tool for static scan and software composition analysis. So, I have been involved in all activities around Veracode from the very beginning. What I liked about Veracode is that it is not just one product. It is a big ecosystem. It even has integration with Visual Studio, etc. First of all, we took a look at the scope of scanning. We compared the results of scanning and the functionality. Veracode had really great reporting functionality. In the end, we came up with the conclusion that Veracode fits best to our needs, and I believe we were right.

My advice would be to adopt Veracode to serve your processes. I believe that the processes inside the company shouldn't be changed significantly with the introduction of new tools. Definitely, for each and every new tool, you need to build some process around usage in terms of administration and control. Veracode has a relatively big ecosystem of tools, which is a big advantage, and my advice would be to check all those tools and see how they can fit into your process, and how they can improve them. There are a lot of options and a lot of tools provided by Veracode that can fit each and every process. Whether you are using a waterfall process or DevOps practices in your organization, with Veracode, you can add necessary steps to your process without making significant changes in the processes that you have.

We take security seriously, and Veracode is not the only thing that we have for security. We do manual penetration testing to security test our applications. We also have some dynamic scanning. We follow some practices while engineering and architecting our solutions. At each and every step, we are trying to cover our solution with the necessary security testing activities or security design principles. Veracode is a big part of our security, but it is not the only one. We are fixing all issues, especially those that are non-compliant with our policy.

We don't use any connections with Software Composition Analysis. It is a separate product in the ecosystem that makes it possible for you to deeply scan your third-party libraries. This is the only way we use it. 

In terms of Veracode SCA reducing our overall scan times, I believe that it is not applicable at this point. In the case of agent-based scanning, the situation that we recently had has shown that you cannot fully substitute Software Composition Analysis from a static scan with agent-based. That's because, in the end, documents that you provide together with the release are the policy scan results generated by static scan. You can reduce the amount of time for your scanning, but in the end, you need at least one scan where you will figure out all third-party states as a part of the policy scan report. You cannot use only agent-based Software Composition Analysis because they are two separate sources of information. We can use Software Composition Analysis and then somehow merge results from two sources in one document for it, which is inconvenient. We are having nightly builds for Veracode, and it doesn't matter to us whether it takes more than 30 minutes or less than 30 minutes. We haven't measured the time, but with the approach that we have set in our company, we can leave it for longer time periods, and after nightly build, everything is okay for us. So, Jenkins just does its job of uploading, and no one monitors it. We are just monitoring that the jobs are stable and results are available. Considering that we're doing it at night, it is not that important for us for how long it runs.

It hasn't exactly increased our fix rate because it is not about our code. It is about the third-party code. We definitely have to mitigate, and sometimes, we have to change libraries to a newer version, so it somehow affects our fix rate, but mostly, the static scan affects our fix rate because it shows flaws in our code. So, I don't see any significant improvement with Veracode Software Composition Analysis in terms of our fix rate. I don't see a direct relationship between Veracode Software Composition Analysis and our fix rate, whereas Static Analysis works and gives us the necessary results and plans for fixing and doing our next steps in security.

It has not yet helped our company with certification and audits. We haven't yet shared those green results with our customers, and we didn't have any certifications the last time.

I would rate Veracode Software Composition Analysis a nine out of 10.

We use software composition analysis and static code analysis. We use a software composition analysis component to identify third-party vulnerabilities in our software. And then we use the static composition analysis to analyze flaws within our application on the front-end and the back-end.

We also use Veracode for static composition and software composition analysis and static code analysis because we need a way to identify vulnerabilities and flaws in the application and relay that information to our developers.

The manual penetration testing is not really used as much.

Having a centralized view is probably one of the most important aspects of the platform. We need to have some way of looking at all the flaws and all the vulnerabilities in one centralized view. 

Having this has improved our visibility into application status. It's very important because it's the way that we communicate flaws to our developers. And without it, we'd be missing out on an opportunity to explain what seems to be fixed and what needs to be managed.

Veracode helps us to reduce security debt. We're finding that issues like cross-site scripting injection, injection, and those sorts of vulnerabilities are getting addressed more quickly. And we don't really have to worry about where those are, whether that's being fixed or not because we can see them in the platform and we can see the score increase every time those get fixed.

The solution's ability to help create secure software is very valuable. We're a zero-trust networking company so we want to have the ability to say that we're practicing security seriously. Having something like Veracode allows us to have confidence when we're speaking to people about our product that we can back up what we're doing with a certification, with a reputable platform, and say, "This is what we're using to scan an application. Here's the number of vulnerabilities that are on an application. And here's the risk that we're accepting."

Using Veracode SCA helped increase productivity for our security and development teams. Every week we do a vulnerability report and we look at the flaws that were reported by Veracode. Our process essentially goes by meeting with developers, looking at the report, finding out which flaws are the most important ones to fix first. After we've done that, we set up a sprint and we have developers work out two to three of those tickets until they're complete. We've done that now for about six months. We increased our application score from a pretty low level all the way up to Veracode Level Three, so above 90. We don't have any high severity or high vulnerabilities and we don't have any mediums and applications anymore. Following that process is extremely helpful. We also utilize the Veracode dashboards as well. We use the Veracode dashboard to monitor our progress in triaging flaws. Then we want to make sure that things are actually getting fixed. And then we can count those metrics by looking at those dashboards.

It has definitely improved our security posture and communication with developers. I think that now developers are taking our security seriously, whereas before it was something that was always important, but there was no real way of actually tracking what was getting done. Now that we have the tool that we can use to track what's getting done, we're making objectives and setting goals, and working towards this.

We use the screening process to help our security professionals and developers fix flaws in the code. It's probably the most utilized security tool that we have at our company.

Scanning with Veracode SCA reduces scan times by a few seconds. It also helps to increase our fixed-rate by 14%.

The scanning process helps to significantly improve our standards and best practices.

The mitigation recommendations provided by the scanning engine of Veracode are important for developers to understand. They need to know how to fix things. So just giving them a blank vulnerability and saying, "this is the issue," doesn't really help. They need something that tells them how to fix the flaw and where to fix the flaw.

Veracode helped us with certification and audit. We're working towards Veracode Level Four right now, we've achieved Veracode Level Three status, and we're looking forward to reaching the next certification level. The goal of that is to eventually have all of our third-party vulnerabilities and mitigate them so that we're in good standing and we don't have anything coming from a third-party library that could possibly compromise our application. Once we get to that fourth certification Veracode Level Four, that would be great.

The JIRA integration automation aspect of it could be improved significantly. We want to have a way to create tickets that are going to allow people to work through those flaws that we're finding. We don't want people to feel like they're missing out on something or that they're not following directions in the right way. And we have a process in place where there's a set of tickets and people can work on them. It just seems that people are more focused. They tend to pay attention to what they're doing and there's accountability. So having a more rigorous JIRA integration would be very helpful.

I have been using Veracode for over a year. 

It's a very stable product, and I think that the team at Veracode is constantly putting in more effort into trying to make it into a better platform. They take feedback seriously. They constantly improve the platform. They are working towards adding features that developers are requesting. So it's always changing, there's always something new being added to it, which is very good.

Large enterprises are probably following a very different practice from what we're following. I think that smaller organizations are going to have an easier time using something like Veracode because of the flexibility of the different API tools that they have available. An enterprise might have a more complicated time scaling it. The issue with that is that the enterprise is probably going to use a proxy and having to deal with the networking issues, it's going to become very difficult for that to scale. However, in a small company, those situations are mitigated pretty easily by getting two or three people together. So we move through those very fast, we're extremely agile. We're always forward moving. We're always rapidly developing. I think each company has its own specific way of handling scalability, it's always been easy just because we're a very collaborative team. We know how to work with each other and we're always receptive to each other's feedback. I can't really speak for other companies, but I can tell you that we find it pretty scalable. That's really just our culture though.

I run all of the administration and I direct people in what needs to be done. So, that's about it. In total, about seven people are really using it.

We are using it to its fullest extent. Even the manual penetration testing aspect of the platform is very useful. The manual penetration testing aspect of the platform is something that would be nice to incorporate because the cost is significantly less than other security companies. For example, InfoSec is about $3,000 more than Veracode, for any organization that wants an all-encompassing security platform. But what we get with Veracode is a platform that provides software composition analysis, static code analysis, Docker Container Scanning, manual penetration testing results, and dashboards that show the progress for moving through all of those issues. And that's probably the most important aspect of the platform.

Once they introduced the prebuilt dashboards that really reduced the amount of friction with upper management. Typically, my mentor said that almost all issues in any business organization come down to personal relationships and opinions, so when Veracode introduced those dashboards, it removed the ability for people to give opinions about what was being done and what wasn't being done.

We're driven by facts as people, so we can look at those metrics and say, "This is what's actually getting done." And there's no ambiguity. Then really that just removes all opinion from any sort of conversation.

They monitor all of the conversations in the platform on the Veracode community. My rep is very responsive. He answers community questions. He votes up really important questions and the issues are getting answered quickly. That's the most important part because then the business, if we run into an issue on Monday and we spend two or three days trying to debug the issue, we haven't figured it out. You can go to a place and actually get an answer. Whereas some organizations try to use a tool that's custom made and they're going to run into an issue where it's intractable. It can't be solved. However, with Veracode, customer support has always been able to find some sort of solution. Anytime I've ever had a problem, it's always been resolved 100%. There's never been a time where it's gone unresolved. I can't say that about every tool.

Positive

We used a combination of things. We use Sonar, Veracode, and JFrog Artifactory just give us a diverse picture of what vulnerabilities are in the application and how we can fix them. Veracode seems to always provide the best feedback. Other platforms really aren't at the same level, they provide reports and those reports are usually very static and they're not very informative. Whereas with Veracode, the platform is very interactive. You can tell that it was designed for users and Sonar is the same way. Sonar is very static. Even in Bitbucket, you can now scan your code with Snyk.

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.

We have absolutely seen ROI. We have buy-in from upper management and developers. We have a lot of people who are very excited about what we're doing and we're working towards that.

We've personally seen a major decrease in vulnerabilities and we've seen an increase in awareness for security. So people actually have conversations about security now, and they're taking it seriously. It's no longer an issue that gets swept under the rug. I think a lot of smaller organizations would benefit from having a tool that showed them what is being done, as opposed to someone just saying this is what we're doing if they can see the results that really improve. So, once we added that, we saw a decrease in vulnerabilities, we decreased our third-party vulnerabilities from a pretty significant level and attended the three down to single digits, which is huge for any organization.

The thing that I'll go back to is when one of my mentors said to me "Evan, security is a critical aspect of any organization. People don't always believe in it. And the best way to sell it is to explain what could go wrong." So when we compare what could go wrong, having a third-party vulnerability, like a graph library, such as the one that Equifax used, which led to a $3 million lawsuit, and their reputation was destroyed. When you compare that to paying $8,000 for an application, it's a no-brainer. Once the reputation of an organization has been tarnished, that's it. The whole thing is completely over. Really everyone loses faith and once people lose trust, it's almost impossible to get people to believe in a vision.

It's definitely worth it considering what could go wrong. The DevOps Mantra is to always be prepared for what could go wrong. Most things are going to go wrong.

Having a static cost gives people confidence. And once people start using it, if the price changes, then that's going to be dependent on how much they're getting out of it.

I definitely looked at other security platforms, but Veracode seems to have the most performance.

With Xray, essentially you upload your builds, once you've uploaded your build, you index it. And after you index it, it'll give you a security report. Now, the thing with that is you have to make a policy, you get a report, the report comes out as a PDF and the PDF doesn't really tell you how to fix it. It tells you the fixed version.

The first path of that really was just creating a pipeline that ran a curl request over to Artifactory to generate that PDF. And then on Monday mornings, that was automated. So management can go in, look at that PDF and say, "Oh, okay, these are the things that are happening in our application." Whereas Veracode, is fully automated, it runs the full scan and then creates the tickets. So that's the contrast. 

My advice would be to start with meeting with people from Veracode. Once you meet with the team from Veracode, the best way to handle that is to start asking questions and identifying the things that would be of value so that an organization doesn't start out by paying too much money. Then you're moving away from that being too scared of what the outcome is. I think once they go in and they have a meeting with people and they can actually discuss what they want to do, that's the first step towards planning out how the platform will be used.

I would rate it a ten out of ten.