StackHawk Reviews

My main use case for StackHawk is to analyze our application live in our EKS cluster.

A specific example of how we use StackHawk in our EKS cluster is that we deployed an agent authenticated to the StackHawk platform and it is in charge of analyzing our different repositories, letting us know if we have any open vulnerabilities within our base code. Every scenario of analysis is completely published into the StackHawk platform so we can see if we have open vulnerabilities to solve and how much time it takes to perform the analysis.

The best feature StackHawk offers is called Attack Surface, which is a way of letting us know what repositories that we have hosted in any repository system have a surface attack, and in that case, we integrate the platform into StackHawk, then they let us know the application code base and how we have to integrate it and easily set up the application.

The Attack Surface feature has helped our team by having an inventory of our repositories and which of them have a surface attack.

StackHawk has positively impacted my organization by giving us a new vision of how vulnerabilities were seen, as we now have more visibility in that matter. We now take care of not just the static analysis and the composition analysis, but the dynamic analysis. When our microservices are running, we do have a vision of how it performs, and it also lets us know if we have any open vulnerabilities so we can close them.

Since we started using StackHawk, we've seen reports on different vulnerabilities that we have in our current microservices within the cluster, so now we have a wide vision and a wide perspective, and also we have new ideas about what we need to do. We also have similar microservices, so most of them are common errors and now we are closing up that gap of vulnerabilities.

StackHawk can be improved in the way that it is integrated, as at the very beginning, the idea was to, within the pipeline, mount the different resources that our microservices needed to start to run. For example, if we have a service that needed Redis, maybe Kafka, or a database to initialize, we did need to have a Docker Compose file, get up those services, and after that, do the analysis. It didn't have that; it wasn't reachable at the very beginning and it wasn't that good as we expected. But at some point, we decided to mount it as an agent in the Docker file, and it was waiting for new jobs. It was even better, and when we figured out how to integrate it within our EKS cluster, suddenly we started reaching to the services, knowing what was going on, and everything related to security. As long as we have a P2T to our QA site or cluster, we do not have garbage in our databases, but StackHawk does put a little information, a garbage information, doing their job.

That's the main area I'm focusing on right now regarding needed improvements.

I've been using StackHawk for almost a year.

StackHawk is stable.

Regarding StackHawk's scalability, I don't have a clear vision about how scalable it is, but we can use it in every microservice that we have, and we have almost 300 microservices and all of them can be analyzed within the cluster with our agent.

The customer support was amazing; every time they could, they brought a Spanish translator, so the communication was really smooth. I would rate the customer support ten out of ten.

I didn't previously use a different solution for dynamic analysis.

Regarding my experience with pricing, setup cost, and licensing, I'm not sure about pricing since I wasn't part of the team that got the application. The setup cost was actually really cheap; I hosted a self-runner with an image based on the StackHawk one, so it was really cheap and easy. I want to emphasize that I was not part of the pricing details and I'm also not sure about what kind of license we have.

I was just in charge of implementing StackHawk, and I'm actually not part of the security team, so I cannot measure its accuracy and reliability.

Since we started using StackHawk, we've seen reports on different vulnerabilities that we have in our current microservices within the cluster, so now we have a wide vision and a wide perspective, and also we have new ideas about what we need to do. We also have similar microservices, so most of them are common errors and now we are closing up that gap of vulnerabilities.

Actually, I cannot say that we have seen a return on investment, as we've been using it recently and the company hasn't adopted it with all the services, so there isn't any measurement about that. Also, at the very beginning, we were just working with two engineers, and now we have maybe just one, but I don't know, it's complicated.

Actually, I cannot say that we have seen a return on investment, as we've been using it recently and the company hasn't adopted it with all the services, so there isn't any measurement about that. Also, at the very beginning, we were just working with two engineers, and now we have maybe just one, but I don't know, it's complicated.

The setup cost was actually really cheap; I hosted a self-runner with an image based on the StackHawk one, so it was really cheap and easy.

We did not evaluate other options before choosing StackHawk; we went straightforward to it.

I don't actually have a clear perspective on StackHawk's AI capabilities regarding its governance and security.

My advice to others looking into using StackHawk is to stay prepared. Document how your architecture works, whether you have decoupled services or not. Based on that, it will be easier or not to use the application. In our case, we had to deploy an agent within our cluster and that was the only way we could analyze our microservices. So be prepared, especially technically, because they can help a lot in different areas, but you're the owner of your own infrastructure, so it relies on you how you're going to implement the solution.

My overall rating for this review is seven out of ten.

Public Cloud

Amazon Web Services (AWS)

My main use case for StackHawk is primarily as a PCI requirement for DAST.

As a quick specific example of how I use StackHawk for that PCI requirement, it is one of the controls that sits alongside the requirement to have SAST. I deployed StackHawk and Snyk because those two products were easily integrated and therefore providing a unified view of vulnerabilities that existed either during the CI/CD process or running live.

The best features StackHawk offers are, most importantly, its ability to report any issues that may exist with code running live. The integration with Snyk provides a more holistic, complete picture of issues in the entire life cycle of the web application.

An example of how getting a holistic picture of issues across the life cycle has helped my team is related to both StackHawk and Snyk because they were basically joined at the hip. Prior to the PCI requirements, there was not a lot of interest in automating the analysis of code that was being developed. Code was being scrubbed for vulnerabilities by humans, which is frankly impractical. You cannot go through either a few thousand or a few million lines of code and expect a human to find vulnerabilities because they are biased. That would be asking a lot based on the sheer volume of data and expecting people to identify vulnerabilities is completely impractical.

Outside of getting StackHawk connected to websites, which was fairly painless, I have no additional features that stand out to me besides the integration and reporting. StackHawk has positively impacted my organization by introducing an automated process that did not exist previously, and it helped the company achieve PCI certification.

I cannot think of anything I would add to StackHawk, with the possible exception of adding any additional code bases that might be out there. I am thinking about a situation where a company might be in mergers and acquisitions mode and they onboard a company that has developed an application in a code base that is not covered by StackHawk, which would introduce some inefficiency and possible compliance difficulties. It would be great if StackHawk were continuously adding more and more languages and integrations.

On a scale of one to ten, I would rate StackHawk an eight, only because I wish the product was a little less expensive. It also is running into direct competition with Snyk, as they did an acquisition of another DAST company, and they should be sensitive to that and possibly offer a discount for current users because it would be under consideration to move to Snyk and reduce complexity even if it was by a little bit.

I have been using StackHawk for a little over a year.

The advice I would give to others looking into using StackHawk is that the integration with Snyk was impressive. You would also consider just using Snyk and the DAST that they onboarded over the past year.

StackHawk is deployed in my organization in the public cloud using the configuration on their site.

I use AWS as my cloud provider.

I rate this product an eight out of ten.

Public Cloud

Amazon Web Services (AWS)