HCL AppScan Reviews

It is used as a last check before moving code to production. Therefore, it is used as a developer tool.

With AppScan, we are now deploying less defects to production.

We leverage it as a quality check against code.

No stability issues.

We have a strong partnership with IBM. Their tech support is very knowledgeable.

We were using something else (a competing product of IBM), but we switched to AppScan because it is reliable.

Most important criteria when selecting a vendor: At the end of the day, it would have to be the support and relationship. There are a lot of smart people out there building products which do things. However, not everyone can use them, and without having someone to call, it is sort of its own disadvantage. 

We develop software, and the software is property of our clients. So we want to ensure the highest quality possible, and assist the financial side. We want the application to be as secure as possible. AppScan has helped us to identify a lot of issues; we can find them before they reach a new environment. We catch them, we fix them, and we can offer a higher quality product to our clients.

We test on cloud.

In terms of the transition process from on-prem solutions, it was not so hard because we've been IBM partners for eight years. From the beginning, we started developing on those platforms. So it was natural migration, we were "born" with those applications on those platforms.

Usually when we deploy the application, there is a process for ethical hacking. The main benefit is that, the ethical hacking is almost clean, every time. So it's less cost, less effort, less time to production.

AppScan has absolutely contributed to the maturity of our AppSec risk management. I would rate that maturity at only nine out of 10 because there are things that we could be doing better. Not only because of our internal processes, but because we need to adopt to the clients' processes, and that adopting always has small gaps. But generally, it's pretty awesome.

We don't use it to security test open-source applications but we do use it for open-source models, or libraries.

It helps you to enforce security practices, beyond the reach of just operations and training. So give the training, but besides that you can detect some deviations in the development process. I think that's the most valuable of all the features.

I would love to see more containers. Many of the tools are great, they require an amount of configuration, setup and infrastructure. If most the applications were in a container, I think everything would be a little bit faster, because all our clients are now using containers.

I'm not sure what it like on the current version but the previous version had some small issues, some crashes.

With the latest upgrade - I'm not sure what version, I think it was 8, I've seen no major issues; some small glitches, but nothing really major.

Since we're development, we don't usually have issues with scalability because it's only one application.

Generally speaking, their tech support is good.

Usually our clients want to build in-house, but when we present the benefits of a product already built and, out of the box, it can offer a lot of features and can solve the problem right now... 

Sometimes the cost is equivalent to development, but it's more your product. 

A key factor for decision making is the release time. I can release in two months. or it can be released in six months, so that's a critical factor: price versus release date.

It's complex. Our main client is Citigroup. It's complicated because of the size of the client and all of the internal processes. So it's really a pain, not to blame IBM, not to blame us, not to blame them, but all of the ecosystem is complex.

Our clients evaluate Oracle, sometimes Microsoft. Our clients go with IBM, in Mexico, mainly because of the support. You can get more hands-on experienced people on IBM platforms than Oracle's, so if there is an issue - we always have issues - they get fixed more quickly on IBM than Oracle.

We use it prior to product releases. The web scan portion is used to find vulnerabilities, for example, if we have opened up any ports that we should not have. The source scan is used to look for similar types of vulnerabilities. However, at the source code level, it is scanning the source code, whereas the web scan is hitting ports trying to overload it. Thus, we use both of these types of scans before every product release of several of our products.

We have it installed on-premise, although we have a guy who is looking at the cloud version.

It has certainly helped us find vulnerabilities in our software, so this is priceless in the end. 

IBM Application Security has contributed to the maturity of our AppScan risk management program.

While it depends on the product, on average ten percent of our code is open source. Many products are either zero percent open source or maybe up to ten percent. They could possible be up to twenty percent open source, but never more than that.

The most valuable feature is the web scan from our perspective. Being able to quickly find the vulnerabilities if any developer has inadvertently put them in. The source scan is of value, but it is so hard to use that it is of less value.

IBM Security AppScan Source is rather hard to use. Some improvements need to be made to the usability for AppScan Source, specifically. Our biggest problem, we have a lot of code and everything just ends up looking like spaghetti after we run an AppScan Source. It is hard to evolve from one rev to the next. Trying to reuse the things we have found in a previous release to the next release is too hard.

It is perfectly stable.

Scalability is good. However, this ties into the usability a little bit, because we have a million lines of code in one product and this is part of what makes AppScan Source so difficult to use. There are so many lines of code with so many different categories that I am likely to get lost. 

AppScan Web is a good, and it does a good job. 

