Contrast Security Assess Reviews

Contrast Security Assess is one of the first players in this market, so they have experience and customers, especially abroad. Overall, it's a good product. But, again, if you are commercially weak, you remain a single supplier. In any given market with only one supplier, the market cannot function. It is important to have competition, and one should gain market share through flexibility. It will be too late in two years, as many companies claim to be doing IAST. It's like selling there's no Desktop antivirus versus traditional antivirus. Everybody shall do signature-less virus detection. Otherwise, you're out of the market. This scenario is very similar here, especially in the forward applications.

The solution needs to improve flexibility and provide a complete ecosystem like its competitor named, Synopsys. An ecosystem could appeal to their large customers because they are looking for a complete solution, not just a best-in-class solution, but something which integrates into the rest of the development framework.

I have been using Contrast Security Assess since 2017.

It is a stable solution.

The scalability of the product is a problem in the solution, especially from a commercial perspective.

There must be an integration with the ecosystem and application development landscape. So once the solution is integrated with many tools, it is scalable. It's different from the product, which is scalable because the product is one of the steps within a complex process.

To complete the process, you must integrate the solution with other tools.

I have no direct experience with the initial setup, but I needed a couple of proofs of concept for comparing Contrast with one of its Spanish competitors.

The solution is expensive.

The IAST adoption in Italy, at least, is slow. My customers' feedback is that their commercial aptitude could be more flexible. It needs to be more flexible. They need to understand that they have an opportunity window that will last only a few years. And they are selling to win market share now, wherein in the next two years, everybody will be doing IAST. Whether it is good or bad, more or less, everybody will be doing that because the proposition is unbeatable.

I recommend others to try the solution because it is the most rewarding investment you can make in security access, apart from end-user training and user-awareness training.

But my bad side is that I think three, four years in advance. For example, I made a marketing campaign on VPNs in nineteen ninety-eight. Because VPNs were unbeatable, and it took another ten years before the market took off.

So I'm sure it will happen. Especially in the Italian market, there are market specifics because, in Italy, most of the development is outsourced, and very little development is done in-house.

So the big customers usually do not make the investment. The company which generates the code should be tailored to be bought by the leading company, which then uses the product to assess the work. Technology vendors usually focus on technology, and companies focus on organizational processes. So I was trying to sell outlets, which now are IBM source good edition, Upscaler. I was selling outlets to telecoms and proposing ounce levels as portfolio management. So that they have thousands of applications and you have a tool that assesses any given application's security. And the problem was that the guys in charge of the portfolio were not supposed to have access to the code.

So there was an additional problem stopping the customer from buying a perfect technological solution. They could manage the security, but the guys managing the application portfolio were not supposed to add access to the source code. And so they were not the proper organization for the thing to happen. And this is a problem which in large customers is quite frequent. But, again, you should see any market, a single customer, the needs, the processes, the power struggle, and data on a power struggle; it's more complicated though it can be done.

I would give Synopsys a nine because no one is at ten today.

I have ranked Contrast just below Synopsys because Synopsys has the size and the scope, and they have an internal vertically integrated solution apart from all the partnerships you could have. Since Contrast is a much smaller company, they should enter into some partnerships.

I rate the overall solution an eight out of ten.

A good use case is a development team with an established DevOps process. The Assess product natively integrates into developer workflows to deliver immediate results. Highly accurate vulnerability findings are available at the same time as functional /regression testing results. There is no wait for time-consuming static scans.

Assess works with several languages, including Java and .NET, which are common in enterprise environments, as well as Node.JS, Ruby and Python. 

Assess is valuable for several reasons, but time-saving factors are high on the list. Compared to a typical development environment with a SAST tool, Assess saves developer time and reduces the time-to-market. With Assess there is no waiting for a slow static scan to complete. Vulnerability findings are reported during testing and the reported findings are highly accurate, with very few false positives. Other SAST tools often emit a great number of false positives that must be investigated and resolved before the code can be released, consuming the time of developers and the security team chasing invalid vulnerability reports. Assess also provides clear and actionable guidance on how to fix each vulnerability, saving more time. 

