What needs improvement with Veracode?

Veracode Greenlight scans the code while the developer writes it. It will be beneficial for developers if Veracode Greenlight includes Python.

Veracode should include the feature to run multiple scales at a time.

An area for improvement in Veracode is the time that it takes to scan large projects, as that makes it difficult to fit into our CI/CD pipelines. One of our app scans times out after two hours, which requires uploading and scanning that particular application manually. Still, there's no visibility into the CI system with the vulnerabilities found. My company cannot incorporate that into the automatic cycle and has to scan manually, so Veracode could improve on that.

They could improve how they fix vulnerabilities. They could have more support in place to help the developers. That would help a lot of users. The pricing can be improved. It is really, really expensive.

The reporting was detailed, but there were some things that were missing. It showed us on which line an error was found, but it could have been more detailed. Also, with upgrades, we had quite a difficult time tracking the reports, so there was some maintenance around that.

Veracode is costly, and there is potential for improvement in its pricing. In our region of the world, it is challenging to attract a significant number of sign-ups due to its unaffordability.

Veracode's ability to prevent vulnerable code from going into production is commendable. However, we have encountered numerous cases of false positives that need improvement. The technical support service has room for improvement. There are times when we rely on them, but we are not receiving an adequate response. The stability has room for improvement.

From what we have seen of Veracode's SCA offering, it is just average. The SBOM is adequate, but it's essentially the same as what everyone else is doing. In terms of SCA, they are about average compared to other systems. Therefore, I would like to see some improvements. SAST, DAST, and SCA in a single pane of glass would be a good upgrade to Veracode. We are a Jira and Confluence shop and I would like to have a really good integration with those tools. We have a ticketing system that not too many companies have ever heard of. In fact, I had never heard of it before coming here. Instead of using a well-known industry standard like ServiceNow, we use a ticketing system called Cherwell, which also has an open API. Having an API for the ticketing system would be really beneficial. I would prefer if Veracode offered more options for licensing, such as a pipeline or project license instead of a user license. Currently, I have around seven hundred users, but I manage fewer projects. Therefore, I believe it would be more beneficial and efficient for me if Veracode could adopt a project-based pricing model. In reality, I have multiple teams working on various projects simultaneously. Pricing based on the number of projects I have up and running would be more suitable for my needs compared to the number of developers working on a particular project. One thing that I would like to be able to do is to receive a daily summary of the emails I currently receive. With numerous ongoing projects, constant scanning occurs, resulting in a high volume of emails about what is being processed. I believe it would be helpful if Veracode could create a daily summary of these emails. This way, I can easily track the number of actual emails I receive without having to go through each one individually. As of now, I already have 65 emails from Veracode, specifically regarding the processes that ran today.

Sometimes Veracode gives us results about small glitches in the necessary packages. For example, we recently found issues with Veracode's native libraries for .NET 6 that were fixed in the next versions of those libraries. But sometimes you do not know which version of the library particular components are using. The downside of that is that one day, the solution found some issues in that library for the necessary package we spent. Another day, it found the same issues with another library. It will clearly state that this is the same stuff you've already analyzed. This creates some additional work, but it isn't significant. However, sometimes you see the same issue for two or three days in a row. In our project, we use a lot of limited packages that link to another library, and there may be issues in those reference libraries. For example, one library might be referenced by several Google packages. When it shows you a vulnerability in one library, you will not see the issues in all libraries. We've discussed the issue with the Veracode team, and they investigate a way to fix this. Hopefully, it will not be an issue.

The false positive rate is a gray area. The number of false positives could be reduced a lot. For each good result, we are getting somewhere around 15 to 20 false positives. We expect false positives, but if that ratio could be reduced to a single-digit number for the false positives, that would be much more helpful. We are spending some manual effort and time on this because it happens sometimes, when we first scan code, that it says there is no threat. And the second time we scan it, it says there is a threat. Those kinds of positive responses make us do double work. If that was better, it would greatly improve our overall efficiency. Apart from the false positives, I would like to see more plugins and integrations to make Veracode much more user-friendly for developers and users. Any IDE plugins would make our work faster.

Veracode's policy reporting, which ensures compliance with industry standards and regulations, is valuable. It would also be helpful to have a specific example that we can relate to in order to better understand it. Currently, the information is scattered, so precision would greatly assist us. Veracode can be improved in terms of software composition analysis and related vulnerabilities. For instance, when an application team provides us with their software code, we perform code scanning. During this process, we often encounter software composition analysis vulnerabilities that require the application team to upgrade their Java file from version X to version Y. We then communicate this to the application team, and they proceed with the upgrade. Once the upgrade is complete, we conduct a rescan. However, during the rescan, Veracode may identify compatibility issues with the upgraded version Y. This situation puts the application team in a difficult position, as they may be unable to accommodate this change within their project schedule. Therefore, this is an area where I believe Veracode could make improvements. The technical consultation can be enhanced to effectively address the communication variations among different regions.

