Hey My name is Rami (not Rami Malek). I was hired from the crowd and now work to improve the crowdsource security experience, often working behind the scenes. I’ve always had a laser focus on community and continuous improvement from my experience as a professional photographer, pentester, hacker success manager, and everything in between. My unique perspective and determination from my various career paths led me to understand various needs and communicate them to the right people in the right way. Now a part of the Customer Success team, I hope this blog post helps you find the highest value engagement(s) for your organization’s needs. 

Factors to consider before deciding on your engagement type

• Scope: First, you must determine the size and complexity of your digital assets and their potential vulnerabilities. This assessment will help you identify which engagement aligns best with your requirements.
• Budget: Different engagements come with varying costs. Consider your organization’s financial capabilities and evaluate the potential return on investment in terms of enhanced security.
• In-house vs. outsourced: Determine whether you have the internal expertise to handle the chosen engagement or if you need to collaborate with external cybersecurity experts.
• Regulatory compliance: Ensure that the chosen engagement complies with any industry-specific or legal requirements your organization must adhere to.
• Risk tolerance: Assess your organization’s risk tolerance and how much you are willing to invest in proactive cybersecurity measures.

1. Managed bug bounty engagements (MBB):

Managed Bug Bounty engagements incentivize independent hackers to discover and report security vulnerabilities in an organization’s digital assets. Customers then set a tiered reward structure based on the severity and impact of the vulnerability identified in accordance with the Bugcrowd Vulnerability Rating Taxonomy. Once a vulnerability has been submitted by a hacker the Bugcrowd Security Operations team will triage, reproduce and assess the vulnerability. This process eliminates the signal to noise ratio ensuring you’re notified of new and unique findings. Bugcrowd offers MBBs in multiple flavors to meet your specific needs: 

• Time-based:
  • Ongoing engagements
  • On-Demand engagements
• Visibility:
  • Public engagements
  • Private engagements

Ongoing vs on-demand bug bounty engagements

Ongoing MBBs allow hackers to engage with the customer environment over an extended period of time. Ongoing MBBs allow hackers to deliver high impact vulnerabilities over time, which may otherwise not be found through traditional testing methods such as penetration testing Ongoing MBBs provide time and space for hackers and customers to build rapport and establish a level of trust. It’s not uncommon for hackers with strong rapport to exclusively hack on a single engagement/customer as a result of this. I like to call them ‘anchor hackers.’ Some anchor hackers have even been offered full-time jobs!

The benefits of running an ongoing MBB include:

• Impactful and ongoing testing
• Integrates into your long-term security posture
• Provides an ongoing level of assurance external from your security team
• Introduces new hackers over time

On-demand engagements offer two primary differentiators from ongoing programs. Their timeboxed nature provides a highly competitive and rewarding environment for hackers. They may be used to compliment ongoing engagements or to differentiate from them.

The benefits of running an on-demand MBB include:

• Time bound approach: On-demand engagements offer 2 or 4 week timeboxes, providing hackers with a highly competitive environment with increased rewards and unique scope.
• Set reward pool: Using a fixed reward pool ensures customers don’t go over-budget while ensuring hackers are appropriately compensated for their expertise. Customers typically use on-demand engagements as a first step towards the crowdsourced security space, or where they may have flexible spending that may not allow for an ongoing engagement just yet.
• Targeted scope: The highly competitive nature of on-demand engagements allow smaller groups of hackers to target areas with great concern. Successful on-demand engagements are often used to test new features, business-critical systems, and used as a warm up prior to releasing the assets to an existing on-going program.
• Pen testing use cases: They are increasingly used in pen testing use cases as well; in fact, we have customers who have completely replaced traditional pen tests with them.

Public vs private bug bounty engagements

There are two visibility options for MBB engagements, public and private.

Public bug bounty engagements are open to everyone. They’re often a best fit for large organizations with a security team equipped or even dedicated to hosting a bug bounty engagement. Your organization is most likely already quite secure and braced for attacks.

Benefits of public engagements:

• Largest form of exposure 
• Largest talent pool available
• Community engagement
• Showcases strong security posture

Considerations before launching a public engagement:

• Requires skilled team to manage
• Significant exposure 
• Increased noise

Invite only (or private) engagements are highly sought after due to their scarce nature. Hackers often look for large scope, high rewards, and low competition in private invites. The scarce nature leads to highly motivated hackers with more potential opportunity to identify vulnerabilities and gain rewards. Participation requires an invitation by Bugcrowd or your organization. The scope, rules, and rewards are shared with the invited hackers, but not with the general public.

Benefits of private engagements:

• Controlled testing
• Increased confidentiality
• Competitive activity
• Tailored to your needs as an organization
• Segregates different stakeholders and entities
• Introduces crowdsource security in a safer manner in your organization.

Considerations before launching a private engagement:

• Increased crowd management 
• Additional effort to manage compared to public programs 

Overall, managed bug bounty engagements are a great fit for small and large organizations across the globe. If one of the following applies to your organization, managed bug bounty engagements may be right for you:

• You have a large-scale attack surface
• You want to tap into the collective power of a global security community to find diverse and hidden vulnerabilities
• Your organization is able to offer financial rewards to ethical hackers for their discoveries

2. Vulnerability Disclosure Program (VDP):

Vulnerability Disclosure Programs (VDPs) are a “see something, say something” model, offering a public space to safely submit and disclose vulnerabilities to an organization. 

Unlike MBBs, they focus on encouraging responsible individuals to disclose security vulnerabilities directly to the organization with Safe Harbor. While most organizations welcome this information and behavior, the lack of a defined channel or process can carry risk, often disincentivizing people to report vulnerabilities. VDPs offer a comprehensive range of submission channels, triage, integration, and reporting capabilities.

When to choose a VDP:

• Your organization is ready to take their first step towards crowdsourced security
• You value transparency and open communication with hackers
• Regulatory/government mandates may require you to have one
• You want to promote responsible disclosure within the security community
• Your organization is ready to acknowledge and address security issues promptly

3. Penetration testing:

Penetration testing is a controlled and simulated cyberattack on a system, network, or application to identify weaknesses that could be exploited by malicious actors. Unlike bug bounty engagements, our crowd powered Pen Testing as a Service (PTaaS) is carried out by a large vetted pool of skilled hackers from the crowd. They simulate real-world attacks to assess vulnerabilities and provide a detailed report of their findings offering expertise unmatched by traditional pentesting services. According to your testing requirements, our specialized team and our agile processing can yield results in a matter of days. Throughout the testing phase, you will use the Bugcrowd Platform to gain access to real-time, prioritized findings, facilitating prompt remediation actions.

It’s common to see organizations pair their pentests with a bug bounty engagement to maximize risk reduction. 

When to choose penetration testing:

• Pay-for-effort in a time bound approach
• Leverage hackers with specialist skillsets and experience.
• Governance risk and compliance requirements
• Risk posture requires testing to be performed in a specific manner

4. Attack surface management

Bugcrowd’s Attack Surface Management (ASM) goes beyond traditional vulnerability assessments. Most hackers will tell you reconnaissance (recon) is arguably the most important step in the hacking process. Sw33tlie emphasizes recon over time in this blog post. Levering the power of the crowd, ASM combines technology, data, and hacker ingenuity to discover all digital assets (even the hidden ones) within an organization’s ecosystem. By identifying rogue assets, it helps your organization evaluate risk, inventory known assets, and prioritize remediation efforts. It offers a comprehensive approach to managing an organization’s attack surface continuously.

When to choose attack surface management:

• You want a holistic view of your organization’s cybersecurity posture, including forgotten, rogue, or unknown assets.
• You want to discover assets, not exploit them.
• You have a rapidly evolving organization with a complex attack surface to manage.
• You need a solution to help you continuously discover, prioritize, and mitigate risks associated with your assets.

The world of crowdsourced security can be confusing, but by carefully evaluating the options and understanding your organization’s specific needs and priorities, you can make an informed decision that aligns perfectly with your cybersecurity goals.

Thanks for taking the time to read my blog post. If you’re still hungry for more, you can learn about the role of our TCSM team in continuing your success with crowdsourced security, written by my good friend Elle. 

You can find me on Twitter, and LinkedIn. I’d love to hear from you!

The post Demystifying crowdsourced security: How to choose the right engagement for your organization appeared first on Bugcrowd.

Differences between pen testing and bug bounty engagements

Let’s break down each offensive security strategy. Pen testing is a simulated cyberattack carried out by an authorized third party (known as pen testers) who tests and evaluates the security vulnerabilities of a target organization’s computer systems, networks, and application infrastructure. Pen tests are performed by external testers, are typically time bound, and usually follow a testing methodology. Generally, pen testing customers usually expect a final report after the engagement is complete that they can present to an auditor to demonstrate regulatory compliance. 

Bug bounty engagements work by engaging with the global hacker community to find unknown vulnerabilities in your systems. This is done through a “pay for impact” economic model that incentivizes impactful results, meaning the more critical the vulnerability, the higher the reward. 

Pen testing and bug bounty engagements have similar goals, but can have different levels of intensity of the assessment. Pen tests are fit for checklist-driven discovery of common vulnerabilities. Bug bounty engagements cover finding hidden flaws that pen tests might miss.

Reasons to combine pen testing and bug bounty engagements

Combining pen testing and bug bounty engagements into a single program with shared scope, integrations, credentials, and submissions is an effective way to achieve true risk reduction while addressing compliance needs. Here are three reasons why combining pen testing and bug bounty engagements is a best practice:

1. Continuous protection—Combining solutions gives organizations the scale and agility needed to stay ahead of today’s biggest threats, like AI, and tomorrow’s unknown challenges. 
2. Solve for multiple needs—When bringing together the tried-and-true power of pen testing with the scale and efficiency of a bug bounty engagement, organizations solve for multiple needs while improving proactive threat detection. 
3. Get more high-impact results—Using these solutions together goes beyond compliance checklists and helps organizations find up to five times more high-impact vulnerabilities.

Introducing Max Pen Test

Max Pen Tests give you the best of both these worlds in a single package on the Bugcrowd Platform. In addition to delivering your auditor report, we’ll document prioritized vulnerabilities uncovered by tens or even hundreds of trusted testers specifically selected for their skill set, who are rewarded based on the impact of their results. Findings are viewable 24/7 in your dashboard, and if desired, flowed directly into DevSec workflows for fast remediation.

Unlike traditional time-boxed assessments, Max Pen Test engagements can also run continuously, in support of agile development cycles. As code is continuously updated, you’ll rest easier knowing your targets are being continuously assessed for new vulnerabilities. 

The average Max Pen Test user finds 3-5x more high-impact vulnerabilities versus standard pen testing alone, which greatly reduces the cost per vulnerability. 

Speak with an expert about Max Pen Test and see if it’s right for your organization. 

The post Max Pen Tests: Combining the power of pen testing and bug bounty engagements appeared first on Bugcrowd.

While their reward strategy has led to rapid company growth, it has also increased infrastructure complexity and the number of cloud security threats. As such, Tango’s security team faced a growing number of new and unpredictable threats. Despite the team’s competency, Tango recognized the need to enhance its capabilities by collaborating with a robust crowdsourced security platform.

Tango’s priority was to secure sensitive transaction data for its clients while continuing to innovate. The company is committed to combating threats, bad actors, and security incidents. Above all, it wanted to uphold and enhance its brand reputation through a proactive approach to risk reduction. However, rapid digital transformation and an expanding attack surface have proven to be significant challenges.

This aligns with the challenges that other financial services organizations are currently facing. According to Inside the Platform, the financial services industry had an 11% increase in the amount of crowdsourced security vulnerability submissions in 2023. Financial services institutions were historically one of the first industries to adopt crowdsourced security, and the sector has experienced continuous growth with crowdsourced security adoption in the past decade. 

To address these challenges, Tango enlisted the Bugcrowd Platform. Leveraging Managed Bug Bounty, Tango teamed up with hackers to find vulnerabilities in its services that are beyond the reach of automated tools. This collaboration enhanced Tango’s security posture and competitive edge while mitigating potential risks and strengthening customer trust. “Bugcrowd has transformed the way we approach identifying new cybersecurity attack scenarios,” said Tango’s VP of Information Security Monica Bush. “The Bugcrowd platform has enabled us to tap into a diverse pool of talent and has been vital in augmenting our team in identifying and addressing vulnerabilities.”

