Veracode Reviews

Dynamic and static code analysis.

It has given us insight into the actual flaws that are out there, and the speed at which they're getting mitigated. Now, we're starting to see quantitative metrics to show the overall risk with code vulnerabilities. It has been very helpful in that it has exposed an area that we weren't digging into as much as we should have, before.

The developers' awareness of the security weaknesses within their code has also improved. They aren't just mitigating these issues, they are realizing these are, in fact, issues that have to be dealt with.

We are just starting to integrate Veracode into our software development lifecycle. We are reaching out to a few of our developers to begin project Greenlight. Specifically, right now what we're doing is integrating the static code analysis scans into our change approval. If you want to put a new piece of code live, you have to have a clean Veracode scan, whether it be through mitigation approval or through actually resolving issues. We've integrated it as part of our CAB process, and we're going to take that a step further and integrate it into the actual IDE for the developers.

In terms of security best practices and guidance to our dev teams, Veracode has been fantastic. The one thing we really liked about Veracode when we got it - and I think some other providers are doing it now - was the consultation calls; that our developers are able to schedule them on their own, instead of going to a "gatekeeper." They upload their code, they have questions, they schedule it, they speak with someone on the other side who is an expert, they can speak developer-to-developers. That is really good stuff.

Regarding our customers, I don't know if they have benefited per se, other than getting better, more secure applications. I don't know that our customers are necessarily looking for the most secure application, but it is something that I'm sure is on their mind, and they want to know that we're doing it. I would call it a tangential or unseen benefit. It is probably not in the top-10 things that they're looking for when they use one of our apps or our website. They are just assuming that a company such as ours is going to make sure that we have the appropriate security controls in place. So the way they benefit is that, hopefully, we're meeting that expectation, but I don't know that our customers are specifically looking for that as a decisive factor for using our websites or apps.

The reporting and mitigation features which allow our people to work on their own.

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.

One to three years.

I don't think that we are even beginning to push the envelope of what the system is capable of. We haven't had any problems. I'd say we are probably on the lower end of usage, not only the number of scans but regarding the number of applications. I haven't seen any issues, but I also wouldn't expect to hit issues, given where we are.

The support team itself, or security program manager and a few others, have been fantastic. Most of the time, they're willing to move and work faster than we are actually capable of. They have been spot on in helping us get this thing rolling.

They are fantastic. They get the highest rating.

We used HP WebInspect, which is now under the Fortify umbrella. HP WebInspect was just terrible. Had we used the on-demand cloud piece - which is why I perhaps have to pull my comment back - maybe we would have had a different experience. But we had a WebInspect instance on a single server that was inside of our own data center. It was very, very kludgy, very slow, didn't work very well. We were hitting the required specs for it but we'd have a dynamic website scan, which should not have taken very long, taking a week. It not only should have been very close to the scanning engine, but had its own dedicated route for pieces that live in the cloud. It was bad, and it was slow, and their reporting was terrible. There was no real support for it. It was just very bad.

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

I can't think of any cost savings related to code fixes since implementing Veracode. We are mostly focused on using it for application security, which is a hard thing to quantify unless you have a major breach.

I think the pricing is in line with the rest of the tools. I think you get what you pay for. It is certainly not inexpensive, but the value proposition is there. There are certainly cheaper tools, but I don't think we'd be getting the support that we get with those, and that is what separates this product from the others.

Regarding licensing, pay very close attention to what applications you're going to need to do dynamic scanning for, versus static. Right now, the way the licensing is set up, if you don't have any static elements for a website, you can certainly avoid some costs by doing more dynamic licenses. You need to pay very close attention to that, because if you find out later that you have static code elements - like Java scripts, etc. - that you want to have scanned statically, having the two licenses bundled together will actually save you money. 

You really need to understand how your application is going to be delivered and not think of it just as, "This is a website and this is a mobile app," or "This is a website and this is a fat client." Often, with new frameworks, you have websites - especially with Java specifically, which is not even a new framework - running Java, but you also have things running in a local Java sandbox on the machine, or on a Java virtual machine. You really want to understand how that application is being delivered to the end-user, and not just think of it as applications on a box and websites.