Veracode does not support scans for .NET Blazor server applications. We encounter errors whenever attempting a scan. I would appreciate it if Veracode could incorporate support for these applications. I would like Veracode to offer code support for the latest releases of .NET whenever they are released by Microsoft.

In the last month or so, I had a problem with the APIs when doing some implementations. The Veracode support team could be more specific and give me more examples. They shouldn't just copy the URL for a doc and send it to me. I am a distributor and a Veracode solutions expert, so if I create a ticket that means I have read the documentation. It would be better if they sent me more examples instead.

The language version support could be improved. For instance, I recall a situation where there was a slight delay in supporting the application for a specific job because there were concerns regarding the vulnerabilities present in the new languages. Veracode combines container scanning and software composition analysis into a single package. This has always been an issue because people want the freedom to choose one or the other. However, we are almost compelled to purchase both components together. I would like to request the inclusion of incremental scanning in a future release. By scanning only the portions of code where changes were made instead of the entire code, we can significantly reduce the scanning time. I would like to see what Veracode plans to do regarding endpoint protection, PAN testing, DAST, RAST, and similar areas. I haven't seen any developments in these aspects yet. Products like Contrast are more advanced in this regard. So, as teams become more mature, what steps can we take to adopt the mindset and processes required for such advancements?

Scanning progress is highly dependent on the speed of the Internet. This can create confusion about the completion of scanning tasks. For example, a static scan may detect all vulnerabilities during a single scan, but when static scanning is disabled, some vulnerabilities may be detected during one scan, but not during the next scan or a subsequent scan. This inconsistency can make it difficult to track vulnerabilities. Additionally, The solution does not make it easy to mitigate vulnerabilities that are not detected by static scanning. The price of the solution has room for improvement.

Veracode has the capability to identify flaws in the code. I would like Veracode to also have the ability to fix these flaws in a future release.

I'm also a cybersecurity expert. In addition to vulnerabilities, I am looking at this from a holistic cybersecurity perspective. Bringing Veracode in line with the latest vulnerabilities would add value. We see APT issues often, and some processes could be left vulnerable if our tool cannot cope with them. It would improve Veracode to bring it up to date with current threats that the cybersecurity industry highlights. I would also like Veracode to offer training and certifications that users can do on their own time. It would encourage people to build skills that they could reuse across the board. Many other software publishers offer this. It helps build a user base and generate interest. Training is an excellent way to market your product. It would also be helpful to build a user community online to create a knowledge base of expert users who can answer questions and advise Veracode on ways to improve the product.

When we engaged Veracode to conduct the manual penetration testing, they were extremely slow in completing the task and delivering the report, causing a delay of two to three weeks for us. The duration of the manual penetration testing process needs to be improved. The cost of the solution can be reduced.

The backend support team of Veracode requires improvement as they are difficult to reach when we encounter issues. The UI is not user-friendly and can be improved. The speed of our internet connection affects the scanning process, which may take a considerable amount of time to finish. As a result, this can lead to challenges in planning and reporting, causing confusion.

Static scanning takes a long time, so you need to patiently wait for the scan to achieve. I also think the software could be more accurate. It isn't 100 percent, so you shouldn't completely rely on Veracode. You need to manually verify its findings.

Scanning large amounts of code can be a time-consuming process and there is scope for improvement.

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.

In the next release, I would like a proper way of packaging files for scanning and the packing of IOS apps and API Dynamic scan methodology. Also, there seem to be lots of false positives. This can be improved upon.

Veracode could improve their documentation. They don't update the knowledge base when they release a new feature or module. The information in the knowledge base often doesn't match how the latest version works. Veracode should update the knowledge base to tell you how to use and configure the latest modules. The user interface could also be optimized for smaller screen sizes. It displays well on a screen that is around 14 to 15 inches. It isn't a mobile-friendly tool. The usability and user interface need to be improved. It has limitations on some browsers, as well. I find it easier to use Veracode in Chrome than in other browsers like Microsoft Edge. It should work perfectly in any browser.

Sometimes we get a lot of false positives even after configuring our policies, so that could be improved. There is an issue where the UI occasionally breaks in between uses of the application, which can be improved. The UI could also be more catchy for the benefit of the less technical users. It would be good if the configuration of dynamic scanning could be less complex.