Managed Bug Bounty helped Tango better secure its customers’ transactions and keep up with the ever-changing threat landscape. By integrating the identification of vulnerabilities into their existing DevSec tools and processes, Tango’s developers could fortify new features against potential threats. “Bugcrowd partnered with us to identify hard-to-find security weaknesses and provide rapid notifications so the team may address corrections asap,” said Monica Bush. “Bugcrowd’s approach to security has allowed us to focus on our core business, knowing that our systems are in safe hands.” Bugcrowd’s reporting and validation processes also significantly contributed to ensuring Tango’s compliance with security audits and regulations.

Tango’s collaboration with Bugcrowd exemplifies how the alignment of security strategies with rapid innovation can address complex cybersecurity challenges. This partnership has helped Tango secure its operations, preserve its brand reputation, and prepare for future growth. Tango plans to continue working with Bugcrowd, focusing on scaling its bug bounty program and adapting it to new products, services, and technologies.

Check out the case study to read the whole story.

The post Tango incentivizes trusted hackers to secure its incentive program appeared first on Bugcrowd.

In 1854, the window of Bramah and Co. at 124 Piccadilly in London sported a lock next to a small printed board, which stated: “The artist who can make an instrument that will pick or open this lock, shall receive 200 Guineas the moment it is produced.” 

This is the first known example of a security bug bounty, where the lock’s manufacturers incentivized experts to find vulnerabilities in their product. It reassured the manufacturer that they should be among the first to know if their product had a weakness, and advertised the strength of their security to the wider public. And, of course, the lock was eventually picked, by the American proto-hacker and security professional, Alfred Charles Hobbs.

This blog will define bug bounty programs and cover what to expect when signing up for a bug bounty program, how they operate, and how security teams can make the most of them. 

What are Bug Bounty Programs?

Bug bounties have evolved since the 1850s, really coming into their own 140 years later with the growth of the internet and Netscape’s decision to implement a bug bounty program in 1995, which offered financial rewards to developers who found and submitted security bugs in the browser Netscape Navigator 2.0. This approach was taken up by Mozilla, Google, and Facebook in the following years, before being formalized in a third party offering by Casey Ellis with the founding of Bugcrowd in 2012.

These programs are results-focused security initiatives that incentivize hackers to uncover and report security vulnerabilities. They provide ROI by offering financial rewards based on the criticality of bugs submitted, and simulate the actions of malicious actors to find and fix issues quickly.

Before getting into it, we should note that there are internally run bug bounties, just as there are internally run server farms, but this post will focus on managed programs, as they are almost universally considered more cost-effective and usable. If an AI company reportedly valued at $86 billion and focused on safety as a top concern works with a third party for its bug bounty program—not to mention tech giants like Microsoft and Google, plus highly-risk conscious government customers—then you can safely consider it to be best practice.

What are the Benefits of Bug Bounty Programs?

Bug bounty programs are effective because they: 

• Greatly reduces cost per vulnerability compared with other security solutions
• Engage a diverse group of hackers by tapping into a broad array of talent
• Allow you to stay on top of the always-evolving landscape of security threats due to the principles of bottom-up competition in the platforms that that fosters continuous improvement and perpetual learning
• Offer a cost-effective way to discovering vulnerabilities and triage risks that internal security teams may miss
• Contribute to a reputation for taking security seriously among hackers and the broader security community by being willing to invest in results
• Provide continuous assurance that allows you to maintain the highest standard of security for critical assets
• Provide better line-of-sight into security ROI than traditional approaches by directly aligning costs with vulnerabilities based on their impact

Who Participates in Bug Bounty Programs?

Contributors to bounty programs are security experts who like to find novel ways of using and considering tools and processes, or hackers. Like Mr. Hobbs mentioned above, they are passionate about using their skills to improve security and thwart crime, and in today’s digital world, their skills are sorely in demand.

Contrary to their depiction in the media, most hackers are ethically motivated, applying their skills to help companies protect themselves rather than pursuing more lucrative opportunities in the black and gray markets. Bugcrowd’s Inside the Mind of a Hacker shows that 75% of hackers identify non-financial factors as their main motives to hack, and 96% believe that they help companies fill their cybersecurity skills gap, so they are a considerable force for good.

Hackers contribute to public bug bounty programs in a Darwinian market that is bottom-up, meritocratic and open to the world. This ensures program owners always have access to the latest skill sets and techniques, while incentivizing hackers to stay on top of the latest trends and developments.

You also have the option to buy private bug bounty programs, where only invited hackers can partake. This allows you to select for researchers from specific countries or backgrounds, with some providers even allowing you to restrict participants to those with security clearance.

What Services do Managed Bug Bounty Providers Offer?

Even the most sophisticated software and security companies work with third parties to manage their bug bounty programs. Handling the function internally means building and maintaining a software platform, as well as handling and triaging a potentially large volume of submissions. Add to this the need to staff the platform with security professionals in a market where talent is scarce, and it becomes apparent why so many companies opt for managed programs. 

Overall there are several services that you should look for from a managed partner:

• Validation and triage: separating signal from noise is the most important part of any bug bounty program. Platforms add value by quickly identifying invalid or duplicate submissions, triaging based on criticality and ensuring bugs are fixed and hackers paid promptly.
• Custom curation of The Crowd: matching hackers to jobs based on skill set, performance, experience, and other metrics makes the process more efficient and helps you get results faster. Platforms that do this well rely on AI and advanced algorithms to match hackers to programs.
• Remediation at the level of SDLC: identifying bugs and fixes is only half the battle. Platforms should ensure that these fixes can be implemented within the SDLC to make the remediation loop as tight as possible. 
• A SaaS platform built for multiple use cases: crowdsourced security is broader than just bug bounties, and the best providers will offer platforms that integrate with pen testing as a service, attack surface management, vulnerability disclosure, and similar security solutions.

What is the Difference Between Bug Bounty Programs and Penetration Testing?

Penetration testing, or pen testing, is a service where external testers mimic attackers to identify security vulnerabilities in a company’s assets. These tests are typically time bound and work to established methodologies, and they provide a final report that can demonstrate compliance to regulatory bodies. This sets them apart from bug bounty programs, which identify vulnerabilities based only on hacker ingenuity and can operate continuously.