My advice is what I mentioned in the pricing/licensing section above, you really need to understand what it is you are looking to do.

Also, take into account a data sensitivity for the applications. It's not "one policy fits all." I really like that Veracode allows me to set up specific policies that I can apply to applications. Understand which are your critical apps that deal with critical, very sensitive data, and then apply a more rigorous scan model to them, versus internal applications that perhaps don't deal with as much PII, with as much sensitive information, and aren't available to the outside world. Those might have a lower risk footprint. Understand that, so when your developers go in there you are not treating every single thing like it is a public-facing, client-data-gathering, credit-card-processing web app. That way your developers can prioritize what they need to work on, so that you are delivering the right metrics to your leadership.

You really need to understand that strategy going in, because the tool is not going to help you determine that. The tool is only going to help you scan.

The only reason I don't rate it a nine or a 10 out of 10 is because we haven't hit those scalability roadblocks yet. I know we might have some challenges in the future, but I would say eight out of 10 is an incredibly good score for a product like this. If you were just asking me about the support and the people behind it, I would rate that a nine or a 10. If you bundle it all together it's an eight.

I recommend Veracode to colleagues all the time.

Provides static code analysis of the customers' applications from all industries. It includes any type of code and scripts, but mostly Java, .Net, C++, and C# environments.

The solution is a specialist in SAST that you can rely on. Code scanning is fast with current, updated algorithms.

Provides consistent evaluation and results without huge fluctuations in false positives or negatives. 

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.

Application development and secure code development.

We do automated scanning, so we use it as part of our development cycle. We do both automated security scanning as well as our own automated testing. We run the two in parallel and treat both outputs of, let's say, a sales functionality test. A security vulnerability is just a defect that needs to be resolved before we release the product.

We do an automated upload to the Veracode platform for all of our applications - we have about 35 applications. For all of them, it's automatically done, pre-configured, pre-compiled, based on scripts that we worked out with Veracode. And then on a scheduled basis, the upload and scanning is done, in some cases, twice a month. In some of our applications, two to three times a week, we just constantly scan and look for exposures, and continue to feed that back to the development team and make sure that they don't release product that's not ready for market.

We have found that our developers have become a lot more knowledgeable about how to develop secure code, and that was very important to us. We also became more knowledgeable about vulnerabilities in the market, which are the most critical to address. You could say it helped us to apply the right investment in the right place.

In terms of best practices and guidance, we do quarterly reviews with Veracode, where they're analyzing our information alongside of us and providing feedback to our executive team to suggest strategic changes in certain approaches. We've also done benchmarks with them, where we've compared our maturity model to the industry's model, as far as security practices go and best practices for security and such. In some cases, we've made adjustments to improve, and in some cases we are confident we're ahead.

Regarding our customers, for one, they can move to market faster, we can move to production faster. Also, we discuss our security program and the software development life cycle with them in pre-sales discussions, post-sales discussions, implementation approaches. What it does is, it gives them the confidence to move ahead in a more direct fashion, with one less headache for them to worry about.

• The static scanning of the software is very important to us.
• The ability to set policy profiles that are specific to us. 
• The software composition analysis, to give us reports on known vulnerabilities from our third-party components.

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.

No issues with stability.

None.

Tech support is very effective. We can do online requests for read-outs with their tech support - but the more common support would be for security advisory, when we're looking at certain vulnerabilities that we're struggling with how to remediate. We can get online with one of their security engineers, and they provide advice to us some best practices on making the code changes to secure the system. They do a very good job of that.

Prior to working with Veracode, we used a self-applied application. That is, we had the solution on-premise, but just could never quite get the routine approach that we've developed with Veracode. The program management features that Veracode offers to help us get our program up and going, along with the low false-positive rates that their solution provides - versus what we had done in the past - gave us some immediate traction. I think that we were able to make progress in the first five or six months working with Veracode, that we had not made in four or five years with previous approaches.

