What needs improvement with Micro Focus Fortify on Demand?

They could provide features for artificial intelligence similar to other vendors like OpenText products.

It would be highly beneficial if Fortify on Demand incorporated runtime analysis, similar to how Contrast Security utilizes agents for proactive application security. This could enhance the solution significantly. Moreover, considering the evolving threat landscape and the inevitability of zero-day vulnerabilities, implementing mechanisms like heuristic approaches would be advantageous. By incorporating heuristic algorithms or leveraging artificial intelligence, especially in the form of behavioral analysis akin to network security practices, Fortify could evolve into a more resilient solution. This could involve heuristic analysis for source code, the introduction of AI-driven processes for enhanced security, and the identification of security hotspots.

The products must provide better integration with build tools. In SonarQube scans, the pull requests are decorated. I don't know if it is a missing integration or a limitation, but I don't see the same feature in Fortify. The developer must be able to see whether the build has failed. I would like the pull request to be decorated like SonarQube. It's just not the same experience with Fortify. I have a problem with the Java version because our projects now use OpenJDK 7 or 17, but the scan still requires JDK 1.8. It is a problem for me, and I don't know how to change it.

Temenos's (T-24) info basic is a separate programming interface, and such proprietary platforms and programming interfaces were not easily supported by the out-of-the-box versions of Fortify. Although Fortify already supports around 25 programming languages, during our evaluation, we found it lacking in terms of support. So Fortify on Demand doesn't support all programming languages. Additionally, automating everything from the pipeline, which means the build will stop if any single vulnerability is found by their particular tool during the scan.

We need something that's going to be fully integrated with CIT processes from setting up a new microservice to scanning and managing other vulnerabilities. As of now, we don't have that which makes it a painful process.

Overall, it's very good. They have very good support, but there is always room for improvement.

I would like the solution to add AI support.

Micro Focus is a bit heavy on resources and uses up a lot of my RAM. My machine tends to slow down when I use it. A beneficial additional feature would be scanning executable files. Currently, it scans the uncompiled code only. I'd also like to see support for additional languages and support for scanning libraries whether they're outdated or not. The solution scans for security vulnerabilities but not for outdated versions or policy violations.

An improvement would be the ability to get vulnerabilities flowing automatically into another system.

Micro Focus Fortify on Demand can improve by having more graphs. For example, to show the improvement of the level of security.

Fortify on Demand could be improved with support in Russia.

Micro Focus Fortify on Demand could improve the reports. They could benefit from being more user-friendly and intuitive.

We have some stability issues, but they are minimal.

The UI could be better. Fortify should also suggest new packages in the product that can be upgraded. Currently, it shows that, but it's not visible enough. In future versions, I would like more insights about the types of vulnerabilities and the pages associated with the exact CVE. That will help us understand what's affecting the CVE. Initially, it's about finding the safer package version. Fortify should automatically recommend the safest version, so we can go to the vendor and request that. Once we identify the vulnerability, we can implement a remediation plan.

There are lots of limitations with code technology. It cannot scan .net properly either.

I would like to see improvement in CI integration and integration with GitLab or Jenkins. It needs to be more simple.

It could have a little bit more streamlined installation procedure. Based on the things that I've done, it could also be a bit more automated. It is kind of taking a bunch of different scanners, and SSC is just kind of managing the results. The scanning doesn't really seem to be fully integrated into the SSC platform. More automation and any kind of integration in the SSC platform would definitely be good. There could be a way to initiate scans from SSC and more functionality on the server-side to initiate desk scans if it is not already available.

Micro Focus Fortify on Demand could improve the user interface by making it more user-friendly.

In terms of what could be improved, we need more strategic analysis reports, not just for one specific application, but for the whole enterprise. In the next release, we need more reports and more analytic views for all the applications. There is no enterprise view in Fortify. I would like enterprise views and reports.

Micro Focus Fortify on Demand cannot be run from a Linux Agent. When we are coding the endpoint it will not work, we have to use Windows Agent. This is something they could improve. Currently, when we are running a security scan or Azure DevOps pipeline Micro Focus Fortify on Demand will give an overall status. People have to click on the link to read the in-depth results. If there could be some output of the report that can be passed in the pipeline and based on that we can control the next step of the pipeline. For example, if Micro Focus Fortify on Demand is saying the report is critical, do not go any further. If we can have that critical variable as a pipeline output that can be used later it would be really helpful.

It does scanning for all virtual machines and other things, but it doesn't do the scanning for containers. It currently lacks the ability to do the scanning on containers. We're asking their product management team to expand this capability to containers. It doesn't do software composition analysis. We've asked their product management team to look into that as well. We want a user-based control and role-based access for developers. We want to give limited access to developers so that it only pertains to the code that they write and scanning of the codes for any vulnerabilities as they're progressing with writing the code. As of now, the interface to give restricted access to the developers is not the best. It gives them more access than what is basically required, but we don't want over-provisioning and over-access.

We typically do our bulk uploads of our scans with some automation at the end of the development cycle but the scanning can take a lot of time. If you were doing all of it at regular intervals it would still consume a lot of time. This could procedure could improve. We are receiving false positives. We then have to repeat the scan even though it is a false positive and tell it to ignore some of those issues. Some of the false positives could be a design issue which we will know, but they keep coming up on the report. I have found the processes a bit cumbersome for the developers.

I would like to see easier integration to CI/CD pipelines. The reporting format could be more user friendly so that it is easy to read.

There's a bit of a learning curve. Our development team is struggling with following the rules and following the new processes. The initial setup is a bit complex. We could have more detailed documentation. They could offer some quick start or some extra guidance regarding the implementation. I'd like to see more interactive application security And more IDE integration and integration with VS Code and Eclipse. I would like to see more features of this kind.

