BountyHub's workflow automation system offers a unique approach compared to other popular automation systems. The idea arose from my frustration with existing automation platforms that I wanted to try.
Every single one of them had some aspect that I found limiting or frustrating, which led me to design BountyHub's workflows with a different philosophy in mind.
I will walk through some of the key ideas I wanted to have from my automation platform. If you don't care about that, you can skip to the comparison section.
I am not suggesting that BountyHub is better than other systems.
Each system has its own strengths and weaknesses, and the best choice often depends on your specific use case and preferences.
This platform is built for like-minded people sharing the same goals I share, so we can build a community around it, and the system that we all enjoy using.
If that is not you, that's perfectly fine too! I highly encourage you to explore and experiment with different systems to find the one that best fits your needs.
Scans are not tools. The tool is the main driver, but the scan consists of multiple steps, including pre-processing, post-processing, handling errors, etc.
I do have an external server to this platform I'm playing with, that will most likely become a new feature of the platform. My scans are periodically propagating the data to the external server.
I need my tool to run, transform the output, and push it to my server. That all constitutes a scan. Not the invocation of the tool, but also the side-effect the scan creates.
I want to have full control over the environment in which my scans run.
I've developed some tools that are pretty specialized, and I want to be able to use them in my scans. During the initial creation of the platform, I couldn't run self-hosted. Tools are stored on every machine my runners are running on and I want to invoke those tools, not the ones from the library of tools.
I want to have a simple syntax that is easy to read and write. I don't want crazy GUI where I end up zooming in, moving left and right to see the entire workflow.
I need a clear description of my scan, and a clear description of the entire workflow.
There is a reason why there is something like code as infrastructure (e.g., Terraform, Ansible, etc.), why GitHub Actions and GitLab CI use YAML to define workflows. Text-based representation is often the best way to define complex workflows.
I want to have a live workflow that I can interact with, instead of a static pipeline. I want to be able to dispatch the scan. I want to be able to run on different schedules, and I want to have a way for multiple pipelines to interact with each other. I care about the latest results, not the sequence of execution. Some scans are more frequent, running on the same data. That is fine. I don't need to re-discover a subdomain to scan it again.
I could use GitHub Actions for example to run the workflow. True, I don't need git, but I can simply run my steps on my self hosted environment.
However, where do I upload the results of my scans? How do I manage the findings? How do I track the progress of my work?
I want to be notified on particular findings. That would mean I have to
configure notify for every scan. Let's say I'm running a scan that potentially
exploits the target by causing it to issue a request to a server I control. I
could run my server separately, but then, I'm managing two separate systems. I
want to have everything integrated in one place.
Not only that, but GitHub Actions for example is designed with code-related events in mind. I need triggers that are more aligned with security research and bug bounty hunting. For example, I want to run a scan when a new subdomain is discovered. That is not something that GitHub Actions can do out of the box.
The scheduling decisions should be made by the scan being scheduled, not by the scan I depend on.
For those of you who are also developers, you might appreciate this parallel. Go interfaces for example use duck typing. I can define the interface locally, and as long as something contains the necessary methods I want to use, based on the method signature, I can pass it as an argument.
On the other hand, Java/C# style interfaces require explicit implementation. My type needs to know which interface to implement, so I can pass it as an argument.
The same principle follows here.
I don't want to connect my subfinder scan to my httpx scan. The subfinder
shouldn't care about what is next in the pipeline. The httpx scan should
decide if it should be scheduled or not, based on the expression that is not
linear.
In GitHub Actions, you have needs field, which effectively does this. However,
I cannot test for anything except for the dependency being met. What if I want
to schedule only on output diff. How to do that?
And for n8n, Trickest, and alike, I don't want to drag the line from subfinder
to httpx. My httpx instance should be scheduled much more frequently than
the subfinder. There is no line there. I need to use the latest results, not
pass the data from one scan to another.
I often run subfinder every other day, but httpx every 12 hours. Should I
run the subfinder more frequently just to satisfy the dependency of httpx?
No.
The point of this section is to describe differences between BountyHub's workflows and other popular automation systems, so you can make an informed decision.
This is obviously a biased comparison, so please take it with a grain of salt.
And if you disagree with any of the points, please feel free to reach out and discuss it with me. I'm always open to feedback and suggestions.
This is an amazing automation tool. It has a great UI, and it is very easy to use.
However, it is designed for general purpose automation, and it lacks some of the features that I wanted for my bug bounty hunting workflows.
Just take a look at NahamSec's Automation Using n8n.
As you can see, it goes against multiple issues that I have with existing automation systems:
httpx every 12 hours, but subfinder every other day, there is no way to
express that in n8n. You have to run subfinder more frequently just to
satisfy the dependency of httpx.On the other hand, some people prefer UI over text-based configuration. In this case, you should definitely consider n8n. It is very stable, very pretty, and has a great community.
N8n has many tutorials to help you get started, so if this is what you are looking for, definitely check it out!
Similar to n8n, there are other popular automation systems like Zapier and Integromat.
Same objections apply to those systems as well.
These are great tools for automating workflows related to code repositories. However, they are not designed for bug bounty hunting workflows.
Although they have cron-based scheduling, conditional scheduling must be
triggered from the calling workflow. My subfinder must know to dispatch the
httpx, which must know to dispatch the nuclei, nmap, etc.
These platforms are very stable, but they are not designed for the use case that I have in mind. They are designed for code-related events, and they lack some of the features that I wanted for my bug bounty hunting workflows.
Also, I'm missing the ability to integrate with my bhlast servers, ability to get notified on the diff, unless I use something like notify, etc.
I need an automation for hackers, not for developers.
Fun fact: One of the founders of Trickest (Nenad Zaric) is the guy who introduced me to bug bounty hunting, which I will be forever grateful for.
Trickest is a great platform for automating red teaming and penetration testing workflows. However, it is not designed for bug bounty hunters.
Back at the time I wanted to use it, there were no self-hosted agents.
But okay, let's even grant that, maybe I could develop custom scripts instead of the tools written in Go or Rust and run them. However, Trickest is designed in a tools as the top-level concept. You create a workflow by chaining tools together.
Tools are provided in the UI, and you combine them to run your workflow. The scan output must be transformed using intermediate step, which adds noise to the workflow.
Also, it is very GUI oriented. It suffers from the same objections I have against n8n and the platforms alike.
The pricing model is just not designed for bounty hunters. Free plan contains 14 days retention period. This is not enough for bounty hunters who want to track changes over time. This is not enough for me who wants to see how the target evolved over time. This is definitely not enough for me when I stop doing bounties for 2 weeks and want to start again, reviewing the results I've found until my automation starts producing results again.
On the other hand, Custom plan requires talking to the sales team, and getting features I don't truly care about:
I don't want most of these things. I don't care about most of these things.
Most companies offering workflow automation systems are designed for businesses. Pricing models and features are designed with businesses in mind.
I think that for most of us, results should be the driving factor. Data retention, scheduling flexibility, ability to customize the environment, and similar features should be the driving factor.
Therefore, I have designed BountyHub's workflow automation system with these principles in mind.
It solves my own problems, and I truly hope it solves yours as well!
If you haven't already, check out the workflows overview to understand the basics of workflows on BountyHub.
Learn more about the runners, an agent that execute workflows for you.
Currently Reading
Comparison With Other Automation Systems