How to Use Bug Bounty Program Data to Enhance Development and Security ?

Data from bug bounty programmes tells a story, but which one?

Organizations can discover problems, spot opportunities, and take corrective action by tracking programme metrics. Stakeholders must be aware of the metrics to monitor and how to interpret the data in order to accomplish this.

Two seasoned HackerOne programme managers, Allie Lugton and Denzel Duncan, led a presentation on tracking and analysing data from bug bounty programmes at the 2021 Security@ conference.

Denzel and Allie gave an explanation of how businesses may use data to improve the security and value of their programmes.

Three Steps to a Successful Bug Bounty Program

Programs offering bug bounties have three main phases.

Phase 1: Planning

The team from your company will create the overall programme during the first phase, which includes the following:

• Security page;lays out the participation requirements and ground rules for ethical hackers.
• Program scope;indicates to hackers which resources they can access and the methods they are permitted to employ.
• Rewards provide hackers a return on their investment (ROI).

Your company will also set up connectors with current developer and vulnerability management systems, such as JIRA or Service Now, and create responsiveness goals for your security and development teams during this phase. You can monitor programme performance over time using these objectives. Ideally, make them difficult but achievable, and think about tightening them over time.

Phase 2 : launch

Starting a bug bounty programme is a huge step, therefore it's crucial to keep the security and development teams from being overburdened. To do this, employ a step-by-step strategy, beginning with a modest private programme and progressively encouraging more hackers to participate. This will give your teams time to find weaknesses in current vulnerability management systems without being overrun with reports.

Common measurements used during this stage include:

• Reporting size
• Volume of a valid report
• Volume of reports, by severity
• Number of invited hackers
• Accepted number of hackers

Work with your programme manager to come up with changes if you notice an issue so you can get back on track. For instance, if you're getting an excessive number of low severity reports, you could want to change the programme scope to leave out less important assets.

Phase 3: Development

You will inevitably enter the Growth phase when your programme becomes established and you create KPIs. You'll carry out ongoing reviews during this phase to make sure your programme stays active and efficient.

Keep track of metrics to make sure your programme is fulfilling its main goal. Track the kinds of vulnerabilities that are reported and contrast them with the Top 10 online application security concerns identified by OWASP, for instance, if your goal is to protect web-facing assets against common threats.

Typical KPIs to monitor are:

• Reporting size
• Volume of a valid report
• Volume of reports, by severity
• vulnerability breakdowns by class

Keep track of how quickly you respond to identified vulnerabilities by validating them, addressing them, and paying bounties. You should strive to maintain continuously good responsiveness because these metrics are essential for keeping hackers interested in your application.

Finding Trends and Patterns

Allie and Denzel, like other HackerOne programme managers, have experience interpreting programme data and assisting clients in taking the necessary actions. Among the frequent patterns (and contributing factors) they observe are:

A high number of duplicate reports can be a sign of a problem with the remediation process. The likelihood of receiving duplicate reports would rise if it took a team a long time to verify and fix vulnerabilities, forcing internal teams to spend time triaging duplicates. Hackers and security teams would be frustrated. Hackers might believe they spent their time uncovering and reporting those problems because they are not compensated for repeat findings.

Trending vulnerability categories across numerous assets point to a root reason that needs to be looked at, such as the requirement for developers to receive training on a certain problem.

Trends in the seriousness of reported vulnerabilities for an asset might indicate a number of problems, such as:

• A programme may have low security maturity if it has a large number of straightforward vulnerabilities.
• An asset may be maturing and needing more sophisticated methods and processes if there is a consistent flow of key data.

Although these are frequent results in data from bug bounty programmes, they are merely samples. Collaborate regularly with your programme manager to identify and address problems if you want your bug bounty programme to be as effective as possible.

Data-Driven Collaboration Between Security and Development Teams

The working connection between the security and development teams is essential to the success of a programme. You can deploy solutions to help the teams work together effectively to achieve vulnerability management objectives using programme data to identify potential collaboration breakdowns.

Among the crucial metrics to monitor are:

vulnerabilities with a long time to address. TTR ought to decline organically as a programme gains more traction. A high TTR indicates that the repair process has failed somewhere. By monitoring this measure, programme managers may spot problems as they happen and look into them to make sure the right procedures, teamwork, and SLAs are in place.

types of reported legitimate vulnerabilities. There may be gaps in the current vulnerability management processes if a specific category of vulnerabilities is frequently reported. Typically, businesses can either tighten code review methods to discover them early in the development cycle or train developers to avoid creating similar vulnerabilities in the future.

For developers to design secure code, education and empowerment are essential. During the session, Allie explained:

"We constantly monitor data trends that result from programmes. Any bug bounty programme must have access to this information in order to develop. Analyze the times it takes development teams to respond to tickets, look at remediation times for real vulnerabilities, and utilise the information to push where it is required. Bring back information on the most often occurring vulnerabilities, and teach development teams to write code that avoids them whenever possible.

To make this process simple, HackerOne interfaces with businesses like HackEDU that provide secure code training for developers based on trends found in programme data.

Strengthen Security Through Data

The majority of bug bounty programmes have raising the organization's security profile as their ultimate objective. You should keep a careful eye on data patterns and act quickly to address problems where they arise if you want to make sure that your programme accomplishes this regularly.

We have looked into a number of uses for programme data. The main take a way from the meeting with Allie and Denzel, though, was unmistakable: your programme manager is in a perfect position to support you in using data to enhance your bug bounty programme.

They are skilled in following, analysing, and acting on data from bug bounty programmes, and they have assisted numerous firms in establishing fruitful, long-lasting relationships with hackers that serve important security goals.