Assess integrates with a many common tools to generate notifications and tickets, such as JIRA tickets. The result is that application security vulnerabilities can be handled by developers as just another type of bug found during testing. Application security becomes part of the development process rather than a step that is done “after” development. The temptation to skip the security testing step to meet a release deadline is eliminated.

The combination of real-time analysis and accurate vulnerability reports can really accelerate time-to-market. One large customer was even able to eliminate the human signoff before release to production. This customer had a solid DevOps process with automated application testing, but still had the security testing and review process delaying releases. With Assess in their pipeline they were able to automate the release decision. Apps that passed functional tests and reported only vulnerabilities below a certain criticality threshold would be automatically released directly to production.

Contrast is good at listening to its customers and setting product directions based on their feedback. Contrast continues to improve along multiple axes. One axis is languages and platforms. Support for Python was recently added and Go is in beta.

Another axis is the deployment and configuration of agents. Contrast offers a lot of flexibility in agent management but is working on enhancements to improve centralized control.

I've used this product for about three years.

Operational stability of the platform has been excellent.

The Assess agent is designed to run with the app in a preproduction environment. The agent monitors the operation of the application to which it is bound. This monitoring of course uses some processing resources and time, but the impact is usually not detectable by a human user of a web app. The additional processing might impact a loaded production system, so Contrast recommends that the Assess agent not be used in production.

However, some customers deploy Assess in production occasionally because they view the live production traffic as a source of additional test activity.

Contrast is a well-designed SaaS platform and scales well. There are no practical limits on the number of users or apps. 

The technical support is excellent, with a knowledgeable team and access to the necessary resources. 

The agent installation is straightforward. Typically, for an initial user (developer) and application, Customer Success or Professional Services can just walk them through the setup over the phone. The dashboard requires no installation (SaaS), so the developer can exercise the app + agent and see vulnerabilities immediately.

Some deployments are more complex, but deployment complexity generally reflects the complexity of the customer and their overall situation. A large customer may have many business units, app teams, apps, and languages, requiring some planning. 

Start with a small app team initially, before scheduling a larger rollout. Teams that have been using SAST tools find that using Assess changes how they think about appSec in their development workflow and helps them identify process modifications that maximize the value of the tool.

Overall, on a scale from one to ten, I would give this solution a rating of ten. The product is strong and improving, support is responsive and effective, and supported integrations work for many customers.

We've been using Contrast Security Assess for our applications that are under more of an Agile development methodology, those that need to deliver on faster timelines.

The solution itself is inherently a cloud-based solution. The TeamServer aspect, the consolidated portal, is hosted by the vendor and we have the actual Assess agent deployed in our own application environments on-prem.

We've historically run dynamic and static scans for all of our applications, but for these teams that need to deploy on a much faster basis, we prefer using Contrast because there are no point-in-time scans required. There isn't a lot of triage required when it comes to reviewing the results. Everything is instant and requires little bottleneck from the security-team side, and the developers can continue on with their development and testing without us.

We have a very large backlog at the moment for DAST scan requests, from our application teams. That backlog has grown so much that some of the teams have missed their initial deployment timelines because they're waiting on us to become available to run dynamic scans. Now, with teams that have Contrast, they're not seeing any delays in their deployment process because they're not waiting on us to complete the scans on their behalf. The vulnerabilities are being automatically identified using the tool.

The most valuable feature is the continuous monitoring aspect: the fact that we don't have to wait for scans to complete for the tool to identify vulnerabilities. They're automatically identified through developers' business-as-usual processes.

The automation of the actual vulnerability identification is great. I would give it a very high rating, given that it requires little of the security team or developers to understand and start reviewing the results that are identified.