Penetration Testing as a Service (PTaaS) is an improvement to bring the practice in line with modern capabilities. It simplifies and accelerates onboarding, provides integration with the SDLC and other crowdsourced security services, and speeds up the reporting process, all while maintaining the core strengths of operating to defined methodologies and offering clear reporting.

Pen tests and PTaaS are more appropriate if you:

• Have specific compliance requirements to meet industry regulations like HIPAA or PCI DSS, and require a pen test with a formal reporting function
• Want to take a “pay for time” approach to ensure coverage based on a predetermined checklist/methodology
• Have internal controls that require time-bound testing of new products or functionality before they ship

Bug bounty programs are more appropriate if you:

• Want to take a “pay for impact” approach to incentivize the discovery of high-impact vulnerabilities without a predetermined checklist or methodology 
• Are looking for a wide range of hackers to apply their skills and experience to the problem to find novel vulnerabilities and fixes
• Want 24/7 coverage of your assets

As you can see, these are complementary rather than competitive services, and companies that take security seriously will typically invest in both services and integrate them on a crowdsourced security platform. For more details on the differences and complements between pen testing and bug bounties, see the Bugcrowd blog on the topic.

What Factors to Consider Before Starting a Bug Bounty Program

• What is in scope? You pay for results, but some results are more valuable than others. Start with a narrow asset range and look at the capacity that this demands. Once you have a good indication of ROI, expand it based on your resources and strategic priorities.
• Public or private? It helps to start small, with a private bounty program that matches the most relevant hackers to your task. Once you’re comfortable with the rate of vulnerabilities uncovered and their remediation, open it to the public to make the most of The Crowd’s collective intelligence.
• On-demand or ongoing? Continuous coverage is the best way to identify security risk quickly and effectively, but not every development environment can keep up with submissions and security budgets might not stretch to cover this level of work. You should start with a point-in-time program, then extend it when you’re comfortable with ROI and confident in the agile development methods needed to make fixes quickly.
• Which integrations to prioritize? Bounties come with operational challenges, and getting the development side right means being confident about integrating with your back end. A good bug bounty program should integrate into the SDLC and work with developer and project management tools like JIRA, GitHub, Trello, and Slack.

How to Develop a Bug Bounty Brief

There is enormous security talent available in The Crowd, but it’s only as useful as your ability to harness it. Getting the brief right sets expectations for hackers and gives direction on what success looks like. Providing a concise, unambiguous brief gets you results quickly and more effectively and reduces the need for triage.

The brief should set out the below.

• Scope – Clearly sets out the assets that are in range for testing, leaving nothing open to interpretation. Narrow scopes are better for beginners, but not so narrow that it is unattractive to hackers or fails to add security value.
• Focus – Adds context to scope by highlighting areas that are particularly important to you. This can include bug types, specific functionality, new features or similar subjective properties of your assets.
• Out of scope – Further clarifies scope by stating what is ruled out. The most common example is hosts that resolve to third party services.
• Rewards – Expected payouts, this should be correlated to market prices to ensure you’re attracting the right talent.
• Disclosure – Whether, and how, hackers can expect to take credit publicly for bugs found. We recommend public disclosure to build strong relations with hackers and demonstrate an understanding of security dynamics, but it is your decision.

TL;DR–Bug Bounty Programs

Bug bounty programs rely on harnessing the skills of the world’s security talent, known as The Crowd. They offer continuous coverage for assets and quickly surface novel vulnerabilities, while pairing well with formal and compliance-based security such as pen testing. Making bug bounties work for you means knowing the strengths of the program and planning your brief and financial incentives to maximize these strengths. Getting the most out of the program means knowing the strengths and how to pair it with other solutions like PTaaS and Attack Surface Management.

Bug Bounty Program Resources

• The Ultimate Guide to Bug Bounty Programs
• Managed Bug Bounty Data Sheet
• 10 Ways to Save with Bug Bounty Programs Infographic
• 6 Questions to Ask Before Starting a Bug Bounty Program
• Understanding Bug Bounty Scope Data Sheet
• The Anatomy of a Bug Bounty Brief

The post What is a Bug Bounty Program? appeared first on Bugcrowd.

Rapyd is a cutting-edge fintech leader focused on helping businesses create great commerce experiences anywhere. It had been using crowdsourced security for years, but about a year ago, it made the switch to Bugcrowd with the goal of launching a public program, which it did six months later. 

Rapyd has experienced outstanding results so far, uncovering almost 40 unique and valid vulnerabilities—15 of which were critical. We spoke to Achiad Avivi, who is responsible for application security at Rapyd, for his advice on how to successfully take a bug bounty program public. 

Tip 1: Find the right hackers for your program and engage with the community.

While your program is still private, focus on finding specialized hackers for engagements so you have the right fit. By picking the right hackers for specific programs, researchers remain engaged, setting up a future public program for success. Be sure to respond quickly to hackers and engage with them to build positive relationships and a good reputation. 

Tip 2: Build confidence in your security posture across the organization.

Be sure you have the right roadmap in place before launching a public program. We worked with Bugcrowd to build this. Our entire team participates in the strategy and operations of our program. We’ve integrated the platform with numerous DevSec tools for tracking program findings and routing to the appropriate stakeholders. By preparing our process in advance, we felt confident in going public. 

Tip 3: Leverage unparalleled expertise from the Bugcrowd team.

Launching a public program is a journey, not a destination. We haven’t stopped looking for ways to continuously improve our program, and we work very closely with the Bugcrowd team via email, meetings, and Slack for advice on how best to do this. I encourage you to take similar advantage of these channels. 

“We quickly felt safe to take our program public with Bugcrowd. We value the way Bugcrowd finds the right hackers with the right expertise for our programs.” – Achiad Avivi, applications security, Rapyd

Learn more about Rapyd’s journey with crowdsourced security. 

The post 3 Steps Rapyd Took to Make its Program Public appeared first on Bugcrowd.

For customers that are new to crowdsourced cybersecurity, the differences between these two options may not be obvious. This blog will help you better understand which program to use when.    

The Rise of VDPs and MBBs