During development, when our developer makes changes to their code, they typically use GitHub or GitLab to track those changes. However, proper integration between Fortify on Demand and GitHub and GitLab is not there yet. Improved integration would be very valuable to us. Similarly, I would love to see some kind of tracing solution for use in stress testing. So when we stress the application on a certain page or on a certain platform, we would be able to see a complete stress test report which could quickly tell us about weak points or failures in the application. Further potential for improvement is that, when we deploy our Java WAR files for review in the QA area, we want to be able to create a report in Fortify on Demand right from within this deployment stage. So it might inspect or check the solution's Java WAR package directly and come up with a report in this crucial phase of QA.

They have a release coming out, which is full of new features. Based on their roadmap, there's nothing that I would suggest for them to put in it that they haven't already suggested. However, I am a customer, so I always think the pricing is something that could be improved. I am working with them on that, and they're very flexible. They work with their customers and kind of tailor the product to the customer's needs. So far, I am very happy with what they're able to provide. Their subscriptions could use a little bit of a reworking, but that would be about it.

Reporting could be improved. It would nice to export to an Excel sheet or another spreadsheet. At the moment, my only option is a PDF. Micro Focus Fortify on Demand is tailored towards more web application APIs, and I would like to see mobile applications added to the next release.

It natively supports only a few languages. They can include support for more native languages. The response time from the support team can also be improved. They can maybe include video tutorials explaining the remediation process. The remediation process is sometimes not that clear. It would be helpful to have videos. Sometimes, the solution that the tool gives in the GUI is not straightforward to understand for the developer. At present, for any such issues, you have to create a ticket for the support team and request help from the support team.

In terms of communication, they can integrate a few more third-party tools. It would be great if we can have more options for microservice communication. They can also improve the securability a bit more because security is one of the biggest aspects these days when you are using the cloud. Some more security features would be really helpful.

The thing that could be improved is reducing the cost of usage and including some of the most pricey features, such as dynamic analysis and that sort of functionality, which makes the difference between different types of tools.

This solution would be improved if the code-quality perspective were added to it, on top of the security aspect. It would rate performance and other things. This is one of the reasons that people are interested in SonarQube. This would make it a more complete and unique platform that would be a great player in the industry.

This solution cannot do dynamic application security testing. It needs to be able to simulate a situation where a hacker is trying to break into the system. The vulnerability analysis does not always provide guidelines for what the developer should do in order to correct the problem, which means that the code has to be manually inspected and understood. Adding more information to provide a better analysis would be an improvement. This solution would benefit from having more customization available for the reports.

Strictly in terms of this product, I think it is a top-notch solution and I think the technology is still the best on the market. What might be improved is maybe just look at the pricing. It is a bit confusing compared to other products that we also sell. Whatever innovation they can come up with would be an excellent addition if it adds useful functionality. The only thing I can think of that they might add is something like features you can find in Codebashing that they have not yet implemented. I don't know if it has all of those features. If not, it would be useful for something like that to be added.

The solution has some problems with latency. Sometimes it takes a while to respond. This issue should be addressed. They should improve the data path where the issue has been flagged. They can improve the flow module details. If you can understand from the data flow or data path what is happening, you can better understand what the issue is.

The reporting capabilities need improvement, as there are some features that we would like to have but are not available at the moment. It needs a better configuration and more options for reports.

Primarily for a complex, advanced website, they don't really understand some of the functionalities. So for instance, they could tell us that there is a vulnerability because somebody could possibly do something, but they don't really understand the code to realize that we actually negate that vulnerability through some other mechanism in the program. And they try to look at it saying, "Okay. From a pure standards perspective, this is a critical vulnerability for you." Which in reality, if you would really try to exploit it, you'd see that we actually did cross a little something around it, and the vulnerability is not there. So they would expect to have a certain type of a formatting requirement around a specific field to avoid being able to put in special characters. They would assume that because we don't have that, it's a vulnerability. But in reality, you actually do have a custom function that has been defined somewhere else in the code and these fields are subject to that function. I don't carry along with that in the same way as the application really does. That's something that we found that needs improvement. We're actually going to transfer from them, and the main reason is that there is nobody home. We could have tickets open with them for months trying to escalate and have them remediate certain false positives as I described. We have had no success bringing this product to a level that we feel there's not too much noise. It gives you specifically what you need. You could take it at face value and run with it. We're going to switch to Checkmarx. We're in the middle of the deployment.

Yeah, some of the technologies and framework for libraries were not available at that point of time. For example, if it was in the back end, at that point in time we had to look at other tools. There were some analytical compliances so when we had more tools, it took all the technologies frameworks that Fortify was having. We required this because we were widely working with different clients for the different varieties of technology and domains. There were some regulated compliances, which were not there, but these were the factors because of which we had to use some instances of other tools as well.

Sometimes when we run a full scan, we have a bunch of issues in the code. We should not have any issues. We would like a reduction in the time frame of scans. It takes us three to five days to run a scan now. We would like that reduced to under three days.

It's still a little bit too complex for regular developers. It takes a little bit more time than usual. I know static code scan is not the main focus of the tool, but the overall time span to scan the code, and even to set up the code scanning, is a bit overwhelming for regular developers. That's one of the reasons we don't use it throughout the company and for all our applications, only for the ones we judge to be most important. Also, if you have a continuous integration in place, for example, and you want it to run along with your build and you want it to be fast, you're not going to get it. It adds to your development time. And it's too expensive to afford to run it for every application all the time. That's certainly something that requires improvement.