Over time, the attack surface and submissions associated with the VRT evolve, as do the needs of hackers and customers – so the VRT needs to grow and change, too. In that spirit, we are pleased to announce the latest release, VRT version 1.11, will be rolling out on the Bugcrowd Platform and reflected in our submission form shortly.

Overview of changes

This release includes several updates. As you can see below, they reflect changes to the threat environment, and how hackers, customers, and the Bugcrowd triage team view certain vuln classes and their relative impacts differently than before. 

New Top-Level Category: Cryptographic Weaknesses
A new category has been added to cover all common flaws in the cryptography area. This approach will help guide hackers when submitting a report about a specific weakness – such as insufficient entropy, predictable PRNG or IV, missing cryptography steps, timing attacks, or insufficient key stretching, to name just a few.

Multiple Category Updates: Insecure Direct Object Reference (IDOR)
This category has been a bit of a thorn in the side of hackers for a while now as a single IDOR category with the priority of ‘Varies’ can be frustrating especially when the finding has proven demonstrated impact. Additionally, with a lack of default priority, it could mean a program owner is more exposed than they should be, compared to if it were a P1.

Therefore, we’ve added several specific variants to the category:

• P1 – Read Personal Data (PII) – Iterable Object Identifiers
• P2 – Modify/Delete Sensitive Data – Iterable Object Identifiers
• P2 – Read Personal Data (PII) – GUID/Complex Object Identifiers
• P3 – Modify/Delete Sensitive Data – GUID/Complex Object Identifiers
• P4 – Read Sensitive Data – GUID/Complex Object Identifiers
• P5 – Read Non-Sensitive Information

This change should cover most common IDOR cases. However, hackers who find something that isn’t in these specific variants can always select the top-level category and appropriate adjustments will be made by our triage team.

New Variant: HTML Injection
The existing P4 ‘Email HTML Injection’ variant receives a lot of false-positive submissions from hackers submitting HTML injection in a web application. We did a lot of research on this category, reviewing the outcomes from the P4 false positives and how many led to accepted submissions and resulted in fixes. The answer was: not very many. As a result, the new category for these is considered P5, and you’ll find it under the existing ‘Content Spoofing’ specific vulnerability name. We’ll update existing submissions under the old P4 variant to the new P5 one, accordingly.

Update To Existing Category: Server-Side Request Forgery (SSRF) – External
We reviewed a number of SSRF findings across the existing P4 variant ‘External – Low Impact’. Most of these submissions are not accepted by customers, as they typically arise from intended functionality such as a webhook or image download. As a result, we have moved this category to the P5 level. 

New Specific Vulnerability: HTTP Request Smuggling
Thanks to amazing work by James Kettle at PortSwigger, this category has been revitalized across the internet. We see this vulnerability reported on a daily basis, but more often than not, it has low impact – so, we’re introducing it at the ‘Varies’ priority level in the ‘Server Security Misconfiguration’ category. The triage team will adjust affected submissions as needed.

New Specific Vulnerability: LDAP Injection
While certainly not the most reported vulnerability we see, LDAP Injection was a conspicuous omission in previous versions of VRT. We’ve remedied that by adding it to the ‘Server Side Injection’ category. 

Modified Specific Vulnerability: PII Leakage
The existing ‘PII Leakage’ category is commonly misused, with many hackers simply searching for ‘PII’ in the VRT selection box and selecting this category regardless of whether the specific vulnerability is related to automotive security. As a result, the existing category under ‘Automotive Security Misconfiguration – Infotainment’ has been changed from ‘PII Leakage’ to ‘Sensitive Data Leakage/Exposure’, retaining its usability for automotive submissions specifically.

A new vulnerability called ‘PII Leakage/Exposure’ with the default priority of ‘Varies’ has also been added to the category ‘Sensitive Data Exposure’. We believe that a ‘Varies’ priority is important here because not all instances of PII – a single email address in an AEM response, for example – are a P1 by default. However, the triage team will adjust submissions to a P1 as needed.

Deprecated Specific Vulnerabilities and Variants
‘Existing P4 Cross-Site Scripting IE-Only / IE11’ has been removed and the existing P5 category ‘Cross-Site Scripting – IE Only < IE11’ modified to cover all versions of IE. These changes have been pending for some time due to Microsoft retiring Internet Explorer version 11 in 2022.

