OpenText Core Application Security Reviews

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.

My primary use case is to help the teams in development. It helps us scan.

First, you don't have very high requirement and we could do it quickly and efficiently. Second, it was easy for us to install the reading bot facing challenges and such, while doing that installation. Third, when we were doing the scan, it was self intuitive and we were able to scan faster while we had two challenges in the other two solutions that we were using. In terms of finding out where to configure, what are the next steps to configure what we are missing and those kind of areas.

Usually what happens, because we were part of the COE, we had to find those faster and go through old ECs and deliver the results to the short duration income. So, that's where it helped us, it helped us setting up that environment quickly on a laptop, do the scan and come back.

The features I found most valuable is that it is very configurable. The installation was also very easy. 

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.

I do not remember any issues with stability. Of course, it is common that if there is some misconfiguration, it can lead to crashes and the site of the code can crash. But, this is something we have learned to tweak and estimate the length of code before the site of the application. Then, we can consider which technology could be configured, what technology should be excluded, and then scan to optimize some of the related issues.

In terms of the scalability of the solution, we did not have a centralized server connecting to multiple clients. We did not have scalablility issues due to our small-scale use.

We had a good tech support experience.

It was very straightforward in comparison to other solutions that we had used in the past.

The licensing was good because the licenses have the heavy centralized server. It connects to the other PTs, or even if it connects to the old EC servers. We had to put it within an old EC, in order for the licensing to be available at all scales.Then, you had to open multiple ports in that scenario that was not possible. But, you can do it at the application level, which is faster. You can buy a license, do a scan at that level, as well as scale up. So we also had multiple requests in terms of helping a client before they start in terms of doing something easy so that you do not require a complete license to be purchased.

We were using many other tools like TechAbility, IBM AppScan and I think these were the predominant ones.

Today's security has become so complex that you cannot lean completely dependent on one tool. What I have learned is that you should have multiple tools. Now, with different areas coming into space, all of these tools have to co-exist. To make the right choice of a tool is really important. A solution must have ease-of-use. If it becomes too difficult for installing, configuring, learning the scan, then the add option becomes a challenge.

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.

We use it for externally exposed applications that we want to scan before releasing them to production. As you can imagine, it's important to make sure they're secure and that we will not be exposed. For internal apps, we use other static code scanning, primarily SonarQube. But Fortify on Demand is for externally exposed applications.

Because of the kind of products we deal with, and the kind of customers we have, we have really specific security requirements and practices we need to follow, specifically applying to our SDLC. Our SDLC dictates that we have security scanning, and that improves our code quality. Thankfully, we have never had any kind of serious security flaw or any kind of deviation of the process. We can certainly account for that because of the security tools and analysis that we have prior to moving code to production.

One of the valuable features is the ability to submit your code and have it run in the background. Then, if something comes up that is more specific, you have the security analyst who can jump in and help, if needed. I think that's really useful.

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.

I haven't really encountered any issues with stability.

No issues with scalability. It has been able to handle all our workload so far.

Our experience with tech support has been good. We haven't needed support that much but whatever we needed we were able to find on their website. There were a couple of things regarding the licensing and payment that we had to get some help with. But it was quick and easy.

We didn't have a previous solution. We researched a couple of the tools, but we ended up using Fortify because of the comprehensive scans they have, and mainly because they are focused on the kind of apps that we have and the kind of requirements we have. They are able to cover most of the standards and practices that we need to adhere to.

The initial setup was straightforward. We had onsite training from HPE to help set up the local environment and first scans, and that was helpful.

The subscription model, on a per-scan basis, is a bit expensive. That's another reason we are not using it for all the apps. That subscription model is probably something that needs improvement.

We looked at CheckMarkx and SonarQube Enterprise. As I said, we are currently using SonarQube for other apps, but we use the open-source version. We tried to use the Enterprise version but it didn't cover all the aspects that we needed it to cover.

Understand what you want to get out of it and be sure to fully understand what you will be paying per scan if you go for the subscription model. As I said, having to scan hundreds or thousands of apps using that subscription model and doing that several times a week, or several times a day, may increase your costs. That might be something that you need to look at.

I rate it at nine out of 10. It's not a 10 because of the cost model, it's a bit pricey, and the slowness, it could be a little bit faster. I understand the reasons why but you just need to be aware before you start using it that the local scan won't be as fast as the static code scan.

