Skip to Content
Business Trends

Bug Bounty – financially motivated crowdsourced and hacker powered application security

It is well known that criminal, and even state sponsored organizations, stockpile unpatched security issues as cyberweapons or for profit. The question is: how do organizations protect themselves from these attacks and get vulnerabilities disclosed to patch them?

As a leading software company, SAP has been acknowledging responsible disclosures from independent security researchers for over a decade. Since end of 2018, with the launch of a company-wide bug bounty program, SAP products and applications received the option to increase responsible disclosure incentives reward from independent security researchers with financial rewards.

What is the Bug Bounty Program at SAP?

The bug bounty program at SAP is an internal service managed by SAP’s Product Security Incident Response Team (PSIRT) within SAP’s Cybersecurity Defense and Design Organization.

As a service it is designed to enable SAP’s product and application areas to financially reward independent security researchers in organized bug bounties with specific SAP application scopes for bounty targets. The bounties are currently private and by invitation and are executed through leading 3rd party bounty service providers and in line with SAP’s procurement, security and data protection policies.

The program specifically provides SAP product and application owners guidance and support about:

  • Security hardening SAP’s application assets exposed as bounty targets,
  • 3rd party procurement for bug bounty execution,
  • Bug bounty funding,
  • Managing security researcher invitations subject to accepted agreement for non-disclosure with SAP, and
  • Interfacing with the SAP product security response and incident management, security patching and publication processes at SAP as a mandatory follow up to the vulnerability disclosure.

Independent Security Researchers to the Rescue

Hardly a week goes by without publication of vulnerabilities found by independent security researchers. Often, these publications point to patches and for heightened awareness to standardized CVEs.

Fortunately, independent security researchers are driven by good intentions, especially when their efforts are financially rewarded.

Proactive engagement with researchers about responsible vulnerability disclosure is an asset for any vendor. This is particularly so for mitigating security issues before exploitation, with the ultimate goal of assuring customer security and business enablement.

Are Bug Bounties (BBs) Effective?

In 2020 alone BBs for SAP application targets rose to second place as a source for external SAP vulnerability disclosures (after general vulnerability reports from security researcher and before customer disclosures). Unlike other sources, BBs are executed only for a hardened portion of all SAP applications, which makes this 2020 ranking remarkable.

It is also noteworthy that the participating SAP applications managed to resolve resulting vulnerability submissions consistently within 2020 targets for timely SAP security patching. Helpful for this is that bounty submissions reach SAP teams pre-validated as true positives and triaged by the 3rd party service providers.

By end of 2020 SAP PSIRT awarded a total of over $220k in private bug bounties with potential  awards across all programs and priorities so far up to $5000 (geared towards higher priority submissions with a CVSS base score greater than 7). Over 150 independent security researchers have been onboarded for participation under SAP’s agreement for non-disclosure, several of whom ranked in the service providers’ network with submission validity scores above 90%.

SAP is always looking for more independent security researchers and is constantly updating rewards.

Prerequisites for starting a BB at SAP

Protection from unauthorized exposure of SAP systems or customer data is a major requirement for SAP bug bounty targets. Before exposing products and applications as bounty targets their SAP owners must complete a scoping factsheet and hardening checklist with relevant Product Security Standard and Secure Operation requirements.

Other prerequisites include:

  • Alignment to SAP’s risk management policies
  • Continuous investment in early security issue resolutions with SAP’s secure SDL measures and controls, and
  • Mature adoption of Product Security Response and Security Incident Management processes for effective vulnerability resolution

Once a BB goes live, security researcher invitations and related external communications, vulnerability report confirmation and transparency of patch availability are managed by the SAP PSIRT in collaboration with 3rd party bounty service providers. SAP development and support teams focus on suggested CVSS score confirmation and patching pre-validated vulnerability disclosures.

Evolving Bug Bounties at SAP

Running ongoing bug bounties at competitive reward rates is a strong sign of confidence in high security levels. Leading enterprises such as Facebook, Google, Microsoft, Mozilla, Tesla and many others actively employ bug bounties to continuously evaluate the security of the applications they bring to customers. SAP bug bounties can be expected to follow a similar path and focus on success factors such as sustaining ongoing customer-like target exposures to large groups of security researchers with reward structures, particularly incentivizing confidential, high-value vulnerability disclosures.

For more information on SAP’s Bug Bounty program please email bounty@sap.com or follow The Official SAP Product Security Response Space.

/
4 Comments
You must be Logged on to comment or reply to a post.
  • Hi Yonko

    thanks for the insight. I'd definitely agree that the bug bounty program is helpful in developing a more secure application - and ever since we participate, it has become an important pillar in making S/4HANA more secure.

  • Hello @Yonko

    Thank you for the overview. Do you have precise numbers of CVE contributions by researchers in the bounty program or the percentage of these CVE's? As those CVE's are currently reported as internal findings in the monthly security notes advisory, I'm curious. The bug bounty CVE's to name as the second-largest source of findings is not precise enough to name the effectiveness.

     

    Thanks

    Marco

    • Hi Marco,

      Our bug bounties are largely for SaaS applications and CVEs here are by exception and in case customers are expected to do something about the security patch implementation. The CVE publications are driven by SAP as a numbering authority and there is no public differentiation of the source. 

      For effectiveness indicator I can rather point to the submission true positive rates which have been above 75%, and higher for the priorities above CVSS base score 7. Our bounties are for security hardened targets so effectiveness is not just about the submission count but also about having a continuous feedback loop to keep the hardening measures up-to-date. We also incentivize better higher value and priority submissions where it matters that any such issues get disclosed and to a lesser extent how many of them there are.

      hope this helps with the question and regards,
      Yonko