New Specific Vulnerability: On Permission Change
This vuln is documented by OWASP and other sources, but is also very use case specific. To support these customer use cases, we’ve added it to the ‘Failure to Invalidate Session’ variant of ‘Broken Authentication and Session Management.’

This is a healthy, albeit not major, update to the VRT with contributions from hackers in the Bugcrowd community, our triage team, and our customers. There is still more work to be done, so you’ll soon be hearing from us again very soon about additional changes that reflect the evolving environment.

Why contribute to the VRT?

As we said in the introduction, an open-source governance model helps the VRT evolve at a pace and in concert with the changing environment – but that only happens if hackers and customers actively participate in the process. Contributions to the repository are reviewed by the VRT Council, which meets regularly to discuss new vulnerabilities, edge cases for existing vulnerabilities, priority-level adjustments, and general validation experiences. When the team comes to a consensus regarding a proposed change, it is committed to the master.

If you would like to contribute to the VRT, Issues and Pull Requests are most welcome!

The post Announcing Our Latest Vulnerability Rating Taxonomy Update appeared first on Bugcrowd.

As a new milestone in that effort, we are thrilled to introduce a groundbreaking, industry-first platform feature: Request a Response. This new feature offers an additional channel for hackers to engage with Bugcrowd triagers and customers, with a response ensured within 48-96 hours depending on the type of request. 

As a result, hackers will enjoy improved communication, increased transparency, and most importantly, more time dedicated to hacking–and to earning rewards. For Bugcrowd customers, Request a Response enables faster access to insights from hackers, when decisions about payments or other submission details would benefit from their feedback.

The Old Standard is Out

Unread comments are frustrating, to say the least. In the crowdsourcing space, it’s common for hackers post comments or questions that need to be addressed on their submissions, but for various reasons, the comment will not receive a response for an unacceptably long period of time–or get no response at all, in some cases. 

So, the industry standard has long been: submit a bug, wait for a response, leave a comment while awaiting response, comment goes seemingly unread, reach out to support, and eventually, reach a resolution only after much missed or absent communication. 

This cycle of miscommunication leads to confusion and frustration for everyone involved. Hackers are left wondering about the state of a particular submission and when they can expect movement–and their time, resources, and energy take a hit. 

Request a Response is Here to Deliver, and Here’s How

To solve this problem, Request a Response will help standardize communication between hackers, customers, and Bugcrowd staff. It allows hackers to directly request additional information, or ask a question to Bugcrowd employees and customers. A request triggers specific workflows, notifications, and alert actions to Bugcrowd and customers, who will then address the request within 48-96 hours. For status updates, hackers receive in-platform and email notifications as their request is addressed. 

Communication gaps have been the norm for far too long, and we’re determined to close them. With Request a Response, communication between hackers, Bugcrowd, and customers is streamlined and smooth.

Here’s what our beta testers had to say:

What You Can Expect

Our goal is to make this process as simple and predictable as possible. That leads to clear, reliable communication pathways and timelines. 

With this new standard set by Bugcrowd, hackers can request a response from Bugcrowd across seven different categories:

• Issue is Reproducible
• Scope
• Duplicate State
• Reward
• Priority
• Requesting Update
• Other

For responses from customers, two types of requests are available: Requesting Update and Other.

Additionally, hackers can provide details about their request to help Bugcrowd staff and customers properly triage and respond to them.

Plus, hackers can use this feature for these different submission substates:

• Triage
• Unresolved
• Resolved
• Out of Scope
• Not Reproducible
• Not Applicable (Bugcrowd only)

This feature is available to the Crowd across our engagements, so hackers and customers can submit a request and receive a quick response, saving time and stress.

The New Standard is Here

Ask questions, get a response: It’s as simple as that. Historically, succinct and predictable communication between hackers, platforms, and customers has been poor, messy, and frustrating. With Request a Response, you can expect clear communication timelines and guaranteed responses. 

For more information on Request a Response or any other Bugcrowd feature, please refer to our Researcher Documentation. Follow along as we continue to expand our platform features by following us on Twitter and Instagram, and don’t forget to join us on Discord and the Bugcrowd Forum. Sign up for a researcher account today to start your hacking journey!

The post Introducing Request a Response: A new standard for hacker and customer response time appeared first on Bugcrowd.

