Fortify Static Code Analyzer Reviews

Fortify Static Code Analyzer is used for scanning the container image, such as Kubernetes or Docker, and its main role is to do the static security analysis.

Fortify Static Code Analyzer tells us if there are any security leaks or not. If there are, then it's notifying us and does not allow us to pass the DevOps pipeline. If it is finds everything's perfect, as per our given guidelines, then it is allowing us to go ahead and start it, and we are able to deploy it. 

Fortify Static Code Analyzer is a good solution, but sometimes we receive false positives. If they could reduce the number of false positives it would be good.

The solution could be more user-friendly. You have the CLI for business people sometimes, we are not able to give a good overview. Generally, the business people you choose would want to see the dashboard.

I have used Fortify Static Code Analyzer within the last 12 months.

The stability of Fortify Static Code Analyzer.

Fortify Static Code Analyzer is scalable. However, they could improve. The time it takes to scale could improve. 

We have 30,000 employees in my company and 20 percent of the company is using the solution.

I rate the support for Fortify Static Code Analyzer a four out of five.

We have a team that did the implementation of the solution.

The price of Fortify Static Code Analyzer could be reduced.

We are looking for a different solution.

My advice for others is to look for other solutions before you choose  Fortify Static Code Analyzer.

I rate Fortify Static Code Analyzer an eight out of ten.

We usually run the product through the pipelines through GitLab, CICD, or Jenkins pipelines. I'm currently experimenting with AWS CodePipeline right now with integrating those types of tools into the pipeline.

We write software, and therefore, the most valuable aspect for us is basically the code analysis part. It's mostly used for the software that we actually write and we use it to identify whatever it is that we're looking for, whether it's the bugs or the technical data and so forth.

The setup is pretty easy.

The solution is pretty stable.

We use several other tools. We also use SonarQube. If one tool does not meet our requirements, I kind of implement another. We actually use SonarQube and Fortify together as the tools that we use to do the static code and dynamic testing, and also for security. You combine various tools in a pipeline to verify the code. Basically, it's not necessarily a standalone solution. You need to work with others to get what you need. 

It comes with a hefty licensing fee. We get around it by leveraging SonarQube, which is free. We're trying to get plugins now for SonarQube to match what Fortify could do. It would be ideal if it also had some sort of open-source version we could use.

I've been dealing with the solution for maybe almost two years or so.

The stability is good. I'm not running into anything that gives me a problem as far as my pipelines are concerned. I'm okay with it. I haven't really dug into a deep dive with it, however, for what I use it for, is sufficient, and I get the results that I'm looking for. 

I haven't really dealt with technical support. Anything that I can't solve, I can Google. Then there's also the exchange code area. Usually, you find your answers if somebody has run into something, or if I run into something. If I can't find any answers, I would of course reach out to support, however, so far, that hasn't been necessary.

We also use SonarQube in tandem with this product. SonarQube is primarily a static code analyzer, and then Fortify was made more for the security side. With the new plugins that go into SonarQube, it's trying to catch up with Fortify. I have the same from the opposite side, asFortify has a different use case that we use it for.

SonarQube is trying to be just as efficient as Fortify with what Fortify can do, via the extensions that you can put in. However, when you get that extension that matches Fortify, it's kind of like SonarQube becomes more of a paid product at that point, however, even then, it's not near the price point that Fortify is.

Everything is basically straightforward with the setups. Most of the static code is actually done by SonarQube, however, we run it through Fortify afterward. However, due to the large license fee, we need to find workarounds like this.

The licensing is extremely expensive.

I'm not sure which version of the solution we're using. I can't recall the exact version number off-hand. 

I deal with the dev-ops engineers. We usually go for items that are cost-effective. If you've got the money for the license, then it's definitely a good solution to have. We have it at a higher level platform, however, I only use it at a certain level for our development environment. 

I'd rate the solution at a nine out of ten. It's a great product, however, it's a bit expensive. 

I work for a company that implements these solutions for customers. So, we've got it everywhere. I've done implementations that are very simple and are developer workstation-based or security analyst desktop-based. We also have implementations all the way up through their big kahuna, which is decentralized and automated scanning.

Its flexibility is most valuable. It is such a flexible tool. It can be implemented in a number of ways. It can do anything you want it to do. It can be fully automated within a DevOps pipeline. It can also be used in an ad hoc, special test case scenario and anywhere in between.

I know the areas that they are trying to improve on. They've been getting feedback for several years. There are two main points. The first thing is keeping current with static code languages. I know it is difficult because code languages pop up all the time or there are new variants, but it is something that Fortify needs to put a better focus on. They need to keep current with their language support.

