Fortify on Demand Reviews

We use it for statistical analysis for Java applications that are used in the collection process of a bank. It is also used for an internal web page. The tellers use this web page in the branches to make money transactions, such as withdrawals, deposits, etc.

The most valuable feature is the capacity to be able to check vulnerabilities during the development process. The development team can check whether the code they are using is vulnerable to some type of attack or there is some type of vulnerability so that they can mitigate it. It helps us in achieving a more secure approach towards internal applications.

It is an intuitive solution. It gives all the information that a developer needs to remediate a vulnerability in the coding process. It also gives you some examples of how to remediate a vulnerability in different programming languages. This solution is pretty much what we were searching for.

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.

I have been using this solution for two or three months.

It has been pretty stable.

It is scalable, but we haven't scaled it much. Currently, we have ten users, but it is capable of taking many more users.

Their support is good, but sometimes, they take a bit longer. For high severity incidents, they should properly identify the team that has to be engaged to solve an issue. I would rate them an eight out of ten.

The initial setup was pretty much straightforward. It was quite easy to implement. 

It is quite intuitive, and the training model that they have helps the development team in using it easily. The deployment process took only about two weeks.

In terms of the implementation strategy, it started with a kickoff meeting with the provider who offered the solution. We involved the development team, security information team, and infrastructure team from the beginning. They all knew what can be done with the solution and what role they are going to play in the implementation process, which helped a lot to achieve a pretty short implementation time.

It is cost-effective.

It is a great solution. It is cost-effective for a secure development process. If an enterprise wants to adopt the DevOps process, Micro Focus Fortify on Demand is a great starting point. 

I would rate Micro Focus Fortify on Demand a nine out of ten.

We use Fortify on Demand to test our e-commerce website. We do static codes testing before it goes live.

Before we migrate a new code to our production website, it is scanned with Fortify and all security vulnerabilities are identified. Then we try to remediate them so we don't expose ourselves.

I've been involved in deciding what's right or wrong. I've been involved in deciding on the product early on, and then if we should go on-premise or in the cloud, if we should build it into part of the software development life cycle or if we should do it on demand before we go to production. I've been involved in a lot of that. I've been involved in working with the development team to decide what is a vulnerability and what is not, and which vulnerabilities we need to take to heart, regardless if we understand what it is that we should ignore, and regardless of the fact that we think it's highly critical.

The product, in general, is meant to scan the website and identify any vulnerabilities: a known vulnerability across that script and SQL injection or other vulnerabilities from OWASP top 10, etc. That is what we're using this for.

The solution scans our code and provides us with a dashboard of all the vulnerabilities and the criticality of the vulnerabilities. It is very useful that they provide right then and there all the information about the vulnerability, including possible fixes, as well as some additional documentation and links to the authoritative sources of why this is an issue and what's the correct way to deal with it. 

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.

Stability is good. The product works.

Scalability is irrelevant to us because it's in the cloud. For the past few years, we've been using it in the cloud, so it's a common scanner. It's not handling transactions. It's not a firewall or an antivirus that you have doing real-time transactions. It looks at the code and the volume of code we migrate. We write a lot of code every week, but it's still within reason. We're not talking about thousands of developers sending code at the same time. So I don't think that scalability was much in our conversation.

The product is being used by the e-commerce application development team, and we have senior developers who are responsible to scan and evaluate security concerns that come out of the product. We also have a lead security person and a development team who are responsible to oversee this and ensure that the issues are being addressed.

Deployment and maintenance, are not really applicable because it was somebody at DNH working with the company, setting it up. We did not put it into part of the platform of real-time migration, such that the code automatically goes there, marks it, and allows it to go to production or not. We didn't go that route, so it really didn't need too many people to be involved in the deployment.

The technical support is just not there. We have open tickets. They don't respond. Even if they respond, we don't see eye to eye. As the company got sold and bought, the support got worse.

Our website is complex, so the setup is also complex. By definition, we expected it to be complex, and Checkmarx should also be complex because of the culture, habits, and complexity of our custom-developed website. Our website is not an off-the-shelf product, so there's a lot of complexity that comes with it by nature. But that's okay.

