Contrast Security Assess Reviews

We use the solution for application vulnerability scanning and pen-testing. We have a workflow where we use a Contrast agent and deploy it to apps from our development team. Contrast continuously monitors the apps.

When any development team comes to us and asks, "Hey, can you take care of the Assess, run a pen test and do vulnerability scanning for our application?" We have a workflow and deploy a Contrast agent to their app. Because Contrast continuously monitors the app, when we have notifications from Contrast and they go to the developers who are responsible for fixing that piece of the code. As soon as they see a notification, and especially when it's a higher, critical one, they go back into Contrast, look at how to fix it, and make changes to their code. It's quite easy to then go back to Contrast and say, "Hey, just consider this as fixed and if you see it come back again, report it to us." Since Contrast continuously looks at the app, if the finding doesn't come back in the next two days, then we say, "Yeah, that's fixed." It's been working out well in our model so far.

We have pre-production environments where dedicated developers look at it. We also have some of these solutions in production, so that way we can switch back.

It's hosted in their cloud and we just use it to aggregate all of our vulnerabilities there.

If an app team is going to deploy new features to prod, they put in a ticket saying, "We are including these features in our 2.0 release." The ticket comes to our team. We deploy Contrast Security and then we do a bunch of manual pen tests. During the time that we're doing manual pen tests, Contrast will have a bunch of additional findings because Contrast is sensor-based. It's an agent-based solution which continuously looks at traffic coming in and going out of the application. When my team does manual penetration tests, Contrast looks through those flows and that makes our coverage better. It goes hand-in-hand with our pen test team. When the manual pen-test team tests the application, Contrast is looking at that traffic. Another application, like a Qualys, doesn't go hand-in-hand with a manual pen test team. Contrast really helps us because it's more like another resource looking at traffic, and at logs. It's like a watchman looking at traffic going in and going out. I literally consider it as another resource looking at traffic, day in and day out.

Contrast has also reduced the number of false positives we have to deal with, by something like 10 to 20 percent over the 18-plus months that we've had it.

The solution is accurate 90 percent of the time. Most of the time, when Contrast has identified top vulnerabilities in the OWASP Top 10, our manual pen-test team has gone in and said, "Yes, for sure." There were times when, because of resourcing issues, we did not have people pen-testing and they would just say, "Okay, we'll see what Contrast says." And sure enough, Contrast would come back with 10 to 20 critical vulnerabilities. Then we would backtrack and have manual pen do some pen tests. They would come back and say, "Yes, it has literally identified most of them;" things like a SQL Injection, which is in the OWASP Top 10. So we've seen that happen in the past, and that's why I feel the accuracy of Contrast is pretty good.

The advantage of using Contrast is that it is continuous.

I've seen some of the development teams completely take up Contrast themselves and work in Contrast. For example, a developer will be notified of an issue and will fix the code. He will then go back to Contrast and mark it as remediated. Then, he will keep watching the portal. He will be notified if the same vulnerability is found. We have seen teams that completely like the information that Contrast provides and they work independently with Contrast, instead of having a security team guiding them and holding their hands. There are times when we do hold hands for some of the teams, but it really depends on the software developers' maturity and secure coding practices.

In addition, it definitely helps save us time and money by being able to fix software bugs earlier in the software development lifecycle. It really depends on where you put Contrast. If you put Contrast in your Dev environment, sure enough, as soon as the developer deploys his code and QA is testing it in that environment, it will immediately flag and say, for instance, "You're not using TLS 1.2." The developer will go back and make those changes. It really depends on what model you have and where you want to use Contrast to your advantage. A lot of teams put it in the development environment or a preparation environment and get to fixing vulnerabilities before something is released.

I've also seen the other side of the fence where people have deployed it in production. The vulnerabilities keep coming. Newer hacks develop over time. When teams put it in prod and an exploit happens, they can use Contrast Protect and block it on the other side. You can use it as you need to use it.