Now, we’re taking our PTaaS vision one step further: Starting immediately, you can buy, configure, launch, and see real-time results from a human-driven Bugcrowd Standard Pen Test–with a pentester team matched to your precise needs–via a few clicks. No more sales calls, scoping calls, and other backs-and-forths that delay your pen test launch. Instead, thanks to new capabilities in our platform, you’ll cut setup time from days to hours, start seeing prioritized findings in a rich Pen Test Dashboard fast, and get a final report within days of test completion. That’s how pen testing should work!

To give you a flavor of how easy this is, we’ve captured a couple steps in the brief demo below:

The Need for Standards

Why have we taken up this mission? Because everyone in the industry knows that the penetration testing experience for buyers and pentesters alike needs an upgrade. Traditional penetration testing has roots in consulting, so buying, scoping, sourcing pentesters, and report delivery depend on numerous manual, ad hoc interactions that delay what everyone wants: results. Too often, other PTaaS providers rely on automated, low-impact testing to streamline this process, while leaving the procurement and setup process largely manual–giving buyers the worst of both worlds.

Instead, we believe the solution to this problem is to standardize how human-driven, high-impact pen testing is delivered for common asset types, just like the construction industry adopted standards to make it faster and easier to build things at scale. That standardization is what makes it possible for us to orchestrate the setup process in software, for customers to buy Bugcrowd Standard pen tests in three sizes for external web apps or networks (with access to exactly the right pentester skills), and to easily organize and manage multiple pen tests in groups. Our platform’s unique ability to crowd-source the right pentesters for the job (CrowdMatch^TM) based on data, and rotate them on demand, is special value in the bargain.

Clear Choices

So what does this development mean for the pen testing industry? The way we see it, the choices are clearer than ever:

With this announcement, we’ve transformed the pen test experience from procurement through report delivery, but we won’t stop there. In the future, we’ll expand the types of pen tests that can be purchased and set up online and make it even easier to clone, organize, and manage pen tests and other programs on our platform.

In the meantime, buy and set up a Bugcrowd Standard Pen Test that’s “just right” for your external web app or network with just a few clicks! And if you’re attending RSA Conference in San Francisco next week (April 24-27), visit us at Booth #2438 or schedule a 1:1 to learn more. Read more about our Pen Testing as a Service announcement here. 

The post Standard Pen Tests Are Now Just A Few Clicks Away appeared first on Bugcrowd.

The Bugcrowd Platform also provides out of the box capabilities for the most popular workflows and use cases. Some of these include inbound integrations with SDLC tooling such as Atlassian Jira or IBM SOAR. To address outbound needs, Bugcrowd offers notifications on important events via email or on the web. As these use cases grow in sophistication, we’ve enhanced Bugcrowd Platform Notifications with two additional settings.

First, you can now be notified on submissions assigned any severity. For example, “Notify me when a P1 is submitted” is one of the most popular features requested by customers. With this setting, customers are notified of the issue immediately, even before triage. This allows you to take action on the finding immediately if the submission is in fact a true positive. Of course, you will still be notified once the submission is triaged by the Bugcrowd team. 

Second, you can now set up notifications for multiple submission states where you’ll be notified for all submissions that reach the specified state in the Bugcrowd Platform. As an example, you can be notified any time a submission reaches the “Triaged” state, and when it reaches the “Unresolved” state (accepted by a team member).

Both of these settings are now generally available in the Bugcrowd Platform. For more details, see the docs here.

The post Configuring Notifications for P1 Response in the Bugcrowd Platform appeared first on Bugcrowd.

In 2022, Bugcrowd Security Knowledge Platform introduced a new platform feature, the Industry Versus Organization Comparison Report, to allow customers to benchmark the performance of their program against industry peers for augmenting or improving the overall performance of their program. Today, we’re announcing additional security benchmarking capabilities in the report: giving customers the ability to benchmark the performance of their program against different industry peers, and adding new performance metrics, as well.

We understand that customers have dynamic, complex businesses and need to benchmark against different industries to fully understand the performance of their program. So, we’re giving customers the ability to select up to three industries to compare against at a time.

We have also added four additional charts for Payout comparison for P1 through P4 submissions to help our customers understand how they compare in payouts versus their peers in different industries. Having that data should help them become more competitive for researcher attention and attract more researchers to their program.