There is a sandbox limit of 10 so any company using Veracode needs to plan for only having those 10 sandboxes. If they increased that to 25 or 30, the scan time would decrease and the results should be more effective. There is also a size limit of 100 MB so we cannot upload files that are larger than that. That could be improved. Also, the duration of the scan is a bit too long.

I do have two pet peeves with the platform. * 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. * 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.

There should be more control for administrative users so that we can add and delete any functionality or module within the platform. We should not have to reach out to Veracode's customer support every time. We should be able to customize our modules. Also, the analytics reporting should be improved. It should provide bar graphs and full visualizations so that people who are not as technical can understand things.

Searching for applications in Veracode is a little bit difficult. We have to minimize the length of an application's name to 47 characters. It would be good if this limit could be increased so that an application's name can be properly reflected in 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.

We are testing Veracode's software composition analysis, but we're having trouble integrating it with SVN. It works out of the box when you use Git but doesn't work as well with other tools like SVN. It's more geared toward Git.

Technically there is nothing wrong with Veracode. The only issue that we have is uploading the code, the process of actually uploading and getting our results back. All of that is a little cumbersome. One of the things that we have from a reporting point of view, is that we would love to see a graphical report. If you look through a report for something that has come back from Veracode, it takes a whole lot of time to just go through all the pages of the code to figure out exactly what it says. We know certain areas don’t have the greatest security features but those are usually minor and we don’t want to see those types of notifications. So we would like to see a kind of a graphical representation of the problem areas. I would like to know which file is the biggest source of issues for me so that I can focus on resolving the issue, as a project manager. With how it is now, I am able to do this but I have to take out the whole PDF file and extract it. It takes up a lot of my time. I would like to see better strategic reporting. It would be great to get better graphical reporting.

This is not a very elaborate application. I think that the suggestions are between thirty-five and eighty percent accurate, with most cases being about seventy-five percent. Some of them are references where you have to go and determine whether they are direct threats, or not. At the point in time when we were using this solution, we had older coders and the way Veracode tests for vulnerabilities may have been affected by the code style. I found that there were far too many warnings and some false positives. Of course, this comes with every product, and there are multiple tools that are used. Ideally, I would like better reporting that gives me a more concise and accurate description of what my pain points are, and how to get to them.

This solution does a good job, but it is limited to only a few technologies. I would like to see expanded coverage for supporting more platforms, frameworks, and languages. Specifically, I would like to see support for mobile frameworks like Xaramin and React JS, as well as extended support for iOS applications.

* More timely support for newer languages and framework versions. * Integration with Slack is another request from our developers.

* Management of false positives * Agile best practices: Violation detection. * Support for more programming languages, like SQL. * Support for more frameworks for Java: .NET, Python, PHP, C, and C++.

From a technical standpoint, I'm pretty happy with everything. The one thing I'd like to be able to do is schedule dynamic scans. Today we're kicking those off manually, but I believe that it's something have on their roadmap. Other than that, I don't really get too involved in the cost sides of things that's in my job, I'm more of a technical focus, but I have heard from my manager and a couple other people that the solution is quite expensive. So that is possibly one factor that could turn somebody away from Veracode. But, like I said, I really don't know much more about that. Technically, I'm very impressed and happy with what they've had to offer.

The UI could be better. Also, there are some scenarios where there is no security flaw, but the report indicates that there is a security flaw. The report is not perfectly accurate. So, the accuracy of the scanning reports needs improvement. It currently takes too much time to scan all the vulnerabilities in the applications and code. The time should be reduced. The scanning engine in Veracode needs some improvement in terms of performance and efficiency.

I think the biggest room for improvement is around known or accepted vulnerabilities that, when we re-scan, we want those things to be recognized as already accepted, as an exception. Sometimes they show up as something new and we have to go back and re-accept that as an accepted exception in order to bring our numbers back into compliance. I think if they could improve the operations around accepted vulnerabilities, we would see improvements in our productivity. I would also like to see more executive reporting. Having a good snapshot of how well we're tracking, where each of the teams that own the applications, how they're doing, and where their gaps are would be good. Currently, the reporting is geared towards tracking current vulnerabilities. Even though they have trending, the trending doesn't necessarily evaluate the teams and how well they're doing. I would also like to be more oriented towards teams. Overall, I would give Veracode a nine out of 10.

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've seen slightly better static analysis tools from other companies when it comes to speed and ease of use. Also, with the dynamic tool, sometimes a scan gets stuck and it can be hard to get a hold of the right person in a timely manner to find out why it got stuck and to get it unstuck, or to create a new one. Overall, speed and customer support could be improved.

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.

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.