I analyzed more than 20 applications implemented in BIT Brainery University. The static analysis has to be done every release before putting it in production.

Even though it was our final choice, it has saved us a lot of time as we focus primarily on programming rather than tool operational work. We did not need third-party consultants.

We shared the easy to use dashboard with our programmers and involved outsourcers for a quick issues fix. 

It lacks of some important features that the competitors have, such as Software Composition Analysis, full dead code detection, and Agile Alliance's Best Practices and Technical Debt.

When choosing a software security product, we expect the product not only has the ability to find exploits, but also has educational and instructional capabilities related to exploits. This makes both the security auditor's job easier and helps the software developer to improve himself and write safer code. Here we have seen that the Micro Focus family has exactly what we want. For this reason, we chose Micro Focus software security products. In addition, the quality of the support and updating services ensures that we gain confidence in their products.

In large software development teams, the most important issue related to software and application security is to identify vulnerabilities and weaknesses quickly and accurately, then to gather those findings on a common platform so  they can be distributed and tracked by teams and developers. 

Micro Focus WebInspect and Fortify code analysis tools are fully integrated with SSC portals and can instantly register to error tracking systems, like TFS and JIRA. This facilitates error and vulnerability management and makes the "Secure Software Development Lifecycle" work well.

The most important feature of the product is to follow today's technology fast, updated rules and algorithms (of the product). It also allows for more efficient and custom integration by allowing customized enhancements through the API support offered through the SSC portal.

Though it is generally close to perfection, the biggest deficiency is the integration with bug tracker systems. It might be better if the configuration screen presented for accessing the bug tracking systems could provide some flexibility. Since there are different templates on TFS in particular (CMMI, Agile etc.), the configuration for different templates can also be customized with the flexibility to be provided here.

The HP FoD effort allowed my client to utilize this service anytime their internal IT team was overwhelmed with workloads. FoD gives them an option to utilize the additional HP Services when they are overwhelmed with other IT Security needs across the company.

• The ability to utilize the Client Portal, which provided my clients with a view of the project status, vulnerabilities and needed remediation steps in real-time
• I don’t know of any other On-Demand enterprise solution like this one where we can load the details and within a few days, receive the results of intrusion attacks, and work with HP Security Experts when needed for clarification
• The process was easy to follow and we were supported by 24/7 by TAM personnel to help with any fire drills. This was helpful many times when I needed a quick answer late at night or early in the morning

• I believe that sales packages should be posted for single applications, and packages of multiple applications. For example, we have one-time a package for single applications, and 12 month unlimited use for static and a package for static & dynamic testing. It would be nice to see packages posted for a single application, and groups of three, five, or 10 applications. More than 10 applications would need to be custom pricing like you have today.
• I would like it to be easier to understand, and have better packaged reporting capabilities. For most of the reporting I needed, I exported to Excel and then had to produce more visually accepted reports for Executive Clients. With Rapid7 I utilized its reporting capabilities to deliver Client Reports within just a few minutes of checking the data. I believe that HP’s FoD Clients could sell more services to clients if HP put more effort into delivering visually pleasing reporting capabilities.

Because the product is based on HP’s Fortify Platform, the product is great.

I can’t answer this question appropriately yet as I only utilized the service for one application so far.

Customer Service:

10/10 - Christine Bobba, Gerald and the whole TAM Team were very supportive. Stuart Ward does a great job running his TAM Team focused on customer service.

Technical Support:

Jason Powell was really support from a technical perspective. He was able to quickly gather the details we needed to resolve security issues with the code or set up.

I’ve used Rapid7 and Qualys Security Solutions in Managed Service Environments for previous clients. Both are really good solutions, but I’ve not utilized any other On-Demand Solution.

I switched because my client uses HP as its core product set. I needed to use Fortify and the FoD Solution allowed me to be up and running within a few short days.

Super easy deployment and usage of the scanning capabilities. The setup was straightforward, and the ability to enter data and start the correct scan was intuitive.

We did not charge for the product, we charged for our PMO Services to run the product.

We used the one-time application, Security Scan Dynamic. I believe the original fee was $8,000.

I would suggest, and I have, that companies should utilize the 12 month unlimited test package.

I searched online and FoD allowed me the best opportunity for success due to my client’s timeline.

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.