The primary use case for AppScan is for security purposes. I compare AppScan with other tools such as Veracode. We use AppScan for vulnerability detection and auto-remediation of vulnerabilities with features built into the tool, including their AI solutions. I work with AppScan and other security tools as part of my role, focusing on market-leading tools.

We use AppScan primarily for security testing and performance monitoring across our systems.

HCL AppScan is a security scanning tool that we use in our company to scan our applications.

We use the product for Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). By integrating AppScan into our CI/CD pipelines, aligned with Agile methodologies, we ensure that security testing becomes an integral part of the software development lifecycle.

I mainly use AppScan to secure various types of applications. I use its DAFDAT solution for black box scanning, as well as SaaS and source code validation. AppScan helps in scanning code for vulnerabilities, including open-source code.

I use HCL AppScan in my company for application security scanning.

The solution is used for the vulnerabilities scan on the network side.

We use it for evaluating the application's code on web pages and previously published applications to identify vulnerabilities. It helps us to see how the code is written and how hard it is to find vulnerabilities. It's a useful tool for our purposes.

This is a primarily application security testing solution.

HCL AppScan is primarily used to improve application security. We are transitioning from DevOps to DevSecOps.

We are attempting to integrate these tools into our CICD pipeline in order to meet our business use cases. And if we notice that the tool is missing any business features or a feature, we will highlight them and work to have them fixed or implemented. That is how we go about it. We don't go for any generic features because that will be handled by the product team. We are here to identify our gaps and then have them implemented by the vendor team.

AppScan is only used for web scanning; we do not use it for anything else.

I used the solution to find vulnerabilities in our website and system. I did some regular checkups.

I use the tool to find system information for penetration testing and ethical hacking.

We primarily use the solution for static scans as well as dynamic scans to check for vulnerabilities. 

We use HCL AppScan products to help us scan for vulnerabilities and generate reports to provide a foundation on how to fix any issues. Their 4.7 version facilitates machine learning to help us select APIs and customize our scans more specifically. We also use the HCL AppScan Standard Enterprise Source and Cloud for scanning, and we plan to add the HCL AppScan Switch Casing to our toolkit. This makes it easier for us to scan the internet and use Tenable to help us find any issues.

We use the solution to test our web applications and services.

I have a set project, and I'm writing an application for monitoring server status, and I tried several times to scan it with AppScan in order to understand if there are vulnerabilities in my code.

We primarily use the solution for static analysis.

I use it for my customers. 

HCL AppScan efficiently scans through the website and identifies vulnerabilities for AWS. It is reducing tools day by day, making it more efficient. 

I use the tool to scan the web interface.

I mainly use AppScan for vulnerability scanning and database bridging.

We perform more dynamic scanning using AppScan. We set up a scan, perform it and get the results, and then give the results back to our customer.

Within our organization, there are four members of the team who are using it.

Currently, we are satisfied with AppScan but I am sure there are better alternatives available because this is a very old product. It's been on market for more than ten years now. I am sure there are a lot of new age products that are more scalable and cloud-based. Although we are using it and will probably continue to do so moving forward, I think there are better alternatives on the market now.

The primary use case is to detect time-based Blind SQL Injection attacks, as well as Error-Based Injection attacks. The SQL injection attack is my favorite and I have more expertise in this vulnerability.

External and internal web application vulnerability scan.

Our clients use it to try to find errors in base code, and also to find how solutions work together.

I believe they have on-premise usage; they are local government, so they are not very used to using the cloud.

It is an application for security assessment or scanning for static environments.

With all customers, it is performing well.

We integrate AppSense with Fortinet FortiGate Next-Generation Firewall products. This integration is new for us, but so far, we have had good results. However, it is a new integration. 

Fortinet has a lot of potential and integrations going on with IBM: QRadar, AppSense, and IBM Cloud.

We use it for all website development and web-based applications, as part of our development test cycle and QA.

We also routinely use it on existing applications in production because, in terms of security and vulnerabilities, some of the latter exist on some of the platforms that we run. So we run it from time to time, to do some security checks, etc.

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

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.

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.

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.

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 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.

We use it as a security testing application.