The solution has issues with scanning. It tries to decode the binaries that we are trying to scan. It decodes the binaries and then scans for the code. It scans for vulnerabilities but the code doesn't. They really need two different ways of scanning; one for static analysis and one for dynamic analysis, and they shouldn't decode the binaries for doing the security scanning. It's a challenge for us and doesn't work too well. As an additional feature I'd like to see third party vulnerability scanning as well as any container image scanning, interactive application security testing and IAS testing. Those are some of the features that Veracode needs to improve. Aside from that, the API integration is very challenging to integrate with the different tools. I think Veracode can do better in those areas.

The reports on offer are too verbose. They might want to consider t restructuring their reports to better give a very good summary or overview in the first five or so pages and then go ahead and drill into the details of each and every vulnerability beyond that. The documentation could be improved. They could, for example, provide more details in terms of how to fix issues related to sign-ups. There isn't enough detailed information out there to assist users.

I would suggest charging the developer for training, as it's not very expensive. Only charge for developer training because it's a service you give now and they may need to be technical support. It costs them money to do that, but with the technology, an incremental user is negligible incremental costs, which doesn't really cost them. That's software economics. I would like to see them only charge for developer training for the qualified startups and start charging for the licensing once the product goes into production, and available.

I would like to see them provide more content in the developer training section. This field is really changing each day and there are flaws that are detected each day. Some sort of regular updates to the learning would help. I would also like to see more integration with other frameworks. There were some .NET Core versions that weren't supported back when we started, but now they're providing more support for it.

When it comes to the speed of the pipeline scan, one of the things we have found with Veracode is that it's very fast with Java-based applications but a bit slow with C/C++ based applications. So we have implemented the pipeline scan only for Java-based applications not for the C/C++ applications. For C++ based languages, or languages where there is a platform dependency—for example, if I write C language code it is dependent on whether I'm executing that on Windows, or on Linux, or another platform—and with some of these platforms-specific languages, Veracode makes something called debug symbols that are introduced into the code. That gets cumbersome. They could improve that or possibly automate. If Veracode could quickly analyze the code and make file-line flags, that would be great. It is easy to do for Java, Python, and Pearl, but not so easy for C++. So when it comes to the debug symbols, guidance or automation could be improved. Also, scan completion, as well scanning progress, is not reported accurately. Sometimes the scan says it will complete in two to three hours but it will take four or five hours. That is one of the areas where they can give a more accurate estimate.

They should invest in mobile security.

It is pretty efficient when creating secure software. For one or two particular applications, the dynamic code analysis can take too much time. Sometimes, it takes three days or more. That is where we find speed getting dragged. Apart from that, it is pretty efficient for us to get results and make our software secure. If the dynamic scan is improved, then the speed might go up. That is somehow not happening. We have raised this concern. It might also help if they could time limit scans to 24 hours instead of letting them go for three days. Then, whatever results could be shared, even if the scan is not complete, that would definitely help us. They could probably provide some plugins for the Visual Studio code.

The efficiency of Veracode is fine when it comes to creating secure software, but it tends to raise a lot of false positives. It will tell you about a lot of issues that might be hard for an attacker to actually manipulate. Because of that it's very difficult, sometimes, to sort through all of the findings and figure out what you actually ought to pay attention to. Maybe calling them false positives isn't entirely accurate. There were a lot of things that it would raise that were accurate, but we just didn't consider them terribly important to address because it would be very hard for an attacker to actually use them to do anything bad. I think it frustrated the engineers at times. Also, the policies you have, where you can tune the findings you get, don't allow you not to file tickets about certain findings. It will always report the findings, even if you know you're not that concerned about a library writing to a system log, for example. It will keep raising them, even though you may have a ticket about it. The integration will keep updating the ticket every time the scan runs. We couldn't make it stop. We tried tuning the policies. We had several meetings with the Veracode team to get their feedback on how we could tune the policies to quiet some of these things down and nothing ever resulted in that. Ultimately we couldn't stop some of these alerts from coming out. Even stranger, for some of the issues raised, such as the ones that were in the vendor code base, we would put the status in Veracode that we communicated this to the vendor, but then, the next time the scan was run, it would find the same issue. One time it would respect that update and the next time, afterwards, it wouldn't respect it and it would generate the issue again. It was really weird. It was reopening the issues, even though they should have been in a "closed" state. Another significant area for improvement is that their scanning had a lot of problems over this last year. One of the biggest problems was at first it wasn't able to read packaged Go. When I say packaged Go, I mean packaged the way the Go programming language says you're supposed to package Go to deploy the software, when you're using multiple build modules together to make an app. That's a totally normal thing to do, but Veracode was not able to dig into the packages and the sub-modules and scan all the code. It could only scan top-level code. Once they fixed that problem, which took them until August, we found that it kept reporting that there were no problems at all in our Go code base. That was even scarier because it would usually give all these false positives on our other repositories. I had the application security engineer write a bunch of known defects into some Go code and push it in there and scan it, and it didn't raise anything with any of that. They're advertising that they have a Go scanner, but it doesn't actually function. If our company was going to continue in business, I would have asked them for a refund on the license for the Go scanner at our next renewal, but since we're going out of business, I'm not renewing. I would also love to see them make it easier to debug the JIRA integration. Right now, all of the logs that are generated from the JIRA integration are only visible to the Veracode engineering team. If you need to debug this integration, you have to have a live meeting with them while they watch the debug messages. It's utterly ridiculous. Their employees are really nice, and I appreciate that they would go through this trouble with me, but I think it's terrible that we have to bother them to do that.