It was a dynamic scanning solution but, again, it was on-premise. Veracode is a cloud-based platform, where they manage all the back-end, and they do a lot of analysis during the scans, and they do a lot of post-scan reconciliation, where the other solution was a good solution, but all of that work fell upon us to do for ourselves. Our focus is on developing features and functions for our application, and running an application security platform in-house is just not practical, just not our core competency.

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

By implementing Veracode in our development process, what we've done is cost avoidance, not necessarily savings. By getting ahead of it, and releasing product to the market that's more secure, we have very few, if any, reported issues by our customers. So we don't have to go and do a maintenance repair of those. That's an avoidance of cost. 

It's a pretty accepted standard that if you release a vulnerability or a flaw into the market, it's going to cost you 10 times more to address it after the fact than if you prevent it. I'd say that that, plus the automation of the scanning, has also reduced the amount of capacity or full time equivalence we have to apply to repair and scan.

As I said, we have 35 applications, and instead of having 35 different people preparing their packages for upload and scan, it's automated. We don't have to spend money doing that as well. 

So avoiding the cost of releasing vulnerabilities into the market that get caught by customers and reported back, is a big one; and then, reducing the investment of performing the continual scans.

We're very comfortable with their model. We think they're a good value.

We worked very closely with Veracode on understanding their license model, understanding what comprises the fee and what does not. With their assistance in design, we decomposed our application in a way where we are scanning a very significant amount of code without wasting their capacity and generating redundant reported issues. You scan in profiles, per se. And we work with them, in their offices, to design the most effective approach.

So the advice I would have for customers is, you can get up and live fast, but work closely with Veracode to refine the method you use for scanning and the way you compile the applications. There's a concept called entry-point scanning, and that's probably not used well by the rest of their customers. We see our licensing as a good value because we leverage it heavily. I'd say many customers might not quite go to that level. But that's their choice.

I'd rather not give out competitor names.

But the method we were using in the past was what is called dynamic scanning, or DAST. That required we have an environment that was up and running with the application, and then we could proceed to scan. You can see that if we have 35 applications, that means we've got 35 environments running our application internally, just for scanning purposes. That's a lot of hardware, whereas this methodology uses static scanning, where we upload the compiled code and we don't invest any hardware in doing that. The scanning capability not only does the scanning but contains the application code for us. There are a lot of complexities with trying to do a dynamic scan on-premise, versus a static scan on a platform.

You almost can't compare the two. False-positive rate in the dynamic scanning was very high - 30 percent, maybe - and the false-positive rate for the static scanning is very low - maybe two to four percent. That is a significant value, because you don't have to spend a lot of time sorting through reported issues to determine if they're valid or not. We're pretty well assured that as we start investigating one, it's more than likely valid. We don't have that doubt entering in.

It was a different approach. Two concepts: 

1. That it is a cloud-based solution, which is very valuable to us, we don't need that hardware running our scans and hosting the environment to be scanned.
2. The technology, the static scanning versus dynamic scanning produces a much better result, a more accurate result.

We recommend Veracode to colleagues all the time.

I'd give the advice of not getting hung up on trying to compare the static scanning to the dynamic scanning, that's number one. Don't even compare them. If you're doing neither, do statics first. It'll get the majority of your exposures addressed. Then you come in, in a second round, and do dynamic. Dynamic really becomes more of a confirmation of security.

The other piece of advice I'd give is to "follow the directions." Make sure they understand how they're supposed to compile code. Take the advice of the program management team with their code, and follow their lead, and you'll come out in a very good position very quickly.

I'd give Veracode a 10 out of 10 because the rate at which we gained control of our security posture, from a development perspective, was fast. There is a lack of wasted time on our developer organization in chasing down erroneously reported vulnerabilities. The erroneous reported vulnerabilities is very low, and that means that our developer time is very effective as we investigate a reported issue. As I said, it's 96, 98 percent probability it is real. So our developers gain confidence and don't second-guess the results. 

The level of detail that we are provided for a given vulnerability - the data path that it follows, the precision with which the justification is provided - is very high. Again, you're highly confident in the result. You are provided a tremendous amount of detail about the vulnerability it found. And the rate at which you can ramp up and be productive is very fast.