The post Announcing Enhancements to Industry Comparison Reports in the Bugcrowd Platform appeared first on Bugcrowd.

As the use of GPT-based chatbots, such as OpenAI’s GPT-3 and GPT-2, becomes more widespread, there is an increasing risk that malicious hackers may use these powerful language models for their own nefarious purposes.

One potential way that hackers could use GPT-based chatbots is by using them to impersonate a trusted entity in order to gain access to sensitive information. For example, a hacker could train a GPT-based chatbot to impersonate a customer service representative from a bank or other financial institution, and use this chatbot to trick people into providing their personal information, such as their login credentials or credit card numbers.

Another way that hackers could use GPT-based chatbots is by using them to generate convincing phishing emails or text messages. These messages could be designed to trick people into clicking on a link that would then install malware on their devices, or to steal their personal information.

Additionally, GPT-based chatbots could be used to conduct “social engineering” attacks, by creating compelling and tailored messages to scam individuals or organizations, since chatbots can generate highly specific and convincing text.

It’s also possible for GPT-based chatbots to be used for spreading misinformation and propaganda at scale, by automating the process of creating fake news and misleading narratives on social media.

It is important to note that the technology behind GPT-based chatbots, like any other AI tool, is neutral and can be used for both good and bad purposes, but the potential malicious use cases outlined above are a reminder that as with any new technology, it’s important to be aware of the potential risks and take steps to mitigate them.

For individuals and organizations, it is important to be aware of these potential dangers and to take steps to protect themselves, such as being wary of unexpected messages or emails, and verifying the identity of any person or organization that requests personal or sensitive information. Additionally, developers should design and implement security measures to detect and prevent malicious use of GPT-based chatbots.

As GPT-based chatbots become more advanced and widely adopted, it will be important for the broader technology community to come together to address these risks and to ensure that this powerful technology is used for the betterment of society rather than for harm.

ChatGPT is the consummate example of how emerging threats continually challenge security tools and techniques that were never designed to handle them. Only the global security researcher/hacker community provides human ingenuity at scale to recognize and counter new attack vectors as they appear!

The post Will GPT-Based Chatbots Become A Thing For Malicious Hackers? appeared first on Bugcrowd.

Massive growth in mobile applications, web apps (cloud-based and on-premises), IoT devices, APIs, cloud infra, and other assets continues to complicate the attack surface, especially for smaller companies that historically have had less to worry about in this area than enterprises. Orgs of all sizes are exposed now: In 2021, nearly 80 percent of observed threat groups targeting mid-sized companies, and more than 40 percent of observed malware, had never been seen before.

Source: McKinsey & Co.

The regulatory environment is also driving the need for more solutions: Within the United States alone, there are currently hundreds of state bills or resolutions that seek to regulate cybersecurity and data privacy, and the US Securities and Exchange Commission (SEC) has proposed new federal-level rules about breach notifications. In Europe, the environment is arguably even tougher thanks to GDPR, and NIS2 looms in the distance after recent adoption by the European Parliament. Globally, compliance-driven customer requirements will only grow.

With these strong market forces, you’d probably predict that the gap between spend and opportunity is fairly minimal–but you’d be wrong. In reality, the gap between actual spend ($150 billion in 2021) and market opportunity ($2 trillion) is glaring. According to McKinsey, that gap is both a failure and an opportunity:

“Such a massive delta requires providers and investors to “unlock” more impact with customers by better meeting the needs of underserved segments, continuously improving technology, and reducing complexity—and the current buyer climate may pose a unique moment in time for innovation in the cybersecurity industry.”

In other words, the delta exists because the cybersecurity industry has produced too many solutions that fail to scale up or down, add anything interesting to the technology conversation, and/or reduce complexity or noise. Cybersecurity buyers are crying out for a better approach to reducing risk, and that dissatisfaction is reflected in shallow market penetration by vendors.

Those buyers are also trapped in a deep and seemingly permanent talent crisis, which makes solutions that can help them meet their security goals in spite of that trap extremely timely. 

The Platform Shows the Way

At Bugcrowd, that innovation referenced by MicKinsey takes the form of a Security Knowledge Platform that brings the power of the global security researcher community to penetration testing and other security workflows in a scalable, highly engineered way, removing noise and adding contextual intelligence derived from 1000s of other customer experiences. The result is a unique ability to continuously discover and remediate hidden vulnerabilities that put you at risk of being blind-sided by cyber attacks–while providing a foundation for future applications of crowdsourcing to security.