The second thing is a philosophical issue, and I don't know if they'll ever change it. They've done a decent job of putting tools in place to mitigate things, but static code analysis is inherently noisy. If you just take a tool out of the box and run a scan, you're going to get a lot of results back, and not all of those results are interesting or important, which is different for every organization. Currently, we get four to five errors on the side of tagging, and it notifies you of every tiny inconsistency. If the tool sees something that it doesn't know, it flags, which becomes work that has to be done afterward. Clients don't typically like it. There has got to be a way of prioritizing. There are a ton of filter options within Fortify, but the problem is that you've got to go through the crazy noisy scan once before you know which filters you need to put in place to get to the interesting stuff.

I keep hearing from their product team that they're working on a way to do container or docker scanning. That's a huge market mover. A lot of people are interested in that right now, and it is relevant. That is definitely something that I'd love to see in the next version or two.

I have been using this solution for ten years.

It is fairly stable. I haven't experienced any real catastrophic or fundamental flaws with it since version 19.10. This was the last one that had a real major flaw that needed hotfixes quickly.

It is super scalable. That's definitely a bright spot.

With a solution like this, the number of users varies so much. We typically try to build a program with a client where there is a small team operating the tool. They typically just automate it and plug it into their DevOps pipeline, but the entire development organization consumes the results and does the work. There is the infrastructure management side to keep the solution updated and make sure the infrastructure is running, and then there are security analysts who are tweaking the filters, writing custom rules, and doing this kind of stuff to further advance the program using the tool.

I started working with Fortify in 2011. In the last couple of years, we've branched out and started exploring other solutions, mostly because of our customers' requests. However, we're still not seeing the same level of advancement and ability with some of the other solutions.

We've gone down the route of evaluating Checkmarx and implementing Checkmarx with a few of our clients. It went okay, but it is not stellar. We're right in the midst of evaluating and onboarding the Synopsys toolset. I will have more input on that in about a month or so.

It can be very simple. It could be simple as a desktop installation or just a VM install. It could also be complicated if you're going for their full distributed scanning model, which is their scan central.

It has a couple of license models. The one that we use most frequently is called their flexible deployment. We use this one because it is flexible and based on the number of code-contributing developers in the organization. 

It includes almost everything in the Fortify suite for one developer price. It gives access to not just the secure code analyzer (SCA) but also to FSC, the secure code. It gives us accessibility to scan central, which is the decentralized scanning farm. It also gives us access to the software security center, which is the vulnerability management platform.

I would advise others to definitely do their homework in planning. It is not something where you just open the box and go. There needs to be some foresight, some planning, and a lot of input from various stakeholders. You got to talk to your infrastructure team and make sure that you have suitable hardware for this in order for it to perform at its peak.

I would rate Fortify Static Code Analyzer an eight out of ten.

We use the tool for web-based applications. 

Integrating the Fortify Static Code Analyzer into our software development lifecycle was straightforward. It highlights important information beyond just syntax errors. It identifies issues like password credentials and access keys embedded in the code.

I have integrated the solution with GitLab, Jira, and ITSM. 

The product shows false positives for Python applications. 

I haven't customized many rules, but some customizations that have been applied have been particularly useful in our pipeline. For instance, if our application is found to be very vulnerable, we don't proceed with deployment. We utilize static analysis, and the pipeline is halted until the vulnerabilities are addressed. Similarly, I've applied this approach in Fortify Static Code Analyzer and Checkmark SCA to stop the execution pipeline for highly vulnerable applications.

I utilize validation in the code to manage false positives in the results. In this case, the application helps identify false positives, and I spend extra time validating them. 

I would recommend Fortify Static Code Analyzer for .NET applications and not for Python ones. I rate it an eight out of ten. 

The solution has been quite stable over the years.

We've found the documentation to be very good.

When there are issues, there is a lot of explanation about what they are and how to solve problems. Communication is very clear. 

The pricing is a bit high. 

We have not enough for really sharing between with editor. Therefore, we have to use an older version of a product.

We've used the solution for 12 or so years at this point. It's been well over a decade. We've used it for quite a while.

The stability of the solution is pretty good. There are no bugs or glitches. It doesn't crash or freeze. It's pretty reliable. 

Technical support is good. When we put in requests, we get feedback and results. Older requests get treated with priority, and newer requests go into a queue. 

The pricing of the solution is a bit high. It would be nice if it was more competitive.

While we do want to continue to use the product, we want to negotiate with Microsoft about the licensing. in the meantime, we will likely evaluate a few other options.

We're just an end-user and a customer. We don't have a business relationship with Fortify.

We are not using the latest version of the solution right now. We're waiting for the Fortify version with PCI DSS 4.0.

I'd rate the solution at a six out of ten.