HackerOne in DevSecOps

I’m not going to define DevSecOps in yet another blog post. There are plenty of great resources for that. I do want to set the stage with the familiar “infinity” diagram many organizations use to describe the process.

Figure 1: Security, shown as a green line, is integrated into the DevOps process at multiple points.

Implicit in the diagram is that security—the green line— is integrated into the CI/CD process at several different stages and various technologies. These are labeled in gray, above or below the green line. On the Dev side are the familiar static, dynamic, and interactive scanning tools SAST, DAST, and IAST, respectively. Depending on your process, you may use these tools in one or more of the Code, Build, and Test stages. In addition to these, pre-deployment pentesting is becoming more common in mature development organizations. 

Today’s organizations deploy code faster than most teams can keep up with and code that has not been pentested ends up in production many times a day. When humans do pentests, they can find mistakes that scanning tools miss. 

SCA tools track an organization’s software projects to detect open source components with known vulnerabilities and provide detailed security information about these vulnerabilities to help developers remediate them swiftly. HackerOne has a community edition used by several leading open source projects to run bug bounties. Many of the vulnerabilities found in these bug bounty programs make their way into SCA tools. 

Last on the Dev side is threat modeling. Threat modeling is a process in development where potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified and enumerated. Threat modeling also allows for the prioritization of mitigations. Threat modeling is done during the Plan stage and precedes the use of scanning tools. I mention it last because the inputs to threat modeling often come from observations made after application deployment. These may be observations from tests or programs run on the deployed application or new threats that come to light from the security community after initial code deployment. We have customers that use the high-severity vulnerabilities they discover as markers to find those specific vulnerabilities in other assets, saving time and resources.

On the Ops side, we have more variety in terms of tools and processes. Fix validation is a process used by some organizations to check fixes addressed in production code. RASP, or runtime application self-protection, is an agent-based technology that sits on a server and monitors the application running on that server. Then we have pentesting. Pentests on live applications are more common on the Ops side than on the Dev side. Often called assessments, pentests can satisfy compliance requirements, test against known vulnerabilities, or be group exercises like red teaming. 

Vulnerability Disclosure Programs (VDPs) offer a way for those outside your organization—such as customers or partners—to report vulnerabilities. VDPs are an essential part of a process that sets ground rules for reporting, offers legal, safe harbor to those who find vulnerabilities, and ensures that bugs are triaged and sent to the right person or team to be fixed. 

Bug bounties are similar to VDPs but incentivize hackers to search for vulnerabilities actively. Most dev teams know that they will miss something no matter how many pentests or scans they run. Bug bounties are designed to find what automated testing misses. Hackers often find logical flaws that allow for fraud—not something security tools typically look for. Last is the SIEM—an essential tool for any SOC to keep track of anomalous activity. 

Figure 2: HackerOne products shown in DevSecOps stages where they apply.

The bulk of the HackerOne products apply to applications that have been deployed. Most organizations do not want hackers—or any non-employee—in their source code.

HackerOne Retest is a service where organizations can ask hackers to test that their developers have fixed reported vulnerabilities. This service gives real-world assurance that the code has been changed successfully. Sometimes hackers will find workarounds to the fixes, so it’s helpful to have humans check. Failed tests, complete with any details on workarounds, are routed back to the developers.

HackerOne Assessments are often used against running cloud infrastructure and applications to look for common vulnerabilities. While frameworks like OWASP Top 10 are commonly used, HackerOne can also provide assessments using the latest observed vulnerabilities for a given cloud provider allowing organizations to test against the most current potential threats. Assessments can also be used for pentesting utlizing standard compliance frameworks like FISMA, ISO 27001, PCI, SOC2, etc. In some cases, Assessments are used in the staging environment to test new applications before deployment. Lastly, the Assessments platform can be used by internal staff to run periodic tests in the DevSecOps process pre-deployment.

HackerOne Response and HackerOne Bounty provide turnkey VDP and bug bounty program capabilities, respectively. Organizations can tailor their programs to fit their capacity. This is typically done by defining which applications and assets are in scope. Organizations can set the strategy on what they would like hackers to test, starting with a limited number of applications and websites and growing over time to include more applications and APIs.

While DevSecOps is clearly in the realm of application security, many hackers in bug bounty programs discover issues with infrastructure. It is common for hackers to report DNS weaknesses, storage misconfigurations, or exposed access keys. Hackers may also find hostnames during the reconnaissance process that are unknown to Dev or Ops teams. This helps these teams either reduce their attack surface or make sure these hosts are in scope.

Notably, reports from hackers are triaged, meaning a low number of false positives in contrast to SAST tools, and that the dev team correctly prioritizes vulnerabilities. Severe vulnerabilities get immediate attention.

As mentioned above, feedback from running applications goes back into the threat modeling process in the Plan stage. In addition to observations from vulnerabilities found, HackerOne Insights can be helpful to threat modelers. It provides vulnerability intelligence on similar industries and tech stacks so organizations can plan against threats on similar applications. Think of it as crowdsourced intelligence that is then made more specific to an organization.

Figure 3: HackerOne is integrated with developer and security products to help workflows.

HackerOne is integrated with several tools commonly used by development and security teams, allowing them to incorporate hacker-powered security into their DevSecOps process.

These tools fall into five main categories: 

• Developer Collaboration - Submit vulnerabilities to developers in Azure DevOps, GitHub, and GitLab.
• Software Testing - Submit CodeQL queries to GitHub Security Lab to find vulnerabilities in open source projects. When found and validated, submit to HackerOne for a bounty reward. Feed vulnerability findings as open issues into Kenna Security.
• Incident Tracking - Track vulnerabilities as security incidents and schedule remediation using Jira or ServiceNow. Feed high-severity vulnerabilities directly into PagerDuty to trigger alerts.
• Security Response - Send vulnerability intelligence into Splunk, IBM Security SOAR, and SumoLogic analysis tools to fortify threat data and reporting.
• Communications - Use Slack or Microsoft Teams to receive alerts when reports are submitted. Communicate directly with hackers to clarify and resolve reports. Alert security teams to critical vulnerabilities using PagerDuty.

One interesting partnership that we did not cover above is between HackerOne and HackEDU. Training developers to avoid common mistakes that affect security is a good investment. HackEDU takes things a step further by using actual vulnerabilities found by hackers as part of an organization’s bug bounty or VDP and using them in the exercises.

HackerOne has a lot to contribute to the DevSecOps process. Even if you already use security scanning tools, skilled hackers can find vulnerabilities that these tools miss—often of higher severity. These findings can be integrated into your existing security and development processes with tools familiar to your teams.