For AppScan Source, you might find a better solution out there. We are not actively looking for a better solution right now, and are just using it. However, if somebody else was starting from scratch, that is what I would tell them.

Most important criteria when selecting a vendor: quality of the software.

Our use case is that we always test our applications with AppScan before going to the production side. We have been using it for many years. It's honestly one of the best products in the application security the portfolio.

We aren't using it on the cloud.

It has contributed to the maturity of our AppSec risk management program. I would rate that maturity level as eight out of 10. The testing part of your application's security is very valuable. You can't avoid that.

Applications are the faces of companies to the world. How much your application is secure equals how much your brand is secure. AppScan is a very major part of of the story.

We don't use it to test open-source code.

There's a recording feature that I really like. You pass through the login pages. If you record the login part, it becomes very fast with the solution.

It's a little bit basic when you talk about the Web Services. If AppScan improved its maturity on Web Services testing, that would be good.

We experienced some performance problems at times, but it's actually not about the application. It depends on the hardware you use, the power of the CPUs, memory, nothing except that.

In terms of scalability, we don't need much. So I can't really answer this question.

I like IBM technical support as a whole. It was a really good experience.

When selecting a vendor we look for 

• a global brand
• support
• user friendliness
• cost, and the license models.

I would recommend AppScan.

We use IBM Appscan for a dynamic assessment of development of our code, so we're looking for something that will actually help us through our entire security development lifecycle.

It has performed better than we expected. We were able to use it quite often, use the server IDE to help test our code before we go into a full test. And it's helped point out some things we had to correct.

We're using it on the cloud. That particular solution we've been using on the cloud because it's a cloud instance, so the transition from going from one to the other wasn't there because we already had our cloud. We were able to use it because we had nothing else there. It helped fill a need that we really had.

It helps the organization the way we process the entire thing. It has actually helped a little bit with the speed of delivery too, which was surprising because most people thought it would be the other way around.

IBM Applications Security has contributed to the maturity of our AppSec risk management program. We've been working on our risk management program overall, for security development, and this has been a great asset to have.

We also use the solution to security test open-source applications. I'd say better than 70-75% of our applications are open-source. To me, a lot of people overly focus on open-source. That's because they believe that all the closed-source or proprietary is, in fact, secure. That's not necessarily the case. The issue is, when you take code and you're combining these different proprietary and open-source, packages, you have to test them all in the context where you're using them. And therein is the real issue. To me, it's not so much about the open-source, it's about all code. I believe all code has something that I have to look at.

We have a number of projects running concurrently, so I look at the aggregate. I try not to go to what's done on a single product. However, having said that, since we had nothing in dynamic and now we do, that's a huge improvement. You might say then that it was 100% improvement. I don't know if I would give it quite that number, but it is a huge improvement. It's quite near that number.

For me, as a manager, it was the ease of use. Inserting security into the development process is not normally an easy project to do. The ability for the developer to actually use it and get results and focuses, that's what counted.

I think being able to search across more containers, especially some of the docker elements. We need a little tighter integration there. That's the only thing I can see at this point.

I haven't had any issues with stability so I think it's fine.

We're in the process of testing scalability, so I can't really speak to how broad that is because we're just parring up our entire installation of it. I am looking across other parts in our business where our more traditional products are that connect. So, we're looking to see how that scales. But, overall it's looking good.

Once we got into the queue, we got a fantastic turnaround.

Here I have an unfair advantage. I came out of a large security company, and because of my experience and the fact that we had a need, I looked around for the best solutions that were available. There were a lot of competitors. The question was, how well it would integrate with our process, since we were developing a full SDL with security tool check-points. AppScan fit that very well.

The most important criteria when selecting a vendor were that it had a great product, but I had to have a product that I could integrate and automate. For me, it wasn't a matter if it was best in breed, they had the neatest slice of cheese. What I was looking for was, could it integrate and automate? If it couldn't, they weren't on the selection list.

I didn't do the work but I directed it.

There were a couple of steps where we had to have some help. But at the same time, we just put in an engagement for a Professional Services to do it quicker, do the integration, to make it tighter for us. We're just waiting for the final part of that to be signed so we can actually move forward.

Veracode, Synopsis, and a few others. What made us go with IBM was the integration and automation efforts; what it would do there, and the fact that it did so well at what AppScan does, which was in the dynamic testing.

In terms of rating it, because I haven't had it installed long enough, and we haven't finished all the integration because of the Professional Services yet, I'd say it's rating really well, toward excellent. But it's just one of those things, until you see all the proof in the pudding...

As of right now I would rate it an eight out of 10.

