Veracode Reviews

Static analysis.

It has allowed us to integrate with it through automated processes, which saves us a lot of time and effort.

Also, our customers benefited from the added application security assurance of our software, as they’ve been able to identify OWASP top-10 application vulnerabilities without a manual tester.

Static analysis scanning engine, because we need to do static analysis; that’s why we bought the product.

• 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.

No issues with stability.

Aside from the licensing, no issues with scalability.

Good.

IBM Security App Scan. In looking at Veracode vs IBM Security App Scan, I switched because of the CI/CD offerings of Veracode.

The APIs are a bit nonsensical, but otherwise straightforward.

It has not really resulted in any cost savings related to code fixes.

The worst part about the product is that it does not scale at all. Also, microservices apps will cost you a fortune.

IBM, Coverity.

Regarding measures taken to integrate Veracode into our existing software development lifecycle, we have 100% API integration. We use the Jenkins plugin as a last resort, but we are moving away from that.

The AppSec best practices and guidance to our security and development teams are manifested in the static analysis it provides.

In terms of advice to others looking into implementing this project, I would say don’t use the UI, and do what you can to have license conversations up front.

It depends on the use case and budget, but I would recommend CA Veracode to colleagues.

I helped customers to build and start the journey of SecOps with Veracode.

Veracode helps to know and prevent vulnerable code or applications from being deployed. We can scan, consume reports, and fix vulnerabilities before deploying an application.

It is very good for ensuring compliance with industry standards and regulations. We can have many dashboards and reports related to policy management.

Veracode provides visibility into application status at every phase of development. We can have many analytics dashboards and reports, and we can build a custom dashboard to have this visibility. This visibility is essential for DevSecOps processes. We need this visibility and information to have a strategic approach and mature our security.

Veracode has the lowest false positive rate in the market. Its results are accurate. In some cases, it is very difficult to see a false positive. We report it to the engineers, and they analyze it. If it is truly a false positive, the engineers will update the engine to provide better results at the next scan. The false positive rate of the static analysis has not affected the time we spend on tuning policies.

It has had a very good effect on our organization’s ability to fix flaws. We are developing a new feature, and Veracode will help to quickly fix any flaws.

It has helped our developers save time, but I do not have the metrics.

All features are valuable. I especially like SAST and ADO.

It is scalable and quick to deploy into the site and the pipelines. The reports and analytics are good, and the false positive rate is low. It gives true results.

There should be more APIs, especially in SCA, to get some results or automate some things.

I have been using this solution for almost three years.

It is very stable.

It is very scalable. I help other companies to deploy. Some of them are small, and some of them are big.

Their support is good. I would rate them a nine out of ten.

Positive

I have not used any other solution previously. I have only worked with Veracode.

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

I implemented it myself. I work with DevOps and security teams. In some cases, I also work with developers.

It does not require any maintenance. Because it is a SaaS solution, the maintenance is provided by them.

The ROI is in terms of time savings and mature security. When you deploy a solution like Veracode, you can have these quickly.

It reduces the cost of DevSecOps for the organization when you use it for more than one year.

Its pricing is fair.

It is essential and perfect for preventing vulnerable code from going into production. Nowadays, it is very important and sensible to have a solution like Veracode to know all the vulnerabilities and manage and prioritize the ones that are more critical and better for security posture.

I have not used the Software Bill of Materials (SBOM) feature much, but it is easy to create a report using the SBOM feature. It is important for the supply chain that your software uses.

I would rate Veracode a nine out of ten.

We are using the static application security testing from Veracode and the Software Composition Analysis solution for the main product that we are developing. We don't use the Software Composition Analysis for checking license requirements, but only for finding problems in third-party dependencies.

It has given our management a view into issues with all of our product lines. We have three products and all of them were scanned. As a result, the project lead for each product has taken measures to improve things.

We also use a third-party dependency check from OWASP that is included in one of our other solutions. The Software Composition Analysis from Veracode is on top of that. It offers integration with the Veracode platform so that we can visualize all of these security problems at once. It is great to have an overview of all of the security problems that we have on all of our applications.