The false positive rate is another good feature. It has a very low false positive rate. That means my team, the security team, has to spend less time looking at results and findings, compared to historical, static and dynamic scans where the false positive rate is much higher. From a percentage perspective, somewhere around 90 percent of the time we used to spend has been given back to our team, because the false positive rate with Contrast is less than 5 percent.

In terms of the accuracy of vulnerability identification, so far we've had tens of thousands of issues identified in applications that have historically been scanned by dynamic and static scanning. So far, the large majority of those findings have been true positive. I may have seen just a handful, five or 10, false positives so far, in the scope of tens of thousands. That's a very low rate.

We also use the solution's OSS feature through which we can look at third-party open source software libraries. It is a great tool. We've never had a solution for software composition analysis. It has affected our software development greatly. Since we've never really had a solution for doing software composition, nor have we required fixes for vulnerable third-party libraries, this has changed the way that developers are looking at usage of third-party libraries, upfront. It's changing our model of development and our culture of development to ensure that there is more thought being put into the usage of third-party libraries.

The solution is definitely helping developers incorporate security elements while they are writing code. Since we're able to install Assess in Development and QA and all the pre-production environments, developers can start making use of the tool as soon as they have a deployed version of their products. As they code new features and test those out in their development environment, Contrast is already going to be automatically identifying things at that point. We are identifying issues much earlier in the software development life cycle, which makes it much less costly for developers to fix those findings.

We're saving time and money by fixing software bugs earlier in the software development life cycle. We're saving time on the developers' side, as well as on the security auditors' side.

Regarding the solution's OSS feature, the one drawback that we do have is that it does not have client-side support. We'll be missing identification of libraries like jQuery or JavaScript, and such, that are client-side.

The same thing is true on the custom code side: the client-side technology support. Although client-side technologies are inherently less risky than server-side technologies, which is where Contrast focuses testing, it would definitely help for this tool to identify both the server-side and client-side findings in libraries, as well as custom code. This would help us move away from using multiple tools. For example, if we have Contrast for our server-side testing, we still need to use some sort of static scanning sensor for the client-side. In a perfect world, it would just be Contrast Assess doing both of those.

I have been using Contrast Security Assess for five months.

So far, the stability has been good. We've only had two applications where performance was affected by the agent. For the hundreds of other agents we've deployed thus far, there's been no impact.

Scalability ties back to automation. It's very tough to scale this from an automated perspective, so we've just been doing manual installs from the beginning. If there were an easier way, a way to automate the deployment of the solution, that would be one of our hopes for the product roadmap.

On a scale from one to five, Contrast technical support is about a four. I haven't had too many support issues just yet, but in each one that I have had, they have been very quick to respond; within hours as opposed to days. I haven't rated it a five just because I haven't had enough support requests to see if they are any different than other software vendors out there.

We did not use something else specifically for interactive app testing or software composition. We've only had tools for static and dynamic testing.

Our decision to go with Contrast dates back to the whole issue of our application teams that need faster results and fewer bottlenecks. We use Fortify for static and dynamic scanning, and that creates a lot of time delays, either waiting for a scan or waiting for review of the scan results to be completed. Whereas with Contrast, there are no delays. The teams that are more Agile and deploying much more often require that feature.

The setup of the solution is different for each application. That's the one thing that has been a challenge for us. The deployment itself is simple, but it's tough to automate because each application is different, so each installation process for Contrast is different. But manually installing the tool or deploying it is very simple.

The setup of the Contrast Assess agent is quite simple. Not much time is needed upfront to get this working and, thereafter, ongoing maintenance is very trivial for Assess.

We're still deploying. We have thousands of applications and thousands of teams around the world that we're deploying to. But if we're talking about just one application, at most it would take one to two hours.