Contact us to learn more!

The post Are Cybersecurity Investments Recession-proof? appeared first on Bugcrowd.

This platform-powered approach helps security teams overcome significant challenges caused by the fragmented security environments, including:

• Poor visibility into security posture
• Multiple single points of dependency
• Siloed security data and insights
• Overhead in managing multiple providers

These challenges are even more painful, of course, when budgets and resources are constrained. Customers are almost crying out for strategies that will help them maintain or increase their investments in security, without increasing overhead and complexity.

Our customers are also getting bigger and more complex, so we need to support their growing security organizations. We think the best way to do this is to empower them with the flexibility to structure their security solutions on the Bugcrowd Platform to reflect their internal organization or products, and to manage them in an efficient yet fine-grained way–for example, to enable them to standardize scope across a series of different programs (pen tests, bug bounty programs, etc.), or to run reports across them. That would make managing and getting value from multiple Bugcrowd solutions much easier, and empower security leaders to focus more on the big picture.

Introducing multi-tier management

For these reasons, we’re excited to announce the addition of multi-tier program management to the Bugcrowd Platform.

Bringing multi-tier management to the platform gives customers a lot more flexibility for solving multiple security goals across assets in pen tests, bug bounties, VDPs, and even ASM programs, in any combination. In most customer organizations, the asset is king/queen: It defines which employees get access to which resources, and has an associated security strategy attached to it. This change lays the foundation for managing asset security throughout its lifecycle, across all the Bugcrowd products that might be applied to it.

Under this new model, the “program” becomes a container abstraction for multiple engagements that inherit attributes from the program. In other words, a customer can now share submissions, roles, assets, and integrations across pen tests, bug bounty programs, and VDPs inside the same program–as well as get valuable insights about trends and opportunities from data analytics and reports generated across that program. 

Under the multi-tier model, you can also expect a more holistic understanding of all your assets by researchers. You will naturally create a clear comprehension of your needs regarding submissions, roles, assets, and integrations; providing researchers additional critical tools beneficial to your security investment.

In the diagrams below, we can see an organization that has gone from individually managing five programs under the former, “flat” model (Figure 1), to managing only two programs under the new, multi-tier model (Figure 2). For each new engagement created, it inherits the attributes already set at the program level. Researcher submissions will also be shared across the program, significantly reducing the pain of having to move submissions across different engagements to meet certain requirements.

Figure 1. Before: Flat management model

Figure 2: After: Multi-tier management model

By introducing this model, we will significantly reduce the administration overhead in setting up and managing new solutions on the Bugcrowd Platform. We also unlock new reporting and insights across customer solutions, an ability to duplicate an engagement with a single click, and an intuitive, three-tier navigation UI:

Bugcrowd Penetration Testing as a Service is the first solution type to support this new approach to organizing security programs at scale, with Managed Bug Bounty and VDP to follow on the roadmap. Going forward, as one benefit of this new approach, it will be possible to “clone” completed penetration tests across programs (including scope, targets, integrations, etc.), allowing customers to much more easily repeat their pen tests at scale–which we anticipate will be very useful for organizations that, for example, need to do large batches of compliance-driven pen tests across the year.

Investing in the platform 

If multi-tier management sounds like something that is critical for a multi-solution platform, you’re spot on. This is a significant improvement in the way security engagements are managed on the Bugcrowd Platform, one which has been made possible with significant investment from our customers. If you have any thoughts or questions about this platform enhancement, we welcome your feedback!

The post Announcing Multi-tier Program Management on the Bugcrowd Platform appeared first on Bugcrowd.

The good news is that bug bounty and crowdsourced security are tailor-made to help address the problem, and their adoption by hyperscalers for their cloud products and open source projects is proving it.

Hyperscalers Double Down

Microsoft is an enthusiastic adopter of bug bounty, and recently announced that it paid out $13.7 million in rewards through its 17 active bug bounty programs over the past 12 months. (Bugcrowd processes bounty payments for Microsoft’s programs.) The bounty table is impressive: The Platform Program for Microsoft Hyper-V offers up to $250,000 for findings in the area of critical remote code execution, information disclosure, and denial of services vulnerabilities, and a similar program for Microsoft Windows Insider Preview offers a bounty range of up to $100,000 for critical/important vulnerabilities. 

