This article builds on a previous piece, Why You Should Invite Hackers to Hack You: The Benefits of Vulnerability Disclosure Programs, which laid out the fundamentals of Vulnerability Disclosure Programs (VDP). In this installment, I share past experience transitioning IBM’s in-house VDP to a VDP platform, HackerOne. I’ll be sharing insights and best practices for anyone looking to start, transition to a VDP platform, or refine their own program.
Initial Planning and Strategy
Joining the Team
In 2018, I joined a team responsible for handling activities typical of a product security incident response team and worked on transitioning IBM’s VDP from an in-house model to the HackerOne platform. This “crawl, walk, run” approach allowed us to start with a cashless rewards model and progressively expand the program. By evaluating outcomes early, we determined whether introducing monetary incentives would be beneficial.
Key Lessons Learned During Transition
Transitioning IBM’s VDP to HackerOne offered several important insights:
- Collaboration across legal, procurement, and engineering was essential for smooth execution
- Automation of workflows minimized errors and improved response times, allowing us to manage more reports
- Recognition sustained program momentum without monetary rewards, focusing on community engagement
- Scope expanded to cover all non-product areas, ensuring comprehensive security.
- Policies were clearly defined to set expectations and support compliance
Much of the initial groundwork had already been laid. Leadership buy-in was secured, and the tenured team was already assembled. With those key elements in place, I focused on strategic planning and execution to strengthen IBM’s security posture and enhance client trust.
Procurement and Legal Alignment: Laying the Foundation
Procuring the Right HackerOne Plan
Working closely with procurement, I secured an Enterprise plan from HackerOne that included robust API integrations and priority support, which is critical for a complex organization like IBM. This step ensured we could meet our program goals with the necessary technical capabilities.
Legal Considerations
Throughout procurement, I partnered closely with the legal team to ensure the HackerOne service agreement aligned with IBM’s policies around disclosure timelines, IP rights, legal liability, etc. I clarified cybersecurity concepts for the legal team to ensure accurate contract terms. For example, I helped shape terms around IBM retaining ownership of vulnerability reports. Resolving these complex legal details was mandatory before finalizing the HackerOne contract.
Setting Clear Program Policies
With HackerOne selected as our platform, I focused on defining operating policies and rules of engagement policy tailored to our program’s goals with the help of HackerOne. This included scope, guidelines, legal notice, establishing hacker vetting standards, and creating transparent rules of conduct.
Having IBM legal provide input was invaluable because they flagged potential risk areas related to hackers accessing systems, handling sensitive data, and more. I iterated on the policies until they struck the right balance for productivity and legal/security compliance.
Challenges During the Transition: Expanding Scope and Refining Processes
Expanding Scope Beyond Product Vulnerabilities
IBM’s VDP initially focused on product vulnerabilities, with other areas like websites routed to different teams, often with limited visibility, creating potential gaps.
To address this, we expanded our scope beyond products, covering websites and other areas. New intake pipelines and workflows were established, integrated with internal processes to ensure comprehensive coverage across IBM’s infrastructure. Effective communication was key to ensuring a smooth transition.
API Integration and Automation: Streamlining Workflows
One of the most critical elements of this transition was integrating HackerOne with internal systems to automate our workflows and improve data accuracy. Our internal development team, in collaboration with other teams, worked to ensure seamless data synchronization between platforms. The system would pull tickets from HackerOne, update statuses, and trigger specific actions based on ticket changes, ensuring that vulnerabilities were triaged and addressed efficiently.
Developing Custom Slack Integrations
I took the lead on developing the HackerOne Notifications/Events integration with Slack, leveraging various IBM Cloud services to host and trigger the following scripts:
- Response.py sent notifications for new reports that hadn’t had any activity over three business days or hadn’t been triaged within eight days, ensuring timely attention
- RoundRobin.py automated the distribution of new reports in a round-robin fashion, ensuring even and efficient workload management among team members
- OverDue.py sent alerts when reports were approaching or exceeding their severity-based resolution deadlines, prompting timely action to meet SLAs
These automation significantly improved our response times, allowing us to handle a higher volume of reports without missing any SLAs.
Security and Compliance: Prioritizing Data Protection
Throughout the transition, ensuring data security and compliance was a top priority. We implemented least privilege principles across the board, ensuring that only specific individuals had access to certain sensitive data. All data transfers between HackerOne and other internal systems were encrypted, both in transit and at rest.
HackerOne was particularly helpful when navigating the complexities of data security and handling sensitive reports. Their team provided mediation services and valuable support when dealing with hacker issues, including notifying us when a hacker expressed frustration with the program on X (formerly Twitter). Together with internal teams, we quickly resolved the situation, ensuring transparency and trust in the hacker community.
Conclusion
Transitioning to HackerOne significantly improved IBM’s vulnerability management process, reducing response and triage times. With enhanced visibility and streamlined workflows, we consistently met 100% of both platform and internal SLAs. This success enabled us to expand the scope of our Vulnerability Disclosure Program, strengthen our security posture, and underscores the value of collaboration, efficiency, adaptability, and clear communication in building and managing a robust VDP. The insights we’ve gained from this journey continue to shape our security approach, and I hope they serve as a valuable guide for others looking to enhance their vulnerability management practices.
Call to Action
If you’re looking to launch or enhance your VDP, or if you need guidance on navigating the complexities of cybersecurity, I’m here to help. Feel free to reach out for consulting, collaboration, or just to share your thoughts and experiences.
Acknowledgments
I’m grateful to Kay and Carlos from the IBM security team, who reviewed this article and provided invaluable perspective based on our shared experience building the program. I also utilized AI to refine and enhance the clarity of this article.
VDPs play a critical role in identifying vulnerabilities before they become threats, making them an essential component of an effective Vulnerability Management Program (VMP) strategy. For those looking to deepen their understanding of VMP, the Lonestar Application Security Conference (LASCON) will be held later this month in Austin, TX. It’s a premier event for security professionals, developers, and engineers. I highly recommend attending, especially to hear from experts like mauvehed, who will discuss key strategies for managing vulnerabilities and securing applications. Don’t miss the chance to connect and learn from leaders in the field.