The implementation strategy is that we are deploying it firm-wide within our organization to at least make use of the software composition analysis, because that is a part of the agent that is a free feature. At that point, once we have the agent deployed, that's when we would start working with application teams to give them an understanding of the findings that are being identified, just for software composition analysis. In the meanwhile, the interactive application security testing feature of the same agent is working in the background. So as teams are seeing custom code vulnerabilities being identified as well, we're working with those teams to apply licenses as needed. 

From the deployment perspective, we're focusing holistically on deploying the agent for software composition, and then thereafter, making more risk-based decisions on which teams or applications would use a license for interactive testing.

The adoption rate will be 100 percent because we're deploying all of these agents to all of our application servers out there. For now, we're at about 30 percent. We have a little over 100 users, currently. They range from application security testers and managers, like myself, to product managers who are worried about the business-side of getting the application deployed. And then there are the development teams and build-engineers who comprise those teams. Each application team maintains its own instance.

We're working with Contrast. They've provided a very helpful technical solution architect who has been helping with the deployment.

From a security team perspective, we're able to free up a lot more time. We spend less time reviewing results and can spend our time elsewhere. Developers have the same thing. They can spend more of their time working on actionable results rather than looking at false positives and waiting for the security team to complete testing on their behalf.

The good news is that the agent itself comes in two different forms: the unlicensed form and the licensed form. 

Unlicensed gives use of that software composition analysis for free. Thereafter, if you apply a license to that same agent, that's when the instrumentation takes hold. So one of my suggestions is to do what we're doing: Deploy the agent to as many applications as possible, with just the SCA feature turned on with no license applied, and then you can be more choosy and pick which teams will get the license applied. Thankfully, it's always going to be working. You just won't be able to see the IAST results without applying that license.

There are no fees apart from the licensing fee. Some teams might run into issues where they need to spend more money on their servers and increase memory to support the Contrast Assess agent running while the application is running, but that is a small amount.

We did not evaluate other options. We met with Contrast and they were the leader in the space for instrumentation, so we went forward with them.

Make sure you understand your environment before deploying. Try to get an idea of what technologies are in use by applications so you can group them and group the deployment and the implementation. That way you can focus on automating .NET deployments, for example, first, and then move on to Java, etc.

The biggest lesson I have learned from using this solution is that there is a tool out there that is really changing the way that we are running security testing. In the security realm we're used to the static and dynamic testing approaches. Contrast Assess, as well as some other tools out there, has this new feature of interactive application security testing that really is the future for developer-driven security, rather than injecting security auditors as bottlenecks into the software development life cycle.

I would rate Contrast Security at eight out of 10, and that is because of that the lack of client-side support and the troubles in automating the deployment holistically across an organization.

The product scans runtime and that is our main use case. We have deployed it for one application in our testing environment, and for the other one on in our Dev environment. Whatever routes are exercised with those environments are being scanned by Contrast.

It has helped us to improve the overall security posture of the company. We are able to address the findings before they have been reported by a third-party. It helps to identify things before someone else reports them or they have been widely exposed. It definitely improves the security posture of our applications, as a whole. It also improves our own security processes within the company, the way we catch the findings and resolve them. It has also helped us to gain our customers' trust.

Contrast helps save time and money by fixing software bugs earlier in the software development life cycle. We have installed the app in our Dev environment, so it's way before anything goes into production. It helps us shift left in our SDLC and it definitely helps us fix findings before the code is pushed to production.

The tool has good, strong findings. We have other static analysis tools, but Contrast has found high-priority issues which other tools have not found. The capability of the tool to scan and throw errors that other tools don't catch is important.

No other tool does the runtime scanning like Contrast does. Other static analysis tools do static scanning, but Contrast is runtime analysis, when the routes are exercised. That's when the scan happens. This is a tool that has a very unique capability compared to other tools. That's what I like most about Contrast, that it's runtime.

