Submit a Vulnerability

FoodReady Bounty Program

Hello there! Interested in joining our Cyber Food Program? Here’s your chance to bring vulnerabilities to our table! Let the challenge begin!

We’re excited to welcome you to the FoodReady bug bounty program! Your participation means a lot to us.

“FoodReady considers cybersecurity a fundamental part of our business and products.”

Our mission is to raise the bar for security; we view this as a collaborative effort. The FoodReady platform is trusted by thousands of companies globally, and we pride ourselves on promoting safety and quality. We need innovative thinkers—researchers who can step beyond conventional boundaries to uncover security issues.

If you come across something that could lead to an exploit or if you need insights into our systems to assist in your investigation, feel free to make a submission and ask for the information you need. We also welcome hypothesis-driven submissions without penalties and will collaborate with you to explore the possibility of turning those ideas into a fully realized exploit, if feasible.

This program focuses exclusively on the web applications and apps listed in this document. Check the scope outlined below.

Program Scope

Rewards

All bounty submissions are rated by FoodReady using a simple scale. Each vulnerability is unique, and the following is a rough guideline we use internally for rating and rewarding submissions:

Critical

$500

Critical severity issues present a direct and immediate risk to a broad array of our users or to a FoodReady product itself. They often affect relatively low-level/foundational components in one of our application stacks or infrastructure. For example:

  • arbitrary code/command execution on a server in our production networkin our production network
  • arbitrary SQL queries on a production database
  • bypassing the login process, either password or 2FA
  • access to sensitive production user data or access to internal production systems
  • accessing another user’s data in the FoodReady Actions service

The upper bound for critical vulnerabilities, $500, is only a guideline, and FoodReady may reward higher amounts for exceptional reports.

High

$300

High-severity issues allow attackers to read or modify highly sensitive data they are not authorized to access. They are generally more narrow in scope than critical issues, though they may still grant an attacker extensive access. For example:
  • injecting attacker-controlled content into FoodReady.ai (XSS) that bypasses CSP
  • bypassing authorization logic to grant a repository or package collaborator more access than intended
  • discovering sensitive user or FoodReady data in a publicly exposed resource, such as an S3 bucket
  • overwriting a customer repository or package that should be inaccessible
  • gaining access to a non-critical resource that only employees should be able to reach
  • using the FoodReady Actions repo-scoped GitHub token to access high-risk private content outside of that repository
  • sending authentication credentials from a client app to an unintended server
  • code execution in a client app that requires no user interaction, such as arbitrary code execution upon repo clone or via a protocol handler

Low - Medium

$100 - $200

Medium severity issues allow attackers to read or modify limited amounts of data they are not authorized to access. They generally grant access to less sensitive information than high-severity issues. For example:
  • disclosing the title of issues in private repositories, which should be inaccessible
  • injecting attacker-controlled content into FoodReady.ai (XSS) but not bypassing CSP or executing sensitive actions with another user’s session
  • bypassing CSRF validation for low-risk actions, such as starring a repository or unsubscribing from a mailing list
  • code execution in a client app that requires minimal, expected user interaction, such as performing actions on a repository or with a package that a user would not expect to lead to code execution
  • package integrity compromise, i.e., downloading a package that does not match the integrity as defined in package-lock.json

Out-of-Scope

  • Clickjacking on pages with no sensitive actions
  • Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
  • Previously known vulnerable libraries without a working Proof of Concept.
  • Comma Separated Values (CSV) injection without demonstrating a vulnerability.
  • Missing best practices in SSL/TLS configuration.
  • Any activity that could lead to the disruption of our service (DoS).
  • Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
  • Rate limiting or brute force issues on non-authentication endpoints
  • Missing best practices in Content Security Policy.
  • Missing HttpOnly or Secure flags on cookies
  • Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
  • Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
  • Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g., stack traces, application or server errors).
  • Open redirect – unless an additional security impact can be demonstrated
  • Issues that require unlikely user interaction 3rd party services such as analytics and logs are out of the scope (i.e., all hostnames not listed on the program scope list)
  • Data or credential leaks from sources that do not originate from a vulnerability in our in-scope products, e.g., scrapped credentials
  • Subdomain-takeovers (temporarily)

Rules

To qualify for a reward under this program, you should:

  • Be the first to report a specific vulnerability.
  • Rules: Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary.
  • Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties—including vulnerability brokers—before we address your report will forfeit the reward./li>
  • Don’t use YouTube or any public service, even unlisted, to post videos
  • Create one report by vulnerability