We tried to create an automatic scanning process for Veracode and integrate it into our billing process, but it was easier to adopt it to repositories based on GIT. Until now, our source control repository was Azure DevOps Server (Microsoft TFS) to managing our resources. This was not something that they supported. It took us some sessions together before we successfully implemented it.

When we go from the dynamic scan to static scan to SCA, there is a huge change in the UI. This was not relayed to us when we were buying the product nor during the demo. They mentioned, "Yeah, this was an acquisition. The third-party library scanner was an acquisition from SourceClear." You can see there is a huge difference in the user experience in terms of both the display as well as the usability of the product. That is one of our pet peeves: They are not normalizing the UI across the three product segments. We had numerous calls with them early on because we were new to the platform. The sales team is not aligned with the support team. The support team keeps telling us to use a different UI versus the one that the sales team showcased during the sales cycle. There is much to be desired of UI and user experience. The UI is very slow. With every click, it just takes a lot of time for the pages to load. We have seen this consistently since getting this solution. The UI and UX are very disjointed. It is ironic that they claim themselves as agile AppSec tool, but their UI doesn't reflect that. We had a couple of consulting calls, and perhaps it may be the engineers that we got, they were not really up to speed with our frameworks. They were very focused on .NET and Java, which are legacy frameworks for us. We don't use these at all in our code base. We are using the newer, modern web frameworks, like Django. They have very little coverage or knowledge base on these, especially on the mobile side. There are a lot of faults with the Static Analysis Pipeline Scan tool. Their tool seems to be very good with legacy products, which are developed in .NET and Java frameworks, but there are false positives when it comes to using modern web frameworks, like Python and Django. The C++ code doesn't even scan. We have spent at least three weeks worth of time going back and forth because it won't support the use cases that we have.

If Veracode was more diversified, as far as the number of platforms and the number of applications it could do in our favor, we would be using it even more. But there are a number of platforms it doesn't support. For example, I know they support C+, .NET, and Java, but there are certain platforms they don't support and that was disappointing. They have a pretty unique process to get guidance. It's not like you send them an email. You could do that, but if you want to set up a consultation call, you have to go to the website and give them a certain amount of detail so that they can study the problem and the detail and be ready to meet with you. It's not as simple as doing an email. You have to go to their website and you have to click on the "consultation" button and pick a time to talk with an engineer. Sometimes an engineer is not available for quite a while. You have to wait at least a couple of days before you can meet. Having to wait for two days is not that efficient. You should be able to set it up within 24 hours. And regarding announcements from Veracode, I've tried to get them to let my developers know directly, and I'm not sure if that's happening. I want to tell Veracode to make sure that happens. I don't want them to send an announcement to me and then I have to disseminate that information to my developers. I want it to go directly to them. They've got the developers' names and emails in their database so those announcements should go directly to them.

Whenever there is a mitigation that is submitted through the platform, I'm the one who approves it. The feature that allows me to read which mitigation answer was submitted, and to approve it, requires me to use do so in different screens. That makes it a little bit more complicated because I have to read and then I have to go back and make sure it falls under the same number ID number. That part is a little bit complicated from my perspective, because that's what I use the most.

It's pretty efficient, but sometimes the static analysis is prone to a lot of false positives. But that's how it is with most static analysis tools. In some cases, they might have other mechanisms which would deal with a particular vulnerability, but it wouldn't be captured in the code. I would estimate the false positive rate at about 20 percent. Upon review, the developers understand the solution. But when they get the initial list of findings, it can be a bit daunting to them if it's not managed appropriately. Also, the static analysis can sometimes take a little while. The time that it takes to do a scan should be improved. There are times when we need a quick turnaround but it will take a little while. We might have something scanning and not get a result until the following day. It's not too critical, but it does increase the delay. Most of the time, when developers submit their code, because of the way that we use it, it's because in their minds they're ready to have that code deployed into production. But the security testing, especially with the feedback, introduces additional time into the project, especially if a security fix is needed.