Certifying the application security of my SAS-based application code base.

It allows us to prove our security levels to vendors, and additionally helps us with our HIPAA security policies. Also, CA Veracode has provided AppSec best practices and guidance to our teams. Finally, it makes the IT Governance process of the sales cycle easier.

Static and dynamic scans of the code. It is part of our release cycle.

Mitigation review isn't always super easy.

No issues with stability.

No issues with scalability.

It is excellent.

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

It helps us get over the line for security when contracting with customers, and any help reducing security vulnerabilities is a big help to us.

Pricing/licensing is complicated.

Do your research, make sure you implement the tools you need.

I am very likely to recommend Veracode to a colleague.

We test each major release of our software using Veracode static and dynamic testing. We also do manual penetration testing annually.

Ensures our code and system are 100% compliant. In terms of APPSec best practices and guidance to our team, the Knowledgebase available on the Veracode system is a great resource for our developers.

For our customers, the added security assurance is a requirement.

• Ad-hoc scanning during the development cycle
• Reports for audits

In terms of integrating Veracode into our existing software development lifecycle, there are regular milestones in the SDLC to perform Veracode scans.

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

No issues with stability.

No issues with scalability.

Excellent.

We did use a previous solution. It didn't satisfy our needs technically, and the customer service and its cost were not satisfactory.

Easy.

We don't do a detailed enough analysis to reflect on any cost savings relating to code fixes made since we implemented Veracode.

Negotiate some, but their prices are reasonable.

HPE Fortify.

Have them guide you through your first scan - make sure to add hours to your initial contract for that.

I am very likely to recommend Veracode to colleagues.

Scanning for code security vulnerabilities within our company's products.

Made our company aware of any potential code security vulnerabilities. Also, customers can use our products knowing they are verified by top organizations as safe.

Informing me of application security vulnerabilities. Bamboo build-automation with Veracode API calls are used.

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

No issues with stability.

No issues with scalability.

Great.

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

I can't report on any cost savings relating to code fixes since implementing Veracode in our development process, but it makes us feel more confident about our code, which is awesome.

We are satisfied.

None. We might look into Checkmarx.

I am very likely to recommend Veracode to colleagues. Veracode is great.

We use it to assess or do security inspections of our software that we produce or assemble. We have a very large portfolio of software across our enterprise. The Veracode system is a platform that scales with the dynamics of our organization. We have people that are in many locations, in the US and abroad. The fact that the Veracode platform is essentially a cloud-based platform, that makes it scalable.

We are able to create business policies, and the Veracode system allows us to enforce those policies. That's at the very high level.

We're looking at improving the overall security quality of our software. We use it as a platform to help enable that process. Veracode, in and of itself, is doing nothing but inspecting software. But, there are many other practices that are essential to onboard and embed into our development lifecycle. Veracode is simply the platform that lets us see how well the software is being engineered. Based on some of the findings, we make improvements in areas that need education.

It can't be boiled down to the one or two most important things. It's not Veracode by itself that's doing all of the stuff, there are a lot of tertiary activities that go into building better software. The Veracode system is used to help us validate the security quality of what we're producing. It helps us zero in on some of the things that we can do better. But that means we have to provide education to our developers and architects.

In some cases we use their APIs; they're not as rich as I would like. We have added Greenlight to the IDEs, where the Greenlight tool is compatible.

In terms of cost savings relating to code fixes since implementing Veracode, it would be difficult for me to give you some specifics. I'm not exposed to the cost of the iterations. Development teams have a budget for the year. There are features planned, there are releases planned. There are many other functions responsible for planning the releases. My job is to provide application security tools, so that they can incorporate the security practices that our company expects us all to adhere to. We know, anecdotally, that the time to write software, or scripts... You should write them securely, as opposed to having some additional testing development activities, and several other iterations downstream, because that would mean we're paying three, four, or five times for our resources to accomplish what they could perform correctly the first time, out of the gate.