The most important thing that we have used Veracode for is the static application testing. That was our main target.

The UI is messy because it freezes sometimes and some of the UI components are blocked and I do not know why that is happening. It's not happening only to me. Colleagues have reported to me that they have this issue.

We have been using Veracode for more than a year, but we have only been using the Software Composition Analysis for a few months.

We haven't run it often enough to check if it is stable or not.

The support guys are good professionals. We have received valuable comments on proposals from their side. They are reliable partners and have good expertise.

Positive

We use various techniques to improve our security. We use an OWASP software application networking model to improve security in our different products. We use a number of native plugins to check licenses and vulnerabilities in the third-party libraries that are part of the application. We also have several plugins from SonarLint that are integrated in another tool that we use for quality assurance.

We put Veracode in place because we have an agreement with SAP and we must fulfill some security checks to become partners for their solution. Veracode's functionalities resolve all of the security checks that were demanded of us.

We use a different company for pen tests, three times per year, and it usually takes two or three weeks each time.

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

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

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

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

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

We hope that we will have a successful integration in the near future and that it will bring major benefits, at least for the managers and the people who are responsible for analyzing the flows and for keeping security under control. The amount of management effort will be reduced at that point.

For our company, the price is reasonable for the benefits that we get.

We paid for a one-year license. The contract was reasonable in terms of financial features. The pricing itself depends on the size of the company and on how much the company is willing to pay for these security extensions and how much the company is willing to invest in security in the first place.

Veracode was rated by industry reviews as the top player in this field for static application security testing and SCA. My advice would be to investigate the market because it will give you an idea of what is the best and most cost-effective solution for your company.

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

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

It's a SaaS solution.

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

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

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

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

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

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

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

We have been using Veracode for four months.

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

We primarily looked at Netsparker as an alternative. 

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

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

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

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

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

I'm an automation practice leader and we are customers of Veracode.

The valuable features are the static analysis and the dynamic analysis. The security is also a good feature.

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.

I've been using this solution for four years. 

I haven't had any issues with the stability. 

The solution is scalable but if we scale too far then the performance is impacted. We have around 300 developers using Veracode. 

The technical support is good. Whenever we have any vulnerability issues, we can easily contact them and then have a triage with the technical support team.

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

Veracode is very, very expensive, one of the most expensive security scanning tools available.
We pay an annual license fee that is over $1 million. 

For any company wanting to use Veracode and buying vendor binaries from third party vendors, it's important to get the legal and compliance clearance from the vendor as well. Some vendors have a policy that they're selling you the binary of a particular software but you're not supposed to decode it. Those are the general terms and conditions that every vendor gets you to sign but Veracode does decode and then scans for the vulnerabilities. It's a challenge for any company purchasing the solution from vendors.

I rate the solution six out of 10.

The use case is that we have quite a few projects on GitHub. As we are a consulting company, some of these projects are open source and others are enterprise and private. We do security investigating for these projects. We scan the repository for both the static analysis—to find things that might be dangerous—and we use the Software Composition Analysis as well. We get notifications when we are using some open source library that has a known vulnerability and we have to upgrade it. We can plan accordingly.

We are using the software as a service.

It has improved the way our organization functions mostly because we can perfect the security issues on our products. That means our product managers can plan accordingly regarding when to fix something based on the severity, and plan fixes for specific releases. So, it has improved our internal process. It has also improved the image of the company from the outside, because they can see in the release notes of our products that we take security seriously, and that we are timely in the way that we address issues.

The solution has helped with developer security training because when we open a ticket with information coming from Veracode, it explains, for example, that some code path or patterns that we have used might be dangerous. That knowledge wasn't there before. That has really helped developers to improve in terms of awareness of security.

The feature that we use the most is the static analysis, by uploading the artifacts. We have two types of applications. They are either Java Server applications using Spring Boot or JavaScript frontend applications. We scan both using the static analysis. Before, we used to do the software composition on one side and the static analysis. For about a year now, we have had a proper security architect who's in charge of organizing the way that we scan for security. He suggested that we only use the static analysis because the software composition has been integrated. So in the reports, we can also see the version of the libraries that have vulnerabilities and that need to be upgraded.