What could improve a lot is the user interface because it's quite dated. And in general, as we are heavy users of GitHub, the integration with the user interface of GitHub could be improved as well. There is also room for improvement in the reporting in conjunction with releases. Every time we release software to the outside world, we also need to provide an inventory of the libraries that we are using, with the current state of vulnerabilities, so that it is clear. And if we can't upgrade a library, we need to document a workaround and that we are not really touched by the vulnerability. For all of this reporting, the product could offer a little bit more in that direction. Otherwise, we just use information and we drop these reports manually. Another problem we have is that, while it is integrated with single sign-on—we are using Okta—the user interface is not great. That's especially true for a permanent link of a report of a page. If you access it, it goes to the normal login page that has nothing that says "Log in with single sign-on," unlike other software as a service that we use. It's quite bothersome because it means that we have to go to the Okta dashboard, find the Veracode link, and log in through it. Only at that point can we go to the permanent link of the page we wanted to access. Veracode has plenty of data. The problem is the information on the dashboards of Veracode, as the user interface is not great. It's not immediately usable. Most of the time, the best way to use it is to just create issues and put them in JIRA. It provides visibility into the SAST, DAST and SCA, but honestly, all the information then travels outside of the system and it goes to JIRA. In the end, we are an enterprise software company and we have some products that are not as modern as others. So we are used to user interfaces that are not great. But if I were a startup, and only had products with a good user interface, I wouldn't use Veracode because the UI is very dated. Also, we're not using the pipeline scan. We upload using the Java API agent and do a standard scan. We don't use the pipeline scan because it only has output on the user interface and it gets lost. When we do it as part of our CI process, all the results are only available in the log of the CI. In our case we are using Travis, and it requires someone to go there and check things in the build logs. That's an area where the product could improve, because if this information was surfaced, say, in the checks of the code we test on GitHub—as happens with other static analysis tools that we use on our code that check for syntax errors and mapping—in that case, it would be much more usable. As it is, it is not enough. The management of the false positives is better than in other tools, but still could improve in terms of usability, especially when working with multiple branches. Some of the issues that we had already marked as "To be ignored" because they were either false positives or just not applicable in our context come down, again, to the problem of the user interface. It should have been better thought out to make it easier for someone who is reviewing the list of the findings to mark the false positives easily. For example, there were some vulnerabilities mentioning parts of libraries that we weren't actually using, even if we were including them for different reasons, and in that case we just ignore those items. We have reported all of these things to product management because we have direct contact with Veracode, and hopefully they are going to be fixed. Obviously, these are things that will improve the usability of the product and are really needed. I'm totally happy to help them and support them in going in the right direction, meaning the right direction from my perspective.

We would like to see fewer false positives. Sometimes, I get feedback from a developer saying, "They are scanning a Python code, but getting feedback around Java code." While the remediation and guidelines are there, improvement is still required, e.g., you won't get the exact guidelines, but you can get some sort of a high-level insights. Veracode has a little bit of noise. Sometimes you will get a lot of issues, which you just need to triage. While the solution is excellent, it does come with a little bit of noise.

The triage indicator was kind of hard to find. It's a very small arrow and I had no idea it was there.

I think for us the biggest improvement would be to have an indicator when there's something wrong with a scan. For instance, we have CI scans that run automatically, and sometimes the files don't get upload and/or processed by Veracode. Now, there's a static scan that hasn't been completed, which blocks all future scans. The only way we know this is an issue is going into the Web UI, check each application, and look for stalled scans. This is time-consuming and frustrating.

We've had one occasion where a sub-product upgrade required action on our part faster than we initially understood it needed to happen. This ended up being relatively minor. One feature I would like would be more selectivity in email alerts. While I like getting these, I would like to be able to be more granular in which ones I receive. Separately, I find the results console somewhat confusing. When you are running multiple scan types for the same application, I've sometimes found it difficult to sort out where issues came from when I need that information.

Improve Mobile Application Dynamic Scanning DAST - .ipa and .apk. Right now I have to jailbreak an iPhone and Root an Android to intercept and fuzz requests with a Burp Suite Proxy. That is a very time-consuming process and there are lots of dependencies. It would be very helpful if we can upload and .ipa or .apk into a Veracode simulator, provide credentials and run a Dynamic scan accordingly. Fuzzing functionality on API resources, HTTP Methods, and Parameters would also be very useful in testing our Web and API Application Firewalls, response pages, and other WAAF actions.