There is also a feature in the tool where you can actually specify that this or that is not a problem and mark it as false positive, and it doesn't show up again on your dashboard. It's pretty easy. You can filter out your false positives and be good to go. We have seen a reduction in the number of false positives because, once you mark something as a false positive, that particular one doesn't show up.

I would like to see them come up with more scanning rules. I don't know how it was done within the tool, but there is always room for improvement.

We recently had a call with the vendor. We were talking about a finding where it combined all of the instances of the finding into one. Whenever a new instance shows up that finding is being reported again. We want it to work so that once we mark it as "not a problem" the new one will be reported as a new finding, rather than an old finding popping up as a new instance.

I have been using Contrast Security Assess for about eight or nine months. I joined my current company last September and I've been using it since then. In our company we have applications to work on, as subject matter experts for security. I have onboarded my applications into Contrast. After onboarding, I scan and tune the scan, and then list the non-true positives and false positives. I work with governing team to fix the issues. 

It's been stable. It hasn't gone down from the time we installed it on our cloud. The scans are running every day. We have very great support from the Contrast team so they would be able to help us if we were stuck anywhere.

It's easily scalable. We are planning to spread it to other teams and we are planning on one more application from within our team. It's just a matter of installing it on the proper cloud and it's good to go. It's easy to configure and you just have to decide which environment you want it on and make a few configuration changes.

In our company, it's mainly security who maintains and uses the tool. We haven't onboarded any of the developers or security champions within the company because we just started with it and we want to get to know the tool entirely. Then we can pass it on to other people in the company. For now, we, as the security team, are using it. Our team has 10 to 11 people. There are a few people from the DevOps team who have access to it to do the configuration stuff, and that team is another four or five people.

Contrast's tech support is very helpful. They answer our questions and address our concerns. It's been easy and smooth with them.

We did not have a previous solution. Contrast is a one-of-a-kind tool. It does runtime scanning so this is the only runtime scanning tool we have had.

Before me, one of my teammates was working on a different application and he was the first person to use Contrast. Then we bought three licenses. There is one more person who used it before me, for a different application. We have had good findings there as well. I have put to use the second license and we have one more license to use. We have identified an application to onboard, and we have also spread the word to different teams within the company and they're working closely with the Contrast team to use it in a different way. We are using the cloud version and they're still deciding on how to use it. We are just starting with Contrast but use of it is expanding within our company.

By "application" I mean monolithic, big applications. We currently have two such applications in Contrast and we will be working on the third one. We are looking to do more.

The setup wasn't complex. It was pretty simple. We worked with an internal team that deals with the firewalls, because that's how it has to be configured. Because it was new to us, it took time for us to understand. But otherwise, it was smooth and we were able to configure it pretty quickly. Everything together took under three months. It might have taken less time but it was during the December/January time frame so we weren't available and people from other teams weren't available.

We have an internal process where we connect with other stakeholders to come up with a plan. We worked with a different team to be able to configure it and to be able to run a scan. We also worked closely with them for key rotation and other maintenance stuff connected to the tool. We have a lot of processes internally on how to manage the tool and how to maintain the tool and to make sure it's running scans continuously and that the key rotation is done. We have our own internal processes and our own strategy to maintain it and manage the program.

There is also regular maintenance from Contrast, making sure that it doesn't go down.

We have definitely seen ROI. We have been able to onboard our applications and scan them. The scan is happening continuously, every day, and it does report new findings. We have been able to triage them and fix them, address the defects of the software, even before they were posted to Prod. This will help reduce our attack surface and make our products more secure.

You only get one license for an application. Ours are very big, monolithic applications with millions of lines of code. We were able to apply one license to one monolithic application, which is great. We are happy with the licensing. Pricing-wise, they are industry-standard, which is fine.

There were other companies that the people involved in evaluations were looking at, but I was not involved in that process.

It depends on the company, but if you want to manage and maintain and onboard, I would recommend having Contrast as part of your toolkit. It is definitely helpful. My advice would be to install it on the environment in which there are more routes exercised, whether it is the testing environment or Dev, to get most out of the tool.