Possibly based on the rapidly expanding attack surface associated with cloud infrastructure (including the discovery of six critical Azure vulnerabilities in 2021), Microsoft expanded its bug bounty programs in the past year, adding “high-impact security research scenarios” to its Microsoft Azure Bounty Program. 

Although Amazon Web Services has a less systematic approach to crowdsourced cybersecurity than Microsoft to date, it does accept vulnerability submissions for its cloud products and open source projects, and provides public infrastructure for running private bug bashes (with a goal of squashing 1 million bugs, collectively).

Beyond cloud infrastructure itself, cloud applications are inherently at risk due to potential misconfigurations or data exposure, insecure APIs, lack of tenant isolation, and numerous other reasons. As Bugcrowd Founder/Chairman/CTO Casey Ellis has remarked, “A lot of people would just assume that [security] is all sorted when they go to use a cloud provider — and might be a bit surprised to find out it’s not.”

Google Brings Bug Bounty to Open Source

Meanwhile, in August 2022, Google rolled out a new self-managed bug bounty program focusing solely on Google’s open source projects. The new Open Source Software Vulnerability Rewards Program (OSS VRP) will offer vulnerability rewards that range from as low as $100 to slightly over $31,000, with possible bonus increments that range to $1,000 in the case of a “particularly clever or interesting” vulnerability.

Google was an early adopter of bug bounty through what is now called its Bug Hunters Community, with 12 years of experience and more than $38 million in payouts on record. In 2021, Google disbursed a total of $8.7 million in bug bounty rewards to nearly 700 security researchers across 60 countries. 

This new program is another proof point that the open source software supply chain has become nearly impossible to defend with traditional means due to complex dependencies, constant code churn, increased opportunities for malicious code injection, and other factors. In its announcement, Google cites a 650% year-over-year increase in open source ecosystem attacks, including the recent major incident involving Log4j. 

Next Steps

Now that cloud adoption and open source software are ubiquitous, more security leaders are learning the lesson that Microsoft and Google learned years ago: that status-quo, reactive approaches to cybersecurity alone fall short as scale grows–and nothing says “scale” like cloud and OSS. 

To learn more about crowdsourcing and cloud vulnerabilities in particular, grab a seat for our webinar on the subject with Enterprise Strategy Group cloud security analyst Melinda Marks.

The post Cloud and OSS risks have Bug Bounty adoption humming appeared first on Bugcrowd.

What is a scope? 

A scope is the defined set of targets that have been listed by an organization as assets that are to be tested as part of a particular engagement. Things that are listed as “in-scope” are eligible for testing, and things that are “out of scope” are to not to be tested. 

If you think of scope as a spectrum, there are three main categories that programs fall under. Where you fall could determine the effectiveness of your program reaching researchers and the overall success of your program. 

 Three main types of scopes:

1. Limited Scope: a limited scope on a bug bounty program only includes a single or specific target(s). 
2. Wide Scope: a wide scope bounty program is one that includes a wildcard to the in-scope targets.
3. Open Scope: an open scope bounty program is one that has no limitations on what researchers can or cannot test, so long as the target/asset belongs to your organization. 

For programs that currently fall under (1) or (2), considering a move toward open scope is almost always a good idea. If you’re feeling unsure, don’t worry: Most organizations and bounty programs take a systematic progression over time. It’s common to start with a basic or limited scope, move to a more expansive, limited scope, then to a wildcard, and finally, to an open scope.

Why is expanding your program’s scope important?

Threat actors aren’t asking for permission to use an open scope; they don’t have to play by any rules, and they aren’t going to limit themselves to entering through your “front door.” So, limiting what defenders can test only creates more disadvantages. For that reason, an open scope program is not only useful, but necessary: There are few actions that are more potentially effective in improving security posture than running an open-scope bug bounty program.

Ready to start moving your program toward an open scope?

The best place to start is by talking to your Bugcrowd Success Team – your TCSM will help provide guidance, recommendations, and support for whatever you need to get going. Bugcrowd is here to help you secure your organization, and we know that open scope is a critical part of your security journey. To learn more about Open Scope, check out this guide. 

The post Is An Open Scope Program Right For Me? appeared first on Bugcrowd.