It needs better controls to include/exclude specific sections when creating a report that can be shared externally with customers and prospects.

Veracode owns SourceClear. They bought them in 2017 or 2018, and they still are not fully integrated with the actual Veracode dashboards. Right now, you have to use two separate tools from the same company. One for the static analysis and dynamic analysis, then the second one for the third-party dependency. That is an area that they need to improve the service. Veracode needs to bring the second tool in already to the dashboard so that we don't have to use two separate logins. We don't want two different sets of jobs that we have to upload into two different places, etc. Veracode also needs better integration of their tools to each other. Veracode should make it easier to navigate between the solutions that they offer, i.e. between dynamic, static, and the source code analysis. The SDA feature is on the website. Veracode should integrate SourceClear with the company product line finally after two years. I would love to see that. Veracode did not previously support Python 3. They just released the support for Python 3. Keeping updates coming quicker would be the main thing that I would love to see, i.e. to have all these solutions better integrated.

We would like to see improvement in reporting, in particular, end dates on mitigations.

We would like a way to mark entire modules as "safe." The lack of this feature hasn't stopped us previously, it just makes our task more tedious at times. That kind of feature would save us time.

I attended a meeting of one of the security organizations I am associated with. At the meeting were security professionals from several major retail companies. The topic of discussion happened to be application development security. When the question was asked concerning what tools are being used, many of these major retail companies said they are using Veracode. However, they were quick to comment that the product is too expensive and that there are too many false positives which take too much time to remediate.

Veracode should provide support to more software languages, like ABAP.

They should improve on the static scanning time.

They are already working on, but we are looking forward to seeing it. We would like the consolidation of all the different modules. This would help, so then we would be able to see analytics and results on one screen, like a single pane of glass. Once your report has been generated, you need to review the report with consultation team, especially if it is too detailed on the development side or regarding the language. Then, you need some professional help from their end to help you understand whatever has been identified. Scheduling consultation takes a longer time. So, if you are running multiple reports at the same time, then you need to schedule a multiple consultation times with one of their developers. There are few developers on their end who work can work with your developers, and their schedules are very tight. Therefore, you have the report ready if you want a consultation, then it sometimes takes more than three to four days to arrange a meeting. I feel to wait four days to get a consultation and understand the report around the whatever has been identified is a bottleneck.

The solution currently does not support Dynamic Application Security Testing which is an important facet of application security testing. In addition, the current version of the application does not support testing for API.

Some important languages are not supported.

Raw file scans and dynamic scans would be an improvement, instead of dealing with code binaries.

I would like to see more technical support for some of the connectors, some more detailed diagrams or run-books on how to install some of the stuff; more hand-holding in the sense of understanding our environment. They cover a lot of languages already and it doesn't make sense for them to cover legacy languages but I know there is a need for covering legacy languages. My biggest need, the kind of feature I would want, is more on the technical support side.

Speed. When we scan binary, when we perform binary analysis, it could go faster. That has a lot to do with the essence of scanning binary code, it takes a little bit longer. Certain aspects, depending on what type of code it is, take a little long, especially legacy code. In our case, we have quite a bit of older code. It takes some time to get through.

More integration into the specific application; an open API would be good. Aside from that, I think they do a really good job in terms of the features they have.

As we move to more of a mobile space, much of the code was developed on desktops, mobile laptops, and things. Mobile apps run differently and they have a different runtime. Chris Wysopal and I have talked several times over the past few years about how to address that. I'm not sure that there is a good answer yet, because it is so complex. But I'm pretty sure with Chris' track record that they are going to come up with a very good way to do that in the near future.

The only areas that I'm concerned with are some of the newer code libraries, things that we're starting to see people dabble with. They move quickly enough to get them into the Analysis Engine, so I wouldn't even say it is a complaint. It is probably the only thing I worry about: Occasionally hitting something that is built in some other obscure development model, where we either can't scan it or can't scan it very well. I would also like to see some improvement in the speed. That is really the only complaint, but in all reality we have a massive Java application that needs to be scanned. Our developers are saying, "It takes 72 hours to scan it." That is probably the nature of the beast, and I'm actually pretty accepting of that timeframe, but since it's a complaint that I get, faster is always better. I don't necessarily think that the speed is bad as it is, just that faster would be better.

It's really hard to criticize something that has become somewhat seamless for us. If they wanted to expand their capabilities into other areas of security, that would be fine. They're a very knowledgeable group of people. We do meetings with them on a pretty regular basis. We gain insights from their perspectives. To me, if they just broadened their footprint into the areas that their feet feel comfortable going into, we'd have no problem pursuing that.

