Checkmarx One Reviews

The primary use that we have for Checkmarx is the evaluation of source code vulnerabilities.

We use Git to connect to Checkmarx. We don't use GitHub. We use our own self-hosted Git. We're just using generic Git. One of the biggest thorns in our side is managing that aspect of it. It wouldn't matter if it was GitHub or Bitbucket or any of the other tools that you can use to connect Git to Checkmarx. The issue is the same. 

The tool is good at telling us what repository we're connected to, but it is horrible in telling us what branch we're connected to.

I haven't been monitoring how well our projects have been at reducing vulnerabilities. Checkmarx is one that you have to actively follow, and my position doesn't require that I do that. I set up the tool, and then I let other people use it.

I'm the system administrator of the tool rather than an active user of it. This product has room for improvement in administration.

Adding users is kind of a pain. We need a more automated way of adding users. User administration for the IDs can be improved, they can make it a more automated feature set so that you can add users more quickly and easily. 

Most tools that I'm dealing with today have a mechanism where people can self-enroll.

I'm more of the admin as opposed to a user of Checkmarx. Overall, the ability to find vulnerabilities in the code is better than the tool that we were using before.

One of the biggest heartaches that we have is that all of our Windows servers are on an automated upgrade. Whenever Windows upgrades, we lose the order of the ciphers and it brings down the Checkmarx webpage. 

Our company policy is that we upgrade our servers at a minimum of once a month, if not more. It's a hassle to keep up on that. The ciphers are such a pain to manage.

To set up a cipher connection, there's a tool out there called IIS Crypto. We just run that tool to set the best practices. It forces us to reboot the server. We haven't figured out how to automate the whole thing yet. 

There have been some Windows updates that haven't triggered this issue where the ciphers get messed up. The only thing we're running is TLS2. At that higher level, everything is just a pain.

All of our servers are built out through code. In other words, we use Ansible and Jenkins to automatically create machines. Everything is virtual these days. It's either virtual in-house or virtual in the cloud. 

The issue with Checkmarx is the next pain point, i.e. their installation procedure is GUI-based. They've got a command line for upgrades. I haven't seen the command line for the initial install.

My last statement on Checkmarx is Windows would not be my choice for any kind of server implementation. I'm not a Windows fan at all. Every other tool in our company is Linux-based and our target systems are Linux as well.

I don't have the experience and the knowledge of working on a Windows system compared to my Linux knowledge. Checkmarx being Windows only is a hindrance as well.

Another problem is: why can't I choose PostgreSQL? I would like to have an additional feature added to the product to support either PostgreSQL or MySQL. Those are the two free databases that are enterprise-ready.

Checkmarx is a stable product, especially based on the number of updates that we receive. Every time we get a new update or a hotfix, I'm very much in the loop on getting that information. Compared to some other products, it doesn't have the churn that others do, i.e. in the number of updates and patches that we have to apply to it.

We're licensed for 100 users. Primarily we use Checkmarx for developers, managers, architects, and maybe some of the design folk, but not QA. This would solely be in the realm of development and architecture. 

There is no plan for us to increase our usage of Checkmarx. We're trying to get as many scans as possible. One of the issues that we have is the concept of an incremental scan. The more of the incremental that you do, the slower the service becomes.

When you go in and you look at the last result: it's your baseline or your full scan, followed by applying each incremental. The more of the incrementals that you have, the slower Checkmarx gets.

They've come up with a recommendation for users to do one full scan a week and maybe six incremental scans. This needs to be worked on to get the performance better on this particular tool.

Checkmarx can scale up very easily. Anything that can be automated can be scaled. If I can automate it, I can scale it. Under the hood, it does the management of the scan engines well.

We have some large code bases, that according to the Checkmarx internal people, based on the number of lines of code, everything is 100% optimized hardware-wise. The fastest that the scan should take is 13 hours. That's a full scan, an incremental is a little different.

The problem with Checkmarx from that standpoint is, in our most active code base, we want it to be scanned frequently. At one point in time, it was taking up to 26 hours to do a single scan. We were scanning twice a week or four times a week. 

That same code base has two separate instances of itself. A long time ago they started as a common code base and then they split. Now, in essence, we have two products based on the same code base. We had to scan them twice a week.

The customer service on the phone so far with Checkmarx has been good. We've had more issues with other projects that have gone into the cloud than with this particular instance. 

It's mostly email until you scream enough with Checkmarx or you go through your salesperson. It's a little bit of a burden to get to them. 

For the most part, the people that I have dealt with know their stuff, and we haven't had any problems. It's been a challenge. We did try to do things that no one else had tried before according to them, and so we ended up having setbacks because of trying new things. 

The tool that we were using before was AppScan.

The initial setup of Checkmarx is straightforward. We did a bunch of things that shot ourselves in the foot that we weren't expecting. We were initially trying to put Checkmarx in the cloud. We were even putting Checkmarx into an Azure system until we found out that Azure, with the Microsoft SQL engine, does not support what Checkmarx requires. 

The Azure implementation of SQL does not allow the USE statement. Extremely odd. Maybe Microsoft figured out if you can't use USE, that means you have to have more databases and so they can charge more. Microsoft Oracle and IBM have been pulling that crap for years. They're making a lot of money.

It probably took us a couple of months to go through all of the issues, basically trying to find a home for SQL. We ended up creating a Microsoft SQL server in Amazon.

With Amazon's RDB, you can use Oracle, PostgreSQL, Sybase, Microsoft SQL, etc. as its RDB engines. Depending on whether you already have a license, or if you want to pay for the license when you set up the instance, you can do either. 

We had the license. We just created an instance in the Amazon cloud.

I've got 100 licenses for Checkmarx. As people come and go, it's a hassle to add and remove them. In this day and age, it's such a meaningless time-waster.

We were previously working with Azure. We switched because of their implementation of SQL Server. Checkmarx uses statements to move from database to database. Azure does not support that in its implementation at this time. 

Time will tell and Microsoft does improve their code over time.

From an administrative standpoint, I would rate Checkmarx with a five out of ten. From what my users are telling me, I'd give it an eight for the tool's ability to report on vulnerabilities in the user experience. 

I would rate Checkmarx with an eight on the user side and a five on the admin side.

Customers need to work with Checkmarx to scale the system for their needs, i.e. work with their recommendations. The best practices that they have there. 

They have this formula to calculate how many CPUs and how much memory you need. The memory requirements are huge. We've got 64 GB machines to scan them.

That's the low end of what they're recommending. Their processes do a lot of number crunching in memory. For a 4 million line code base, it's just going to consume a lot of time and a lot of resources. 

We are only using the source code scanner. We're not using the OSS scanner. We use Artifactory for our OSS repository, and Artifactory comes with its own built-in OSS scanner. We didn't need two OSS scanners.