In terms of configuration, we have Contrast on one of the applications in our testing environment and we have the other in the Dev environment. To decide on that took us some time because we didn't have access to all the environments of a single application.

Findings-wise, Contrast is pretty good. It's up to the app engineer to identify whether a finding is due to the functionality of the application or it really is a finding.

Contrast does report some false positives, but there are some useful findings as well from the tool. It cannot give you only true positives, so it's up to humans to make out which ones are true which ones are false. Applications do behave in different ways, and the tool might not understand that. But there are definitely a few findings which have been helpful. It's a good tool. Every other tool also has false positives and it's better than some other tools.

We are not actively using the solution's OSS feature, through which you can look at third-party open source software libraries, because we have other tools internally for third-party library scanning.

It's been a good journey so far.

It is used primarily to help put a layer of security around some of our legacy applications that were built quite some time ago. It's also used to provide better quality assessments on the vulnerabilities of some of these applications, compared to some of the other tools that we've been using.

We're using the SaaS platform.

The solution’s OSS feature, through which we can look at third-party open-source software libraries, give us better visibility into such libraries compared to any other tool on the market, because this is the only tool that I'm aware of that offers that capability. It's not affecting our software development a whole lot because we're not holding developers accountable to that level of metrics, but it's valuable insight to have.

In a way, Assess helps developers incorporate security elements while they are writing code. Not while they're actually writing it, but certainly while they're fixing it, because it provides really impactful feedback on how to go back and fix that code, and the best practices on how to fix it.

It also saves time and money by helping us fix software bugs earlier in the software development life cycle. The enterprise that I'm with has not, historically, prioritized any kind of security remediation at all. It considers all of it to be in a context they call "technical debt." This solution allows the organization to prioritize how to best use the labor hours allocated for technical debt. The savings are an intuitive inference to make in this case. I'm personally seeing that it's easier to get things remediated, versus where they weren't being remediated at all because the quality of the results from those other tools was just terrible. Now that I'm seeing that action being taken on them, it's very rewarding. I can nearly guarantee that we've saved time and money. I just don't know exactly how much.

The most valuable feature is the IAST part. Institutionally, we're not quite at the point of using Contrast for the Protect functionality because we have other tools that overlap with the web application firewall component of it. But for the Assess component, there's a direct correlation to other tools that we've used and the failures of those tools. Contrast, in terms of providing that vulnerability assessment, it provides an immediate benefit there.

The effectiveness of the solution’s automation via its instrumentation methodology is a solid eight out of 10.

The accuracy of the solution in identifying vulnerabilities is better than any other product we've used, far and away. In our internal comparisons among different tools, Contrast consistently finds more impactful vulnerabilities, and also identifies vulnerabilities that are nearly guaranteed to be there, meaning that the chance of false positives is very low. The number of false positives from this product is much lower compared to competing tools that we use right now: WebInspect and AppScan. It reduces the number of false positives we encounter by more than 50 percent.

The effectiveness of the solution’s automation via its instrumentation methodology is good, although it still has a lot of room for growth. The documentation, for example, is not quite up to snuff. There are still a lot of plugins and integrations that are coming out from Contrast to help it along the way. It's really geared more for smaller companies, whereas I'm contracting for a very large organization. Any application's ability to be turnkey is probably the one thing that will set it apart, and Contrast isn't quite to the point where it's turnkey.

Also, Contrast's ability to support upgrades on the actual agents that get deployed is limited. Our environment is pretty much entirely Java. There are no updates associated with that. You have to actually download a new version of the .jar file and push that out to the servers where your app is hosted. That can be quite cumbersome from a change-management perspective.

I've been using Contrast Security Assess since October of last year, making it about nine months.

Overall, the stability is quite good. 