Mitigation review isn't always super easy.

* Entering comments for internal tracking * Entering a priority * Reports that show the above

* The user interface could be more sleek. * Some scanning requirements aren't flexible. * Some features take some time for new users to understand (like what exactly "modules" are).

It should include more informational, low level, vulnerability summaries and groupings. Large related groups of low level vulnerabilities may amount to a design flaw or another avenue for attack.

They've improved the speed of the inspection process. I'd never want the inspection process to become something that's suspect. False positives would diminish confidence in the results; if we don't continue to focus on reducing false positives... that is number one. The on-platform reporting needs to be opened up much more. We'd like to be able to look at the inspection data from a trending perspective in a much more open manner. I need to be able to sort and filter much more flexibly than I can today. I don't have the on-platform flexibility to sort and filter inspection data, and that's not good. Another thing I need is continued support for the new languages today that are popular. Most of them are scripting languages more so than real, fourth-generation, commercial grade stuff; we're evolving. Most applications are using so much open-source that, quite frankly, it would be great to see Veracode, or anybody else, extend their platform to where they are able to help secure open-source platforms or repositories. Currently, I have to have another supplier in my tool chain and that means I have to extract data from different tool repositories to see one holistic picture of security quality, risks, and vulnerabilities. It would be great if I could see it all in one place, but I have to harvest the information from Veracode, harvest information from Rapid7, harvest information from Sonatype, just so that I can get a good, round perspective of where my first-party and third-party code, and the components in the dependent libraries, are in terms of weaknesses, risks, and vulnerabilities. That's a burdensome activity. If Veracode spent more time providing more plug-ins to other competitors' environments, or provided very open APIs so we could harvest data, bring it into one lens so that we can look at the security inspection data through one set of dashboards, it would provide a lot more value from a governance perspective.

Going through the mitigation is probably the hardest thing to do and that's still an ongoing process. If there is a code issue to mitigate, it sometimes takes a little bit longer than what you would think. It might not be anything that they're doing. It's just their engine is changing and our code is changing so we have two things moving. We get a good score one time, scan it again on a new release and the score drops because the engine is picking up more things. I don't know if they could do anything about that. It's just one of those things you might just have to live with.

It's a pretty dynamic product. It's changing all the time and improving.

The Web portal, at times, is not necessarily intuitive. I can get around when I want to but there are times when I have to email my account manager on: "Hey, where do I find this report?" Or "How do I do this?" They always respond with, "Here's how you do it." But that points to a somewhat non-intuitive portal. With that said, I hate when companies redo their portals all the time. So it's kind of a catch-22, but that would be my only critique.

It can take time to find options if you don’t use the interface a lot. At some point, a bit of interface restyling may help (but not now, now that I've learned it).

Reporting. Some of the reporting features of Veracode do need improvement. They do not have the most robust access to data. That would be a bit more beneficial to a lot of our clients as well as our actual in-house staff. I've been talking to our program management at Veracode about that, and that is actually on their radar to have that improved, I think actually this year. That would probably be the biggest area, access to more granular data that we could pull and use on a regular basis. Better dashboards. That kind of information.

Calypso (our application) is large and the results take up to two months. Further, we also have to package Calypso in a special manner to meet size guidelines.

The only notable problem we have had is that when new versions of Swift have come out, we have found Veracode tends to be a bit behind in updates to support the new language changes. Also the Greenlight product that integrates into the IDE is not available for PHP, which is our primary language.

The user interface can sometimes be a little challenging to work with, and they seem to be changing their algorithm on what is an issue. I understand why they do it, but sometimes it causes more work on our end.

I think they are doing pretty well. It would help if there were a training module that would explain how to more effectively integrate the SAST product into the build tool, Jenkins or Bamboo. I think that's a real good idea.

We use Ruby on Rails and we still don't have any support for that from Veracode. The static scans on Java lack microservices architecture scanning. We have developed an in-house pattern for this and the scans can't take care of it as a single entity.

* Better APIs * Reporting that I can easily query through the APIs * Preferably, a license model that I can predict It would save us time when integrating with the APIs. Difficult APIs are annoying to work with and we have to trial/error our way through the integrations. The more straightforward and friendly they are, the less we have to trial/error.

All areas of the solution could use some improvement.

Number one, I need analytics, analytics, and more analytics. It is all about risk based management and better decision support, that is why.

I'd like to see an improved component of it work in a DevOps world, where the scanning speed does not impede progress along the AppSec pipeline.