The initial deployment goal was to scan every bit and byte of code on the production e-commerce site. That was the plan. We started rolling this out and then we started sending tests. We went back and forth on whether we should make it in-line automatic that we scan sales, in a way that it would not allow the code to move further, or if we should do it off to the side, such that the application development life cycle continues to run separately, while somebody is scanning it making sure we dissolve all the issues. So we tried both routes. There are benefits to each, and it's definitely safer to do it in-line. Again, the culture, habits, and technology's use mean that it is not always best to do it in-line because it could become too complicated and break too many things. So we actually switched that. There is a person that does that. It's not built into the migration system by default. Somebody is scanning it and then moves to the next one.

We worked with them and they helped us deploy. We tried a few different versions. We tried on-premise, and then we went to the cloud. Fortify on Demand is the cloud-based version, which we're using now.

Our experience with their developer team was good. But now, over time, the company went from a partner to a disconnected environment. Overall, the experience started out with a back and forth and an active relationship but over time, they became very disconnected.

It's a yearly contract, but I don't remember the dollar amount.

I don't remember if we evaluated anybody else. I think Fortify was recommended through a consultant. Some years ago, there were not so many vendors at a time playing in this arena. There's not so many today for static analysis, but I don't think that we really evaluated any others.

I would advise others not to use Fortify, but rather get something like Veracode or Checkmarx. The most important thing is not the functionality of the product. The most important thing is the knowledge, support, and availability of the team of security specialists as a vendor, that you have somebody to work with and talk to. Everybody's website is different, and if you try to use the product out of the box the way they built it and you have nobody to talk to to figure out how to tweak your application or the product to reduce the noise and the false positives, it becomes literally useless. So I would not advise anybody to go to Fortify based on the fact that they really don't have a very forthcoming support team and availability.

Could be the other options would provide professional services, but that's not the point. The point is that if you want to pick up the phone and send them an email, open a ticket saying that, "This is a false positive," somebody should get back to you. So I don't think that Fortify's a viable option still these days based on the fact of where they sit and how they operate.

I would rate the product a four out of ten. It works. The reason why I give it a four is because of the limitations of the product to understand the dynamics of our website and the number of things that are not working smoothly due to the fact that our website is complex.

The security of our consumer-facing web sites is better.

The quality of application security testing reduces risk and gives very few false positives.

New technologies and DevOps could be improved. Fortify on Demand can be slow (slower than other vendors) to support new technologies or new software versions. DevOps requires very fast turnaround and I’m not sure HPE Fortify on Demand can do that, although they have a new product in beta for that.

We did not have stability issues.

We did not have scalability issues.

Technical support is very good.

We didn’t have a previous solution.

Setup was not complex, although given our size it was a challenge.

Drive a hard bargain.

We evaluated IBM and Veracode.

Go with the SaaS product.

It's saved us a lot of time as we focus primarily on security consultancy work rather than tool operational work.

Also, the features SAST, DAST, Dashboard/Reports, Fortify on Demand Portal and Vulnerability Tracking, have all helped with our work.

Finally, it's reduced operational costs as we minimized security incidents and ensured all vulnerabilities are remediated during the development lifecycle.

The results it provides are more than 95% accurate, helping us to focus on the right things first.

Our new software procurement process benefited as well as we use this as a central control to provide security assurance and evaluate the quality of our deliverables.

Its ease-of-use has influenced developer behavior and enabled them to follow security principles.

It would be useful if they could integrate secure design reviews, security user stories in Fortify on Demand Portal, and also look for possible options to get just one view of risks for given services (Covering Application, Infrastructure, Pen. Test, etc.).

I’ve used it since 2010.

We've had no issues with deployment.

It’s a very stable product. We've had no issues with instability.

It’s scaled for our needs. We've had no issues with un-scalability.

Customer service is excellent.

The technical support is very good.