VDPs have been around for some time, but have really started gaining momentum the past few years as companies increasingly digitize their infrastructure. Last month, Google and Salesforce announced the Minimum Viable Security Product (MSVP), a vendor-neutral security checklist designed to help organizations ensure the minimally viable security posture of a product. The first of its recommendations is the creation of a Vulnerability Disclosure Program. In 2020, the Cybersecurity and Infrastructure Security Agency (CISA) also released a binding directive that makes VDPs a requirement and requires federal civilian agencies to remediate vulnerabilities (catalog of known vulnerabilities) within specific timeframes

Things are also heating up on the managed bug bounty side. Google has kicked off a three-month Bug Bounty Program—with triple researcher rewards—focused on identifying  flaws in the Linux kernel.

The Difference between VDPs and MBBs

VDPs and MBBs are now critical tools to have in your security toolbox, but which tool should you use for which job? Let’s compare:

• VDP: A VDP is a secure, publicly available channel for anyone to submit security vulnerabilities to organizations, helping them mitigate risk by enabling the disclosure and remediation of vulnerabilities before they are exploited by bad actors. In contrast to bug bounties, submissions are not incentivized by cash rewards. Publishing a vulnerability report after it has been fixed is another common attribute of VDPs, and gives researchers the opportunity to share knowledge and enhance their own reputation in the process.
• Public MBB: A public MBB allows anyone to participate in the bug bounty program. It’s similar to a VDP but with the addition of cash and other rewards to incentivize proactive testing. Another trait of MBBs is that testing efforts are directed by the organization themselves to specific areas where security is deemed most critical.
• Private MBB: Private MBBs are often narrower in scope than their public counterparts (e.g., more tightly focused on specific targets). Researchers are incentivized by cash bounties (aka “pay-for-results”). Private MBBs limit participation to handpicked researchers, which allows for targeted skills matching, along with background checks, geographic selection, and so on.

Understanding Use Cases for VDPs vs MBBs

The easy answer to the question of which to use is, “it depends.” But I’m going to put a stake in the ground—a vulnerability disclosure program should be a baseline security standard for everyone, as common as a firewall. All code contains vulnerabilities, even when much has been done to prevent them. According to Coralogic, the data logging analytics company, on average, a developer creates 70 bugs per 1000 lines of code.  A VDP establishes  a “see something, say something” mindset within your organization that carves out a global channel for vulnerability reports and publically demonstrates that your company is doing everything possible to protect its customers, partners, and suppliers.

Even if your company begins its crowdsourced cybersecurity journey with something other than a VDP—like a MBB or pen test—a VDP remains a foundational element.

Alternatively, organizations can start with a private MBB program too. This was the path that Motorola took when it launched a private MBB with Bugcrowd. After the success of its private bug bounty program, Motorola wanted to open a channel to showcase security maturity and interact with the wider researcher community. This drove it to launch a “neighborhood watch” in the form of a VDP.  Motorola did what made sense for its business by going with a managed bug bounty program before rolling out a vulnerability disclosure program. The end result was the same—happier customers and safer products!  

Private MBB is also often used as a similar crawl-walk-and-run rampway toward a public bug bounty program. Public MBB works well for organizations who can fix discovered security flaws in a short period of time, through team resourcing and software development lifecycle (SDLC) integration.

How VDPs and MBBs Address Security Challenges

All these options help organizations deal with the chronic difficulties they have in attracting and retaining the right security skills (aka overcoming the skills gap). Those obstacles are exacerbated by the constant need to move faster, to deploy more infrastructure and applications—demands which in turn create more and more attack surface to defend. And of course, the relentless creativity and ambition of attackers is an ever-present challenge. All of these impediments are greatly lessened with crowdsourced cybersecurity as delivered by VDP and MBB programs.

Of all the options, public MBB has garnered the lion’s share of attention. It’s often the thing people immediately think of when they hear the term “bug bounty”. If your organization is mature enough to want to attract the broadest possible range of talent, and make an even stronger statement about its commitment to security to the public, a public MBB shines.

Now that you have an understanding of VDP and MBB, where do you go from here?

Bugcrowd Can Help 

Combining VDPs with MBBs is a very common approach among Bugcrowd customers. For both types of programs, we provide everything you need to ensure efficiency, return on investment (ROI), and maximum impact.

Bugcrowd’s crowd-powered SaaS platform is built for multiple security use cases. Bugcrowd facilitates hundreds of managed VDPs, escalating high-priority issues within hours and averaging triage completion within one business day. Moving from a program (VDP) to another program (e.g., a managed public bug bounty) can be done via the platform as well. 

Start your VDP journey on the Bugcrowd Platform with an easy self-service option. Per month pricing and the ability to use a credit card are available here. Get started today and let the Bugcrowd Platform start finding vulnerabilities.    

The post Vulnerability Disclosure Program or Managed Bug Bounty: How to Determine which Program is Best for You appeared first on Bugcrowd.

At Bugcrowd, we strongly believe that:

• Appropriately rewarding hackers (see our rewards recommendations below) is an absolute requirement for all-around success in bug bounty, and
  
• The economic benefits of fair, market-rate payouts far outweigh their cost.

Let me explain why.

Case Study: MOVEit Transfer Vuln

The infamous MOVEit Transfer Critical Vulnerability (CVE-2023-35708) is a good example of how a relatively modest bug bounty reward would have paid for itself many, many times over. 

As the Russian-speaking cyber syndicate Clop orchestrated a wave of extortion against numerous companies last season, the narrative was dominated by the scope of the incursion: numerous compromised organizations, personal data of millions siphoned, and copious volumes of sensitive information leaking into the dark web.

Central to this attack was the deployment of a zero-day exploit. Whether this vulnerability was a product of Clop’s own cyber reconnaissance – or, what seems more probable, procured from a dark web forum – it provided a digital crowbar to pry open defenses. Sifting through dark net forum posts reveals indicators that threat actors were actively paying large amounts of money for high-impact vulnerabilities:

Now let’s take a look into the known impact of the MOVEit Transfer vuln on organizations and individuals, to date:

Impacted organizations: 2,561
Impacted individuals: 67,174,909

In cybersecurity economics, quantifying the financial fallout of security incidents is napkin math. But it is very feasible to sketch an illustrative financial portrait by drawing from statistics reported in IBM’s Cost of a Data Breach Report 2023. If we apply the average toll of a data breach for each compromised record (US$165) to the tally of confirmed individuals affected by the incident, the estimated financial impact is a staggering US$11.08 billion. That figure speaks for itself!