It is good in terms of the efficiency of creating secure software.

My team only does cloud-native applications. Ultimately, the part that we are interested in, in testing, works fine.

There are some false positives, like any products that we have tried in this area, but slightly less. I would trust Veracode more than the others. For example, we had quite a few issues with Snyk which was much worse in terms of false positives, when we tested it for open source.

Also, the solution's ability to prevent vulnerable code from going into production is perfectly fine. It delivers, at least for the reports that we have been checking on Java and JavaScript. It has reported things that were helpful.

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.

I have used Veracode for quite a long time now, about two years. I have been working here for three years. In my first year, the company was using a different product for security and then it standardized on Veracode because every department had its own before that. There was consolidation with Veracode.

The stability is good. What I have seen in the stats is that there is downtime of the service a little too often, but it's not something, as a service, where you really need that level of availability on. So I'm not really bothered by that.

We don't have to do anything to scale, because it's SaaS. 

We started with a smaller number of users and then we extended to full single sign-on.

The staff of Veracode is very good. They're very supportive. When the product doesn't report something that we need and is not delivering straight away, they always help us in trying to find a solution, including writing custom code to call the APIs.

From that point of view, Veracode is great. The product, much less so, but I believe that they have good people. They are promising and they listen so I hope they can improve.

We started with WhiteSource, but it didn't have some features like the static analysis, so it was an incomplete solution. And we were already using Veracode for the static analysis, so when Veracode bought SourceClear, we decided to switch.

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

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

My job is mostly technical. I don't own a budget and I don't track numbers. But as the customers are really keen on having us checking security issues, I would definitely say that we have seen a return on investment.

Most of our customers tend, especially in the software composition analysis, to apply their own in-house tools to the artifacts that we share with them. Whenever we release a new version of software and Docker images, they upload it to their systems. Some of them have the internal equivalent of Veracode and they come back to us to say, "Hey, you haven't taken care of this vulnerability." So it is very important for us to be proactive on each set of release notes. We need to show the current status of the product: that we have fixed these vulnerabilities and that we still have some well-known vulnerabilities, but that there are workarounds that we document. In addition they can check the reports that we attach, the reports from Veracode, that show that the severity is not high, meaning they don't create a big risk.

It delivers because we haven't been thinking, "Okay, let's consider another product." We might see some savings so I think the pricing is right.

For open source projects we mostly tested Snyk, which works quite well with JavaScript but much less so with other technologies. But it has some bigger problems because Snyk considers each file inside a repository of GitHub as a separate project, so it was creating a lot of false positives. That made it basically unmanageable, so we gave up on using it.

We have also been using an open source project called the OWASP Dependency-Check that was doing a decent job of software composition analysis but it required a lot of effort in checking false positives. To be honest, it would have been a good solution only if we didn't have a budget for Veracode, but luckily we had the budget, so there was no point in using it.

Another one that we tried, mostly because it was a small company and we had the opportunity to speak directly with them to ask for some small changes, was a company called the Meterian. It doesn't do static analysis, but otherwise the software composition analysis and the library report were the best of the bunch. From my perspective, if we didn't have the need for static analysis, I would have chosen Meterian, mostly because the user interface is much more usable than Veracode's. Also, the findings were much better. We still use it on the open source project because they offer a free version for open source—which is another good thing about some of these products, where the findings are available to anyone. For a company like ours, where we have both open source and enterprise products, this is quite good. Unfortunately, with Veracode, if we scan the open source project, we cannot link the pages of Veracode with the findings because they are private. That's a problem. In the end, for the open source projects, we are still using Meterian because the quality is good.

My main issues with Veracode, in general, are mostly to do with the user interface of the web application and, sometimes, that some pages are inconsistent with each other. But the functionality underneath is there, which is the reason we stay with Veracode.

