Checkmarx One Reviews

We have integrated Checkmarx into all the company's development pipelines. We use it to scan more than 4,000 repositories and around 25,000 pipelines. 

The integration is particularly useful as it works directly with several common SCM solutions in the market, such as GitHub and Bitbucket, and with CI/CD tools like Jenkins and GoCD. This allows us to register repositories quickly and scan code efficiently in our development process.

Checkmarx helps developers improve the maturity of their coding practices and brings a security mindset to development teams, product managers, and business areas. 

It aids in identifying and mitigating vulnerabilities early in the development cycle, enhancing the overall security posture of the organization.

We use the solution to validate the source code and do SAST and security analysis. Checkmarx dynamics code analysis improved our software security posture by showcasing vulnerabilities within the code and identifying or providing recommendations on how to improve.

The solution's user interface could be improved because it seems outdated. The solution should integrate with AI and machine learning.

Whenever a web application needs to be moved into production, a static code analysis or source code review must be done. The analyst runs several tools on the web application and collects details. Completing a source code review for a particular application will take around five working days.

Since we moved to Checkmarx, it has reduced the time significantly. Usually, we get the report within a day. It lists all the critical vulnerabilities and provides remediation. We provide suggestions to the customers and the project owners to fix the loopholes immediately so that we can move to production. Sometimes, the life cycle is reduced from five days to one day.

Static code reviews are small projects. Previously, with a team of four analysts, we did two project reviews every month. Since we started using the solution, we could do four projects every week with the same team.

Our company uses the solution to check the vulnerabilities in our products at the build level. We capture, identify potential issues and fixes, and publish reports on a weekly basis. 

We work in the banking industry and have a license for 100 users.

The report function is the solution's greatest asset. We can configure reports in our build pipeline. We set them to publish scores and consolidate all the pod answers. We go through reports to understand issues and next steps. We get availability of code by clicking on that particular section. 

We are able to speed up services because the semi-application is done in the report.

The solution is very easy to navigate. 

When something happens in a test, then you need to know why. In many cases, you would have to run a scan and find all the problems, and then hand that off to development and have development go back and rewrite that code. If you had an issue with a particular aspect where you have a limited amount of personnel or knowledgeable personnel, based on the language that an application was written in, well, then you would need some type of assistance in order to rewrite that code in that particular language, with the limited knowledge that developer might have had. I assisted with that and helped with educating the developer on how to write that code. It was a two-pronged effort.

The number one use case would be a failed PEN test. Number two would be, "Hey, we have a waterfall DEV approach to our SDLC today. We want to become more agile around speed and quality of code." That would be the second. The third would be able to provide an appropriate availability of knowledge for training developers in secure coding.

Being able to have the breadth and depth of different kinds of support for different languages is excellent & many other solutions require you to compile the code prior to the scan, with CxSAST there is no need to compile code for a static analysis. If you didn't support a particular language that an application was written in, whether it was legacy code or a new agile code like Scala, JScript, PLSQL, or whatever, well, then you didn't get the business. If you were an organization that converted its SDLC from waterfall to agile, then you're going to need the ability to support multiple languages, even if they're not part of the company, thanks to that agility, that approach, that methodology. Supporting different languages was a high priority of the client.

The main thing we find valuable about Checkmarx is the ease of use. It's easy to initiate scans and triage defects.

As the solution becomes more complex and feature rich, it takes more time to debug and resolve problems. Feature-wise, we have no complaints, but Checkmarx becomes harder to maintain as the product becomes more complex. When I talk to support, it takes them longer to fix the problem than it used to.

We are currently using the solution for scanning code-level vulnerabilities. 

Checkmarx is more developer friendly. Developers are aware of how to use Checkmarx. It's not too complicated, and they can understand what the problem is in their code, and it helps them to write secure code. That's a big thing. It's not an obstacle for developers. They can easily write their code and make it more secure with Checkmarx. That's the main positive point.

One use case is when a development team finishes, or even in the middle of, development. They run Checkmarx, which shows potential vulnerabilities. If they don't understand something, they consult with me. 

I explain what Checkmarx is highlighting, why it's "shouting" as we say, the specific vulnerability, and the problem it found in the code. Then, together, we explore the code and decide if it's a valid issue requiring a fix. 

We also discuss how to fix it, or if it's a false positive because, in their environment, the problem either cannot exist or doesn't exist in the way they use their software.

We also have another use case. When a software company, like an integration company, does a project for us, we request them to run their code through Checkmarx. If they don't have their own tool, we run it on our Checkmarx and provide them with the report. We request, or rather insist, that they fix most, if not all, of the problems Checkmarx finds. 

These might be issues they didn't consider, but we put it in the contract that they have to submit their software to a "code check," meaning they can use Checkmarx or another approved tool. If they don't have a tool or refuse, then it's okay. The key is to have it in the contract and signed. 

Otherwise, fixing the software later becomes difficult, especially when the project is nearing completion. That's why we do it when the integration begins, so there's still time to address the issues. If you wait until the very end, it's too late.

The solution improved the efficiency of our code security reviews. It helps tremendously because it finds hundreds of potential problems sometimes. When the development teams fix them, or even some of them, it significantly enhances the security of the software. 

For example, we had a project, an outsourced one, that provided code written in PHP and included dozens of open-source utilities, libraries, and the like. Their server-side code was in PHP, and their client-side was in JavaScript. Both sides also used many libraries and utilities.

When we ran Checkmarx, it found numerous problems in both their code and the third-party software, including hundreds of high- and medium-severity issues in the PHP code. I didn't dig into the specifics; I just said, "Look, it found hundreds of high and medium problems. You need to reduce them. Before testing starts, you need to provide us the code again, and we'll run it again."

They started fixing it, and while I didn't follow up on the specific fixes, perhaps they removed some libraries. As long as the number of high and medium problems in the Checkmarx report decreased, it meant they were making progress. They hadn't finished yet, though.

After they fixed about half of the problems, we allowed them to start integration. However, they still need to fix the remaining issues, and hopefully, they will.