In that sense, the Veracode system, since we've been using it, has helped us identify and code correct over 34,000 security weaknesses. That means there are 34,000 weaknesses and vulnerabilities that never made it into production. It's hard to quantify, if any of those had been exploited, what would have been the real cost to catch them. The only thing I could do is speculate on cost right now. But we do know that it's far better to embed security upstream in the development lifecycle, and produce software correctly the first time, rather than retroactively adding security remediations to the iterations that produce software for service packs and patch releases. Those are unplanned events and there are certainly costs associated with those unplanned events. But I don't have a number I could throw out there and tell you what it is.

I don't really look at Veracode as providing any best practices. It may have some educational aid embedded in the platform. I think the Veracode database of remediation guidance is somewhat vanilla. It's not contextual. I frankly don't rely on it to provide the kind of guidance developers need contextually. So, we augment education aids and remediation guidance with humans, security analysts. We also have other third-party solutions that really provide more contextual remediation guidance unique to the situations, as developers are trying to address them. We don't anticipate what their system is going to identify. But, based on what the system identifies, I would say it's 50/50, whether or not the scripted, plain vanilla, embedded guidance is really the right approach. It may or may not be, and I would say it's probably 50% accurate, but it's very vanilla.

In terms of benefits to our clients from using Veracode, that's like asking me: Am I really happy that my car stops when I press the brakes. I think most people would expect cars to have brakes, and the brakes to work. No more, no less. Software, to me, it's probably in the same wheelhouse, that people use software without thinking, "Is it really secure?" It's assumed, frankly. So I'm not so sure our customers consciously think about security as a benefit, unless they are breached or compromised. It's one of those things that's difficult to track, in terms of how customers are benefiting. We just know that through our efforts we're delivering high-quality software.

Maybe customers that are being independently assessed by third-party assessors - when those assessors have to do security inspections of the technologies that may be consumed by those institutions - if our software is deployed on-prem, we tend to believe that our software will have fewer weaknesses and vulnerabilities identified than, say, other technologies that are consumed on-prem. Only then, might it become apparent to the customer that they're working with a supplier of software that provides higher quality, relative to other suppliers.

The Static and Dynamic Analysis capabilities are very valuable to us. 

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. 

I hold Veracode in high regard. It's a good organization to work with, and it's a very conscientious organization. I'm always a recommender of the solution set.

To certify that we have valid code, and that the developers are working with valid structures and writing good code.

The coding standards in our development group have improved. When we scan our code - at the end of a build cycle we'll go through and scan our code - from those scans we've learned the patterns and techniques to make our code more secure. An example would be SQL injection. We have mitigated all the SQL injection in our applications.

That is now part of our software development life cycle, to do a static scan before we release to our client base. We mitigate what we have to.

I'm not aware of any cost savings relating to code fixes since implementing Veracode in our development process.

In terms of Veracode providing application security best practices and guidance to our development teams, once we scan the software and we have to go through a mitigation process, we make sure we implement that in the base standards. Once we mitigate a problem, we implement it back into the base to make sure the developers who are still developing code are not going to have the same issues that we just mitigated.

For our customers, they know that we go through another level of application security with our application, one our competitors don't use. They know our code meets a standard and that we implement the standard and the structures. That we have mitigated gives them a little bit of peace of mind that our code is valid, and that it's not going to hurt their infrastructure. 

We just use the static scan, it's all we got into as of now. We're happy with that, it seems to work very well for us.

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.

No issues with stability.

No issues with scalability, we're good there.

They're very good. Anything that we've brought up to them, they've responded to us very quickly.

We used the built-in solution inside of Microsoft Visual Studio, and we switched because Veracode had more cohesive scanning abilities and found a lot more issues with our code, when we first scanned it.

It was pretty straightforward.

We get good value out of what we have right now.

We had a couple of products that we looked at, but went with Veracode.

I am highly likely to recommend Veracode to colleagues.

Make sure, once you scan and find issues with your code, that the developers know how to remediate those issues so they don't go through them again.

It's going to take some time to get through your first set of scans and mitigations. To fix your code is not straightforward. But once you do that and implement it back through your whole development cycle, they identify the issues and it's very easy to fix them, once you know and have gone through it once.