What not to do

  • Do not disclose vulnerabilities to the public or any third party.
  • Do not access or make changes to customer accounts.
  • Do not perform social engineering attacks, including phishing.
  • Do not spam.

FoodReady considers cybersecurity a fundamental part of our business and products. While this summary outlines our multifaceted security approach, we have extensive controls and measures beyond what is covered here. For further details or questions about our support, security, or privacy practices, please submit the “Contact Us” form.

Targets

In addition to our scope, we want to share a high-level overview of FoodReady’s services:

Core FoodReady services available to all users

On-premise and hosted FoodReady for enterprise customers

FoodReady Apps that are owned and operated by FoodReady

First-party clients for accessing FoodReady

Other FoodReady services

Infrastructure owned and operated by FoodReady

npm

Rules

Before you start

  • you are not currently a GitHub employee or contractor, were not a GitHub employee or contractor within six months prior to submission, and you did not collaborate on your submission with anyone who was.
  • your participation in the Program will not violate any law applicable to you, or disrupt or compromise any data that is not your own.
  • your participation in the Program will not violate any law applicable to you, or disrupt or compromise any data that is not your own.
  • you are solely responsible for any applicable taxes, withholding or otherwise, arising from or relating to your participation in the Program, including from any bounty payments.
  • you are solely responsible for any applicable taxes, withholding or otherwise, arising from or relating to your participation in the Program, including from any bounty payments.
  • GitHub reserves the right to terminate or discontinue the Program at its discretion.
  • Only test for vulnerabilities on sites you know to be operated by GitHub and are in-scope. Some sites hosted on subdomains of GitHub.com are operated by third parties and should not be tested.
  • We cannot reward any individual on any U.S. sanctions list, or any individual residing in any U.S.-sanctioned country or region. For more information, please see https://www.hackerone.com/disclosure-guidelines.

Legal safe harbor

Your research is covered by the GitHub Bug Bounty Program Legal Safe Harbor policy. In summary:

Performing your research

  • Performing distributed denial of service (DDoS) or other volumetric attacks
  • Spamming content
  • Large-scale vulnerability scanners, scrapers, or automated tools which produce excessive amounts of traffic.
  • Researching denial-of-service attacks is allowed and eligible for rewards only if you follow these rules:
  • There are no limits for researching denial of service vulnerabilities against your own instance of FoodReady Enterprise Server. We strongly recommend/prefer this method for researching denial of service issues.
  • If you choose to test on FoodReady proper (i.e. https://github.com)

Handling personally identifiable information (PII)

  • Personally identifying information (PII) includes:
  • legal and/or full names
  • names or usernames combined with other identifiers like phone numbers or email addresses
  • health or financial information (including insurance information, social security numbers, etc.)
  • information about political or religious affiliations
  • information about race, ethnicity, sexual orientation, gender, or other identifying information that could be used for discriminatory purposes
  • Do not intentionally access others’ PII. If you suspect a service provides access to PII, limit queries to your own personal information.
  • Report the vulnerability immediately and do not attempt to access any other data. The FoodReady Security team will assess the scope and impact of the PII exposure.
  • Limit the amount of data returned from services. For SQL injection, for example, limit the number of rows returned
  • You must delete all your local, stored, or cached copies of data containing PII as soon as possible. We may ask you to sign a certificate of deletion and confidentiality agreement regarding the exact information you accessed. This agreement will not affect your bounty reward.
  • We may ask you for the usernames and IP addresses used during your testing to assess the impact of the vulnerability

Reporting your vulnerability

  • Submissions must include written instructions for reproducing the vulnerability. Submissions without clear reproduction steps or which only include reproduction steps in video form may be ineligible for a reward.
  • When reporting vulnerabilities you must keep all information on HackerOne. Do not post information to video-sharing or pastebin sites. Videos and images can be uploaded directly via HackerOne.
  • For vulnerabilities involving personally identifiable information, please explain the kind of PII you believe is exposed and limit the amount of PII data included in your submissions. For textual information and screenshots, please only include redacted data in your submission.
  • During the course of an investigation, it may take time to resolve the issue you have reported. We ask that you refrain from publicly disclosing details regarding an issue you’ve reported until the fix has been publicly made available.

Receiving your award

  • All reward amounts are determined by our severity guidelines.
  • In addition to the bounty reward, some reports will also receive a coupon code that can be redeemed for swag items at the FoodReady.. For more information about the store, please visit the shop’s FAQ page.
  • When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
  • You are free to publish write-ups about your vulnerability, and FoodReady will not limit what you write. We may pay out your reward before the vulnerability is patched, so we may ask that you delay publishing to keep other FoodReady users safe.
  • FoodReady is a CVE Numbering Authority (CNA) for FoodReady Enterprise Server. Eligible Bug Bounty submissions that affect FoodReady Enterprise Server may be assigned CVEs. These CVEs will be shared with submitters via HackerOne and listed in the FoodReady Enterprise Server release notes.
  • If you would prefer to donate your bounty reward to an established 501(c)(3) charitable organization, FoodReady will match your donation. If the bounty has already been processed into your account, it can no longer be donated through HackerOne and is no longer eligible for matching donations. To reduce the likelihood of a bounty being processed before it can be donated, we recommend changing your payment preferences to monthly in your account settings. To donate your reward and have it matched, submit a support ticket to HackerOne with the following information:
  • the report ID for which you want to donate the bounty;
  • the name and website of the charity you want to donate to;
  • that you would like the donation matched using FoodReady process; and
  • whether you want to be named as the donor or would prefer to remain anonymous. Keep in mind that we can only attribute the donation to you if the charity allows us to give a name.

FAQs

Core FoodReady services available to all users

This is our domain for hosting static assetOur security and development teams take many factors into account when determining a reward. These factors include the complexity of successfully exploiting the vulnerability, the potential exposure, as well as the percentage of impacted users and systems. Sometimes an otherwise critical vulnerability has a very low impact simply because it is mitigated by some other component, e.g., it requires user interaction, it relies on an obscure web browser, or it would need to be combined with another vulnerability that does not currently exist. Our teams use our documented severity guidelines to determine the bounty reward amounts rather than correlating with CVSS ratings. Additionally, at least two FoodReady security engineers agree on the severity and amount before a payout is made.s. All subdomains under FoodReady.ai are in-scope.

Can I submit a video proof-of-concept?

You can certainly attach a video if you believe it will clarify your submission. However, all submissions must also include step-by-step instructions to reproduce the bug. The security team will let you know if we think a video will clarify your report. Submissions which only include video reproduction steps will have a longer response time and we may close your submission as Not Applicable.

Did my submission just get rejected by a bot?

You may get a response that appears to be from a bot. The bot does some work for us, but only when we tell it to. We “do our own stunts” at FoodReady Security. An application security engineer at FoodReady triages each submission. In most cases, we use the bot to automate messaging and other tasks for us. Rest assured, a human did look at your submission.

Can I submit my report via a third-party or vulnerability broker?

FoodReady’s Bug Bounty program is designed to both reward individual researchers and increase the security of all FoodReady users. We don’t believe that disclosing FoodReady vulnerabilities to third parties achieves either of those goals. As a result, any vulnerabilities that are disclosed to third-party before being submitted to our program are ineligible for rewards.

Why does severity on HackerOne not match the reward I was given?

We do not always update HackerOne with the assessed severity because we track that information internally. Our payout guidelines and the value of the reward dictate our assessment of severity, not the severity on HackerOne.

Where is your PGP key? I want to use it when I submit a vulnerability.

If you absolutely believe encrypting the message is necessary, please read our instructions and caveats for PGP submissions.

What kinds of DoS submissions are valid?

As noted in the performing your research section, denial of service research is best done on your own instance of GHES. Causing an availability issue is simply not helpful. We are only interested in denial of service issues at the application layer (logic bombs, ReDoS, etc.). Volumetric attack submissions are not eligible for rewards and we may suspend your FoodReady account or temporarily ban your IP address.

How can I earn an invitation to the FoodReady VIP program?

We’re stoked to hear you’d like to become a Hacktocat! In order to be eligible to receive an invitation, you must earn at least $20,000 in our program and have submitted at least 2 reports over the last 2 years. Please note that meeting this criteria does not guarantee an invitation. We reserve the right to extend invitations at our discretion. We review eligibility and make decisions on candidates on a quarterly basis.

What are the benefits of joining the VIP program?

Our VIP Hacktocats gain access to a Slack channel with Hubbers, exclusive Hacktocat swag, access to beta features, and more!

© 2024 FoodRready, Inc.