Thinking ahead

When we speak with CISOs, it is common to hear the concern that implementing a robust bug bounty program will require a financial investment that can strain limited budgets. However, short-term thinking often leads to long-term problems.

For the sake of argument, let’s assume that a program commits to paying on the higher end of our suggested reward ranges with a payout of US$20,000, not US$5,000, for each critical vulnerability (and this assumes only one is found). The long-term impact would include:

• Long-term cost savings: Investing in a comprehensive bug bounty program can lead to substantial long-term cost savings because the cost of addressing a security breach far exceeds the cost of a $20,000 bounty payout: Per the Cost of a Data Breach Report 2023, the average total cost of a data breach is well over $4 million.
• Protection of brand reputation: The impact of a cyber attack on a company’s reputation can be devastating and long-lasting. Customers lose trust in brands that fail to protect their data, leading to churn and lost revenue. Customer trust is an invaluable asset that, once lost, is costly to regain–far more costly than $20,000.
• Competitive advantage: A strong security posture can be a competitive differentiator. Companies that demonstrate a commitment to security attract more customers and partnerships. A well-funded bug bounty program signals to the market that a company is serious about security, potentially giving it an edge over competitors. You could never buy that reputation with a paltry $20,000 marketing campaign.
• Avoidance of potential fines, legal fees, and insurance premiums: As we described in a previous post, a significant breach can lead to millions in downstream costs–making that $20,000 look like a really good investment.
• Access to expertise on-demand: Bug bounty programs on the Bugcrowd Platform crowdsource the expertise of the global security community, offering access to a diverse range of skills and perspectives that internal teams may lack. This access to a broader knowledge pool can augment, extend, and enhance a company’s security team far more effectively than relying solely on internal resources. Without it, do you have the ability or the funds to employ experts for every skill and asset 365 days a year?

Hackers agree: Per Bugcrowd’s 2023 Inside the Mind of a Hacker report, 84% of them believe that most organizations do not understand the true risks of a breach.

New recommended reward ranges

For the reasons above, there is no downside to scaling your program toward even the upper range of market-rate payouts over time. (Also keep in mind that your program is competing with others for hacker attention, and money talks.) In support of that point and to reflect the current marketplace, we recently updated our recommended reward ranges for bounty programs – informed by benchmarking the most successful programs on our platform after mapping hundreds of thousands of data points about vulnerability types, severity levels, and payouts:

Respecting these recommendations is not only a proven method for enhancing impact, but it’s also the right thing to do for hackers who invest a lot of time in uncovering weaknesses that you want to hear about before potential threat actors do.

As market rates adjust over time, we continue to gather data about what makes successful programs work, and new categories (such as AI) emerge, we’ll make adjustments to these recommendations, as well. 

The post Why Bug Bounty Payouts Are Worth Far More Than Their Cost appeared first on Bugcrowd.

ExpressVPN takes the privacy and security of its users seriously. Since it operates in the privacy and security space, a security breach is a serious potential issue which could result in the loss of trust from its users. ExpressVPN was concerned about attackers obtaining access to its VPN infrastructure and compromising users through the use of its apps. As part of its in-depth security strategy, ExpressVPN decided to select a managed bug bounty provider as a way to continuously review its products and services and provide the most secure user experience possible.

ExpressVPN has been using the Bugcrowd Platform for managed bug bounty since 2020. Brian Schirmacher, Offensive Security Manager at ExpressVPN, has worked in lockstep with Bugcrowd to ensure the products ExpressVPN delivers to users are as safe as possible. “Bugcrowd allows us to become aware of vulnerabilities in areas we don’t have oversight on, such as vendors making changes to third party integrations without notifying us,” Schirmacher said. The ExpressVPN public program has uncovered nearly 100 valid vulnerabilities to date, and continues to see results as skilled hackers join the program. 

Before Bugcrowd, ExpressVPN was running a self-managed bug bounty program. One key benefit of using the Bugcrowd Platform has been its focus on engineered triage for rapid validation and prioritization of vulnerabilities, which lets ExpressVPN’s engineers focus on remediation instead of filtering noise. Bugcrowd has also streamlined reporting and the reward and disclosure processes. 

ExpressVPN has also found value in Bugcrowd’s CrowdMatch technology, matching the right hackers with the right skill sets to its needs—resulting in both a higher number of hackers reviewing its products and a more specialized group of hackers relevant to its scope. 

ExpressVPN values the straightforward nature of the Bugcrowd Platform. “Bugcrowd offers reasonable terms without some of the admin/overhead/transaction fees that other players in this space have begun to add on. They’ve focused on their core service offering and ensured their primary product continues to meet customer needs,” Schirmacher said. 

Another key differentiating factor for ExpressVPN is the heavy focus that Bugcrowd takes on acting as an independent mediator between companies and hackers. This helps maintain trust, and is a huge priority for Bugcrowd. 

Learn more about ExpressVPN’s Bug Bounty program here. 

The post ExpressVPN Uses Crowdsourced Security to Continuously Improve its Security Posture appeared first on Bugcrowd.

A duplicate (in the bug bounty world), is a report for an issue that was previously known or identified. However, when determining whether or not a given finding is truly a duplicate, the solution isn’t always cut and dried. Many situations require a non-trivial amount of nuance and context. To help with duplicate evaluation in these cases, we’ve put together a guide for a few common duplicate scenarios, where we explain how Bugcrowd looks at these situations, and how we recommend clients approach them as well. As we go through these scenarios, there are three key principles to keep in mind:

• Touch the code (or make a change), pay the bug

1. 1. • If a finding causes you to make a change—and is in scope + is a vuln that’s rewarded as part of the program brief—it should be rewarded.

• Similar != same

1. 1. • If a finding is similar to another finding, but requires a separate change, it is a unique issue that needs to be rewarded independently.

• Many != systemic

1. • Just because there are many of a particular vulnerability type, that doesn’t mean they’re all part of the same root issue.

The importance of context and nuance in duplicate evaluation