Usually, we open tickets now using the JIRA/GitHub integration and then we plan them. We decide when we want to fix them and we assign them to developers, mostly because there are some projects that are a little bit more on the legacy side. Changing the version of the library is not easy as in the newer projects, in terms of testing. So we do some planning. But in general, we open tickets and we plan them.

We also have it integrated in the pipelines, but that's really just to report. It's a little bit annoying that the pipeline might break because of security issues. It's good to know, but the fact that that interrupts development is not great. When we tried to put it as a part of the local build, it was too much. It was really getting in the way. The developers worried that they had to fix the security issues before releasing. Instead, we just started creating the issues and started doing proper planning. It is good to have visibility, but executing it all the time is just wrong, from our experience. You have to do it at the right time, and not all the time.

The solution integrates with developer tools, if you consider JIRA and GitHub as developer tools. We tried to use the IntelliJ plugin but it wasn't working straightaway and we gave up.

We haven't been using the container scanning of Veracode, mostly because we are using a different product at the moment to store our Docker images, something that already has some security scanning. So we haven't standardized. We still have to potentially explore the features of Veracode in that area. At the moment we are using Key from IBM Red Hat, and it is also software as a service. When you upload a Docker image there, after some time you also get a security scan, and that's where our customers are getting our images from. It's a private registry.

Overall, I would rate Veracode as a five out of 10, because the functionality is there, but to me, the usability of the user interface is very important and it's still not there.

• Scanning web-facing applications for potential security weaknesses.
• Helping to document the introduction of technical debt in our code bases.

• It gives feedback to developers on the effectiveness of their secure coding practices.  
• It has almost completely eliminated the presence of SQLi vulnerabilities.

• Multiple languages and framework support: We can use one tool for our SAST needs.
• Developers report liking the IDE integration provided by this tool.

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

Interestingly enough, Veracode has evolved over time. Their chief designer has been a leader in security for many years and his insights into applications, and what we now consider DevOps, has been very helpful for the industry. The insights into how we now have a mobile workforce, and that the end-point is what you carry in your hand - and the protection of those apps and web pages - are imperative because the coding in our information has moved out. Quite honestly, the people have become the firewall. 

The products that Veracode has developed help me to manage that, scan that, know when something is going wrong, and I don't have to have a team of developers behind me that keep up with all the latest threats because the subscription service they provide for me does that.

Veracode helps me in several implementations over a couple of industry sectors in a number of ways.

My coding, especially the code we develop, has a number of faults per line and that costs me money and time to fix those, into the lifecycle. Veracode enables me to provide better code, faster, so my time to market is less.

The security means my total cost of ownership goes down significantly over a period of time. The more code I write, the better I organize that, the less my expense is in maintaining that code.

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.

There are always a few bumps going into any new implementation because nobody has the same environment. We are in heterogeneous environments.

But I couldn't point out any one significant problem that comes to mind, because the bumps that we have found have been addressed and corrected pretty quickly.

Scalability is almost infinite in this because the cloud-based solution allows me to expand. The companies I work for are generally in the 10 billion-plus range, but with thousands of developers we have never really had anything on the capacity planning or the performance of the products.

Their technical support is the best in the business. These folks have been around, like I have, for many, many years so they have grown up with the industry. Not only are they developers, they have been practitioners before. Their chief designers, their coders - although many of them change - the key people who started this are still there, and you'll know them by first name; pick up the phone and they can help you with what you need.

Any previous solutions would have been more than 10 years ago, and I don't remember why we switched. It's like the car you drive or the shoes you like to wear: Once they work - and it has worked in multiple sectors - there is no reason to change.

When selecting a vendor, the important criteria are relationships and support. When I pick up the phone and I get a Sam King or a Bob Brennan on the line, things happen.

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

On the rating scale is there anything above 10? If there are no ones and tens, it would be the closest to 10. They have always been supportive. We have had to change, do course corrections during implementations, or particular types of coding. I have just never had a problem. My loyalty to the product has been primarily due to the service and the expedience in which they solve any problems we have.