The advice I would give to a colleague is, first, know your development process and where it's weak. From there, insert secure development, realize that it's not about the tool, it's about the process of development. Then find the tools that solve that. For us the key was, could it integrate, could it automate, and could it make the developer's workload easier? That's what we looked for.

It is used for a DevOps environment, to perform a security profile, a code profile assessment. When you are building your software code, before finishing the build process and deploying to production, we run AppScan to figure out any security vulnerabilities in the code. It's called static analysis of the code.

It decreases the operational risk, security risk, a lot. In fact, when we first used it, the number of vulnerability alerts generated by the tool was huge. As time goes on, we can decrease those vulnerabilities because we learn from it. So, in the next release of the software, or new software that we have to develop, we know upfront that we should take care of some of the characteristics of the software.

It highlights, with several grades of severity, the types of vulnerabilities, so we can focus on the most severe security vulnerabilities in the code.

One thing that we would like in this tool is that it keeps ahead of the security guys, because one big advantage of this tool is that it always offers updates. Security is a process, you mitigate a risk, but the malware guys, they're trying to find another security hole in your environment. And the technology is evolving. So new security vulnerabilities are in the software. The point is, I hope that IBM continue, in improving and launching new versions, new upgrades, that can mitigate those security risks. 

That's the most important value. It's not the tool itself, but the continuous enhancement of the tool. That's why we recommended this tool.

It's pretty stable. No issues as far as I can remember. 

It's scalable. In the beginning, we found some issues regarding installing the tool in an open-source Jenkins environment - Jenkins is a tool for open-source. Jenkins and other tools, they automate the process. Those tools call AppScan in a way to generate a proper time to do this. But after a couple of discussions, we solved the problem, so we don't have any issues anymore.

I think it is pretty good. They answer in a very fast manner.

It's pretty straightforward to install and use it.

One competitor that I remember, one of the last candidates in the evaluation process was Checkmarx. Those tools, especially from startups that come from Israel, they try to grab this market space that IBM dominates.

That's why they have to take care in terms of the price; the price model. But other than that, it would be unbeatable.

The most important criteria when selecting a vendor, first of all, is their capability to continuously invest in the development and enhancement of the software. We are in a very changing process, software is a very changing environment, in terms of the technology. If you develop a tool, launch this tool, but don't have enough commitment to upgrade, to continuously enhance, it's not worth it. That's why I think IBM has a good presence in this area.

My advice would be, don't see only the cost. Try to see the capability of the tools and, besides that, as I have stressed in this review, the capability of the vendor to invest in enhancing and mitigating the risks that will come. New risks, new threats, security threats, will appear. If you don't have a company that is continuously enhancing its software, there will be a problem.

I would rate this product a nine out of 10. The reason I don't give it a 10 is because AppScan is a little bit expensive. IBM needs to work a little bit on the pricing model, decreasing the license cost. But with the maintenance - and the maintenance is the most important, as I told you, because it has to continuously enhance the tool to mitigate the increasing malware in the future - IBM could recover the investment and meet their target margins in another way.

Unfortunately, there is a big discussion if it is very expensive, to use it or not, and there are competitors. I see competitors trying to grab this market.

But from the point of view of quality, very excellent quality, it's above all the tools that I have worked with.

IBM AppScan has made our work easy, as we can do four to five scans of websites at a time, which saves time when it comes to vulnerability.

Many features are valuable but some features stand out, like using our own scripts, and capturing the authentication.

• It has crashed at times
• Scans become slow on large websites
• Many silly false positives are produced

Yes, sometimes we encounter stability issues.

Yes, sometimes we encounter scalability issues.

I would rate tech support a seven out of 10.

Yes. We switched because they made our work easier, with fewer false positives.

It was simple, once we watched many video tutorials and read PDFs to learn about it.

Yes, I used with Acunetix and open source tools.

The benefits are that we that we can find security vulnerabilities fast, get that back to development teams, and report on those. They can then act, fix the issues, and we'll have a secure code in place.

It is easy it is to use. It is quick to find things, because of the code scanning tools. It's quite simple to use and it is very good the way it reports the findings.

We would like to be able to integrate to some of the other tools that we are using. That would be great. We would like to integrate with some of the other reporting tools that we're planning to use in the future.

I think it's quite stable.

So far scalability is pretty good.

We're really happy with technical support. They are great and very responsive.

I was not involved in the initial setup.

What I look for most in a vendor is the product, the offer, the service, the vendor service, and after sale support.

I would definitely recommend this product.