As a quick note, when triaging findings, Bugcrowd’s engineered triage takes all of the above into account (to the best of our abilities—as there are extenuating circumstances in some cases that we don’t have visibility into). We leverage our ML-powered de-duplicate detection, contextual intelligence from over a decade’s worth of data on vulnerabilities, and human validation to perform a thorough review of any and all findings that come into the platform to ensure (1) duplicates are properly identified; and (2) all unique issues are elevated for review by the client. 

Scenario #1: Multiple SQLi Vulnerabilities

• A researcher has identified ten SQLi vulnerabilities across your application for a number of different queries and resources. Since they are all SQLi, you decide to pay for one finding and mark the others as duplicates.

This approach is misguided because multiple vulnerabilities of the same vulnerability class does not equal them all being the same vulnerability. Seeing a large amount of the same vulnerability class reported on a single asset is fairly common—when there are one or two of a vulnerability type, there are usually a lot more. This may be due to the same developers making the same mistake(s) in different places across the attack surface. Like birds, vulns of a feather commonly flock together. 

Assessing Vulnerability Clusters and Determining True Duplicates

In situations like this, it’s important to realize that even though there are many of the same type of vulnerability, they’re sprinkled across the application in different contexts. This means that it’s highly unlikely that they’re all one fix. 

Some of them might be true duplicates. If fixing one removes the need to fix another, refer back to principle #1 from above, “touch the code / make a change, pay the bug.” If, as a result of fixing a vulnerability, one no longer needs to touch the code or make a change to fix another finding, then the latter is truly a duplicate of the former. 

Ensuring Fair Recognition and Reward for Unique Findings

However, it’s imperative that we only mark something a duplicate if it’s truly a duplicate (e.g. fixing the parent finding removes the need to fix the duplicate finding). In the case of having ten SQLi scattered across the application, if we try to reward only one finding and dupe the rest, that’s tantamount to saying that only one change to one area of the codebase was made as a result of those issues. If we look at the situation honestly, had the researcher only reported one of the ten SQLi issues, and that issue got fixed, there would likely still be at least nine other vulnerabilities floating around even after the first one was remediated—because each requires a unique fix. It may be tempting to assert that they’re all one-in-the-same, but that is very rarely the case.

THINGS TO KEEP IN MIND

In some cases, some might assert that implementing a WAF (or WAF rule) could count as a single “fix.” For instance, one could implement a WAF rule that blocks any injection of double quotes that were otherwise required for the SQLi vulnerability. In doing so, all the SQLi issues are no longer exploited, and are thereby “remediated.” However, from Bugcrowd’s view, findings need to be rewarded from the perspective of how they would be remediated in the underlying codebase, and not at the WAF layer. Adding a WAF rule or similar blocking mechanism is a half-measure that will invariably have a hole of its own at some point in the future that will leave the still-vulnerable application underneath exposed. There’s no shortage of WAF bypasses or other creative mechanisms that researchers have found to get around these controls, and as such, (1) any remediation should always start at the application layer; and (2) rewards should be administered based on fixes to the codebase, and not the WAF.

Scenario #2: Reflected XSS Vulnerabilities with Common Parameters

• A researcher identifies 15 reflected cross site scripting (XSS) vulnerabilities across a number of pages on your application—however, they usually end in one of three parameters “page=”, “id=”, and “utm=”. Since they are all on unique pages (e.g. /view, /news, etc), and we previously talked about how it’s important to pay for all unique issues, you decide to pay for each finding independently.

This is partially correct, and partially incorrect. It is correct in that we want and need to reward for all the unique findings, given that these issues appear to be originating from three unique parameters. The most common outcome here is that there would be three unique findings (one for each vulnerable parameter), and the rest would be marked as duplicates of the initial issue for each parameter. 

Understanding Duplicates in Multi-Parameter Vulnerability Scenarios

But this is not always the case. Sometimes the same parameter name may be handled differently by different pages—this can be evaluated by looking at where the injection is reflected back on the page, and if it’s the same place for each parameter on each page. If that’s the case, they’re likely the same issue / underlying function applied on the different pages—despite appearing on unique urls. In cases like this, fixing the underlying function will remediate the issue on every page where that function is called, and so Bugcrowd will automatically mark each initial finding as unique per parameter, and then mark all subsequent ones for those parameters as duplicates. 

THINGS TO KEEP IN MIND

It’s worth noting that in a good number of cases, even multiple parameters will be duplicates of the other parameters across the same or multiple pages if they’re fundamentally part of the same issue. A good example of this is when the page url is printed in the page content. In such cases, the url could have 30 parameters, or even a fake parameter added to it would all be reflected back in the page via the same function on the backend—which again would only take a single fix to remediate, and thereby only be eligible for a single reward across all the parameters and pages that have this issue.

In doing so, we’re adhering to the principles outlined earlier: paying for all the places where the code is being changed (once per underlying function that will be fixed per parameter), and also keeping in mind that “similar != same.”

Scenario #3: CSRF Findings on Multiple Pages/Endpoints

• A researcher submits 50 cross site request forgery (CSRF / XSRF) findings against the application for every available page/endpoint, since there is no anti-CSRF token present anywhere on the app. Since they’ve identified 50 points where there’s an issue, should they be paid out for 50 findings? 

This is where our third principle of duplicates comes into play: many != systemic. As we saw in the first and second example, many issues of a vulnerability class doesn’t mean that it’s automatically systemic, or that it should be condensed to a single finding. With certain bug classes though, it is possible to have systemic issues—CSRF being a notable example.

Clarifying Systemic Vulnerabilities and Their Influence on Payouts

If the application had anti-CSRF protections in 45 of the 50 places, and was just missing it in five of them, then each instance of missing CSRF protection would be a unique finding. This is because the protection exists, it just didn’t on those specific endpoints. However, since in our example there was no anti-CSRF anywhere on the application, it’s possible that once they turn it on (especially in modern frameworks), it’ll automatically apply itself to all of the pages/endpoints for the application, and resolve the many with a single code change. Now, this isn’t always the case, but very commonly is (specifically with CSRF). In such situations, we’ll label the issue as “systemic,” reward the first report, and mark all subsequent reports as duplicates. 

THINGS TO KEEP IN MIND

After the mitigation is applied, if there are places where the systemic fix doesn’t cover all the bases, then those would be net-new unique vulnerabilities that should be rewarded independently.