We've had a couple of support-related problems. Contrast is funny because there are many aspects of it that they don't support. For instance, we have ColdFusion applications and, on paper, Contrast did not support ColdFusion. However, it will still work with ColdFusion, kind of. But it has caused some problems as it comes to isolating troubleshooting issues that occur. It's left us in a position where we have to make generalized assumptions about what can and can't be supported. So, out-of-the-box, we've made the decision not to try to support ColdFusion because of the issues that that can pose for us.

The scalability ties back to something I said before about change management. So far, we haven't seen anything that would prevent us from scaling upwards significantly. However, it requires the organization to have a pretty robust way of handling the changes for Contrast: for instance, the updates of the application itself. Because those updates aren't bundled into Contrast, it behooves the organization that's deploying Contrast to ensure it has a very robust change-management strategy to work with the product.

Out of our perimeter applications, we've got about 20 apps onboarded. Those applications that it has been deployed to are key applications, including key revenue-driving applications, but it's still being used only in a minority of our applications at the moment. Our adoption rate is around 10 percent. We have plans to increase usage of Contrast Security. We have hundreds of applications. Out of our customer-focused applications that are on the perimeter — we have over 200 of them — Contrast is deployed to about 20 of them.

We have about 130 users registered to use the product. The majority, about 80 percent, are developers, while about 10 percent are security personnel, and 10 percent are managers. We have a dedicated staff for maintaining the solution. That's the staff that I'm part of right now.

Their level of support and troubleshooting for the product is limited because of how they handle troubleshooting. It's done through a log file that's very cumbersome to work with.

Their technical support staff is very responsive. Personally, I've put in about 60 support tickets with Contrast. Some of the support tickets have ended up being actual changes to the product itself. Overall, I'm pretty pleased with that. But they're definitely still growing. They're a small company that is on the verge of growing into a very big company. I can tell from the quality of support I'm getting that they're struggling to keep up with that demand.

We use WebInspect and AppScan. We're evaluating the possibility of switching from them to Contrast, but right now Contrast is still in trial. We're not quite at that point in making a decision to drop one of those other tools yet.

The initial setup is straightforward. The version we're using is built for Java, and the setup procedure involves you associating the Contrast .jar file with the JVM arguments of the app server itself. The instructions on that are relatively clear and they've broken those instructions out per container platform that the JVM can run in. It's as clear as it can be for that product.

We're still deploying. We have many apps and there's an onboarding process associated with it. But on a per-app basis, it can take us less than an hour. For a larger app, in a clustered environment, it might take closer to a week.

Because we have a very large organization, we have a different team per application. We have an onboarding process where we work with an application team to onboard the Contrast product into their workflow, and then follow up with them to ensure that they're using it correctly. It's a multi-stage approach on a per-app basis.

We've mostly done it ourselves, although we have Contrast Security Professional Services on staff to assist with harder problems, and to follow up directly with our development teams. We've been happy with Professional Services.

We have seen ROI, but I can't get into specific numbers because those are sensitive to the organization. But some of these applications are key revenue drivers. Contrast's ability to help secure them, even if it is just those applications, gives us a little confidence that they are being looked at in terms of security. That is always going to be a significant return on investment, compared to the other tools that, frankly, weren't driving the progress necessary to secure those applications.

If you know your needs upfront, and if you're more concerned about vulnerabilities and you already have a web application firewall that you're happy with, then focus on the Assess component of it, because the Assess component has a very straightforward licensing strategy.

If you need the web application firewall and you have a highly clustered environment, then you will be paying that license cost per server. Unfortunately, that does not scale as well for us. It helps to understand what your use case is upfront and apply that with Contrast, knowing whether or not you need it per application or per server.

We have not evaluated other IAST platforms.

Make sure that you have a very good change-management strategy in place ahead of time. 

Also, it's not enough to have the solution itself. It still requires proactive management on behalf of your developers to make sure they understand what the product is offering and that they are using the product in a way that will benefit them.