We've used various other tools, including the Fortify on-premise solution. We chose Fortify on Demand as it is cost effective, scalable, easy to deploy, and helps us to manage our vulnerabilities centrally.

The initial setup was very easy and straightforward. We were able to roll out this service to all our business units.

We performed the installation in-house.

There is no setup cost as it is an on-demand solution. However, if there is any firewall change required for an internal application, we would need to raise that from our end.

We considered SonarQube, MSFox, and CodeInspect.

Fully utilize this product and its feature as it covers almost everything required for software security assurance.

What is most useful is how you can have related features upgraded on the tools. The tools themselves have details for the code as well, where the issues have been flagged, and all the vulnerabilities are there, in one place.

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 solution is very stable.

The solution is okay in terms of scalability. I'm still not really familiar with the tool, and I'm still learning from it. So far, I think it has a good ability to scale.

Technical support is okay. They have a platform that you can create tickets on. Once you raise a ticket, support is quick to help you. 

If they wanted to improve technical support they could offer meetings with the developer or security team.

It's a cloud-based solution, so there was no installation involved.

We use the cloud deployment model of the solution.

Whether or not you decide to implement the solution depends on the use case. It depends on if the user has a big application or multiple lines of code which need to be scanned. New users need to do POC so they can investigate if this tool fits in their company or their enterprise before they begin implementation. Everyone should do a comparison before implementing or doing the rollout of any security tool.

I would rate the solution seven out of ten.

We previously used it for static and dynamic scans, but now we use it only for dynamic scans.

We have close to 85 products in-house, so we run a lot of scans.

We are using lost programming languages, because we have a lot of product development going on because we have a product-based company. Fortify helps us to stay updated with the newest languages and versions coming out. We can run our scans on a timely basis.

We can run our scans properly on it. It improves future security scans.

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.

There are no stability issues. Though, we would like the scans to run faster.

We have no scaling issues.

Tech support has been a great help. They always respond to us in a timely manner.

Whenever we contact support, they assist us in running our scans.

We did not have another solution before. We tried other solutions, but they were not as good as Fortify.

I was not involved in the initial implementation.

The pricing is expensive.

Currently, Checkmarx offers us a graphically, revised run.

Security of our applications is a huge concern for everyone now. Using quality products like HPE’s Fortify helped us minimize issues raised by the clients. Therefore, customer satisfaction in terms of the security was high.

We identified a lot of security vulnerability much earlier in the development and could fix this well before the product was rolled out to a huge number of clients.

The Visual Studio plugin seems to hang when a scan is run on big projects. I would expect some improvements there. Also, the comments added on each issue were getting lost on multiple iterations of scans, which could be fixed.

Technical support is very good. We had a few issues in the initial setup and the HPE team’s support was commendable.

I did not previously use a different solution.

Initial setup was complex; we ran into lot of memory issues. The Visual Studio plugin was not responsive, either.

An in-house team implemented it. Don’t use the Visual Studio plugin, unless your solution is really small. Otherwise, use the command line setup.

It’s a tool used at the enterprise level; hence, I did not have a chance to explore other options.

It enforces source-code scanning, finding vulnerabilities in source code.

We're able to find vulnerabilities and weaknesses actually posting to site. We can get to these issues in our staging areas for active data and for verifying user vulnerabilities. It helps the development cycle in that we don't need other people involved in the scans. We're doing pre-scans and then getting other teams involved.

There are a lot of false positives and there's not a good way to manage them. They appear after every scan, and it would be nice to have them marked out so that we don't see them.

We've had no issues with deployment.

Stability could use a little improvement as we've had some issues. It runs out of memory sometimes and uses a lot of resources. Sometimes the scans don't work.

For code scans, company size doesn't really matter so much as the size of the code. It works well with the code scans we're running. Our lines of code aren't as huge as other applications we build, and it doesn't support every type of our applications, which are primarily .NET and HPE apps.

Technical support isn't top-notch, but it's not bad. It's just average. They take a while to resolve issues.

The initial setup was pretty easy and straightforward.

Find the solution that works best for your environment, using the group concept to try them all. Then determine which is best for you.