Other examples of systemic issues include subdomains that are load balanced or resolve to the same host. This is where reporting an issue on one will make it immediately applicable to all other subdomains that share the same codebase or host, etc. This isn’t an exhaustive list—just a couple examples of how/where vulnerabilities can be systemic.

Navigating Duplicates with Confidence

Hopefully this guide provides some context around how, when, and why duplicates are duplicates. It’s important to remember that in all cases relating to duplicates, it’s critical to interrogate and evaluate the situation, as context matters significantly. Many times it requires reviewing the codebase to see how many fixes a given bug will take to remediate. So, remember the three principles mentioned earlier:

1. Touch the code (or make a change), pay the bug
2. Similar != same
3. Many != systemic

As long as you’re taking these principles to heart in each situation, it’s unlikely that you’ll get it wrong. If you have any questions, the Bugcrowd team is always here to help and provide advice. 

Finally, if nothing else, always remember, whether it’s updating documentation or the codebase—“touch the code or make a change, pay the bug”. 

Good luck and happy hunting!

The post The Three Principles of Bug Bounty Duplicates appeared first on Bugcrowd.

When evaluating the value of crowdsourced security, many people focus on the number of researchers who will be focused on your targets. While this is a logical approach, it’s just as important to consider the diversity of perspectives that a “crowd” can provide. For example, in a traditional penetration test, the findings usually reflect the perspective of a single “type” of tester (more on that below) –and that produces results aligned with that, albeit ones that conform to a methodology. In contrast, a genuinely crowdsourced pen test (not a “crowd-washed” one) inherits value from the full range of thoughts, approaches, and styles that only a crowd can provide–and that enables more comprehensive, intense testing to find more diverse types of bugs. Furthermore, it’s a strong signal that “pay for effort” (typical of an industry-standard pen test) and “pay for impact” (typical of a bug bounty) testing models are highly complementary.

At Bugcrowd, we think of hackers/pentesters as belonging to one of five distinct roles: Beginners, Recon Hackers, Deep Divers, Generalists, and Specialists. (It’s also important to keep in mind that over time, hackers/pentesters can and will journey from one role to another.) Each type has an important role to play in a given program, and those roles are relevant to how the Bugcrowd Platform’s CrowdMatch^TM technology matches the right crowd to a customer’s needs, at the right time, across 100s of dimensions.

Next, let’s take a look at each type of role in more detail.

The Beginner

Beginners on the Bugcrowd Platform refer to those who are new to the concept of crowdsourced security in general, rather than just being new to the platform specifically. When assessing a hacker’s level of experience on the platform, we may consider factors such as their participation on other platforms or their published research and tools. However, if such information is not available, we may assume that the hacker is a beginner in the ecosystem, at least initially (although this may not always be the case).

It’s important to note that being a Beginner does not necessarily mean that an individual is unskilled, even if they’re only submitting P3/P4 issues. For example, they may be working through a course to broaden their skill set, or they may have limited public presence but already work as a pentester and want to further develop their skills. Typically, this type of hacker covers vulnerability classes that others may not focus on as much, including P4 issues related to authentication and authorization, as well as simpler infrastructure issues (such as DMARC). 

Beginners add value in terms of coverage and consistency. Their participation in a program ensures, for example, vulnerabilities that would typically be found in a penetration test are also identified in a bug bounty program. The last thing we want is for a customer to follow a pentest with an overlapping bug bounty, and only then learn about a bunch of lower-priority items!

The Recon Hacker

Recon Hackers focus on identifying issues across the largest scope possible, so these individuals often discover P2/P3 issues that would not typically be found in a penetration test. 
Over the past few years, Recon Hackers have dominated every provider’s leaderboard due to the proliferation of subdomain takeovers, particularly in ROUTE53 and EC2 takeovers. While these takeovers are now largely patched, the leaderboards are now askew, and thus the highest-rated hackers may not always bring the maximum level of impact.

It’s important to note that many recon-based hackers are highly skilled. However, many of those who take a recon-first approach have found a lucrative niche, and thus tend to focus on refining their toolkit to further exploit only that niche.

The Deep Diver

Deep Divers are the most valuable hackers for Bugcrowd to identify, engage, retain, and uplift. These are hackers who tend to focus on a particular program, learn as much as they can about it, and provide unique and distinct value. A Deep Diver can uncover vulns that nobody else can due to their persistence and long-term knowledge of how a program operates.

Identifying these hackers is best done by analyzing the content of their submissions–rather than just looking at the spread of vulnerabilities on a program–due to the unique nature of these findings. 

The Generalist

Generalists take a multifaceted approach: They have a solid foundation in reconnaissance and utilize it to cover attack surfaces thoroughly, without relying solely on large-scale monitoring and tooling. Generalists also apply a deep-diving approach to evaluating assets, similar to the Deep Divers. While they may not spend as much time on a particular program as deep divers do, they invest considerable amounts of time across a variety of programs. Due to their dual proficiency in recon and deep diving, Generalists gain a reputation on the Bugcrowd Platform quickly and are highly valued. 

The Specialist

Specialists are a rare breed who require specific sourcing for an engagement. They possess unique and rare skill sets, and typically have years of experience in a particular technology (e.g., APIs, AI, IoT, web3) or a specific Bugcrowd VRT category.

As you read in the introduction, one of the Bugcrowd Platform’s greatest strengths is its ability to source and activate specialists to meet a program’s specific skill-set needs. Due to their specialized knowledge, Specialists can uncover issues that other hackers may miss, and they often provide invaluable, unique solutions to a problem. 

An Engineered Approach

To maximize the contributions of each hacker role, Bugcrowd is strategic in its approach to sourcing and engaging with them. For example, adding Beginners to a program that has been running for three months may lead to frustration and a high number of duplicates, while adding Generalists too early dilutes the ability for Beginners to up-level themselves through their findings. Therefore, program maturity is an important input for our platform’s CrowdMatch^TM technology when it sources the appropriate roles.

To summarize, different hacker roles contribute to crowdsourced security programs in different ways, and it’s important to deeply understand the program’s needs to make the most of those contributions. To respect that process, unlike other providers that rely on leaderboards or coarse-grained methods, Bugcrowd’s engineered approach intelligently sources and activates the right role types and skills for your programs, at the right time.

The post How Different Hacker Roles Contribute to Crowdsourced Security appeared first on Bugcrowd.