The time it saves us is on the order of one US-based FTE, a security person at an average pay level. At a bare minimum, Contrast helps us like that resource. It's like having a CISSP guy, in the US, on our payroll. That's how we quantify it in our team and how we did so in our project proposal.

The primary use case is application security testing, where we try to identify vulnerabilities within applications developed by our company.

Contrast a cloud-hosted solution. That's where most of the data and analysis takes place. It's also how most users interact with that data. Data is collected by agents that are deployed to servers within our environment. The agent component is internal to our organization, gathering data that is sent back to the cloud.

The way that it has improved our application security process is that we are no longer performing scans of specific environments to provide point-in-time vulnerability data. Instead, we're gathering vulnerability data from multiple environments in real time. That's a fundamental change in terms of how our program operates and how we identify vulnerabilities in applications. It gives us greater visibility and it gives us visibility much faster, while allowing us to identify issues throughout the environment, and not in just a single location.

Assess has also reduced the number of false positives we encounter. Because it is observing application traffic and it's not dependent on a response from a web server or other information, it tends to be more accurate.

Assess can identify vulnerabilities associated with application libraries where we would otherwise be dependent on other third-party solutions. It provides us visibility that we didn't have before, which is very helpful. This tends to be an area where our application owners are less focused. They're generally interested in whether or not their application has a vulnerability that is the result of code that they've written. They tend to ignore whether or not they've inherited a vulnerability from a library that they're using. Our ability to point out to them that they are using a vulnerable library is information they didn't have before.

It helps us save time and money by fixing software bugs earlier in the software development cycle, although that's difficult to quantify unless you have a metric for the resource impact of a vulnerable application, or an incident that occurs because an application was vulnerable. But we are certainly identifying vulnerabilities earlier in the process and feel that we are identifying vulnerabilities more accurately.

Up to this point, as an information security company, we had very limited visibility over the testing of the code. We have 25 Scrum teams working but we were only included in very specific projects where information security feedback was required and mandatory to be there. With the use of Contrast, including the evaluation we did, and the applications we have included in the system, we now have clear visibility of the code.

In our most critical applications, we have a deep dive in the code evaluation, which was something we usually did with periodic vulnerability assessments, code reviews, etc. Now, we have real time access to it. It's something that has greatly enhanced our code's quality. We have actually embedded a KPI in regards to the improvement of our code shell. For example, Contrast provides a baseline where libraries and the usability of the code are evaluated, and they produce a score. We always aim to improve that score. On a quarterly basis, we have added this to our KPIs.

We have a site that serves many different products. We have a sportsbook and casino, where a lot of casinos are using the provider's code. Our false positives are mainly due to points missing since we have not integrated the application on the provider's side. Therefore, a request that is not checked on our side is checked on their side, leading to gaps of knowledge which causes the false positive. 

In regards to the applications that have been onboarded fully, we have had very effective results. Everything that it has identified has given us value, either in fixing it or knowing what's there and avoiding doing it again on other parts of our code. It's been very effective and straightforward.

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.

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.

Assess handles our DST and ISD. Assess and Protect run on the same server and agents, but you activate different licenses for each component. 

Assess has brought our development time down because it helps create code the first time. Instead of going through the Jenkins process to build an application, they can see right off the bat that if there are errors in the code and fix them before it even goes to build.

Contrast Security Assess has a really good UI and gives the details in more depth. It gives more information about web application vulnerabilities. If third-party libraries, JS files, and JAR files have any CVEs in them, the solution reports that and gives a grade from A to E. It gives good information about vulnerabilities. It does the secure source code review, and the vulnerability it reports gives the file name and the line numbers indicating the issue and where it is.

When we access the application, it continuously monitors and detects vulnerabilities. Contrast Security Assess detects, even at runtime and in the code part, which file or line of code has the vulnerability.

We use the tool to evaluate our customer-facing apps. We analyze the request, identify the weak parts of the code, and remediate them. 

The product has helped us identify vulnerabilities.