Vulnerability Disclosure Program

As part of our commitment to enhancing the security of our platform and services, we value collaboration with the security research community. To facilitate this collaboration, we have established a Vulnerability Disclosure Policy. This policy encourages individuals to report any discovered vulnerabilities to us, enabling us to promptly address and mitigate potential security risks.

Learn More

Guidelines for Responsible Disclosure

To maintain a constructive environment for security research, we ask that you follow these guidelines when conducting research:

  • Do not engage in any form of Denial of Service (DoS) attacks against byrd applications, servers, networks, or infrastructure.
  • Avoid tests that may result in degradation or interruption of our services.
  • If using automated scanners or tools, ensure they operate in a manner that does not generate excessive network traffic (e.g., limit requests to a maximum of one per second).
  • Refrain from leaking, altering, or deleting any user data or files within our applications or servers.
  • Do not access or disclose any files from our applications or servers.
  • We do not permit any form of vulnerability disclosure, whether full, partial, or otherwise.
  • Avoid submitting spam through registration forms on our websites, including the Support Portal.
  • Use the user-agent "VDP name-at-email-dot-com" in all web-based requests.

Guidance

Security researchers must:

  • Only access the minimum amount of data necessary. For example, 2 or 3 records should suffice to demonstrate most vulnerabilities, such as an enumeration or direct object reference vulnerability.
  • Avoid using high-intensity invasive or destructive technical security scanning tools to discover vulnerabilities.
  • Respect the privacy of byrd users, staff, contractors, services, or systems. For instance, do not share, redistribute, or fail to properly secure data obtained from our systems or services.
  • Not communicate any vulnerabilities or associated details through methods not outlined in this policy.
  • Refrain from altering data in byrd systems or services.
  • Do not disrupt byrd services or systems.
  • Avoid engaging in social engineering, 'phishing' attacks, or physical attacks against byrd staff or infrastructure.
  • Not disclose any vulnerabilities in byrd systems or services to third parties or the public before byrd has confirmed that these vulnerabilities have been addressed or corrected. This does not prevent you from notifying a vulnerability to third parties for whom the vulnerability is directly relevant, such as when the vulnerability is in a third-party software library or framework. However, do not reference specific details of the vulnerability as it applies to byrd in such reports.
  • Not demand financial compensation for disclosing any vulnerabilities.
  • Securely delete all data retrieved during the research as soon as it is no longer needed or within 1 month of the vulnerability being resolved, whichever comes first.

Scope

This disclosure policy applies only to vulnerabilities under the following DNS scopes: *.getbyrd.com:

  • 'In scope' vulnerabilities must be original, previously unreported, and not already discovered by internal procedures.
  • Volumetric vulnerabilities are not in scope - meaning that simply overwhelming a service with a high volume of requests is not in scope.
  • Reports of non-exploitable vulnerabilities, or reports indicating that our services do not fully align with "best practice", for example missing security headers, are not in scope.
  • TLS configuration weaknesses, for example "weak" cipher suite support or the presence of TLS1.0 support, are not in scope.

What to expect

Upon submission of your vulnerability report, you can typically expect to receive an acknowledgment reply within 72 working hours of receipt.

Our team will triage the reported vulnerability and request further information if needed. This includes clarification on whether additional details are required, if the vulnerability falls within our scope, or if it's a duplicate report. If remediation is necessary, the task is assigned internally to the relevant team members.

Bug fixes or mitigations are prioritized based on the severity of impact and complexity of exploitation. Please note that triaging and addressing vulnerability reports may require some time. While you are welcome to inquire about the status of the process, we kindly request that you refrain from doing so more frequently than once every 30 days. This ensures our teams can dedicate ample focus to addressing the reports.

Upon resolution of the reported vulnerability or scheduling of remediation work, the Vulnerability Disclosure Team will notify you. You will also be invited to confirm whether the solution adequately addresses the vulnerability.

Qualifying vulnerabilities

It is 2023 and we assume you know the common vulnerability types that an online business may be affected by. As long as the issue constitutes a tangible risk to our security posture, customer data or similar, it is likely going to qualify. Please understand this is a discretionary decision we make on a case-by-case basis for every incoming report.

Examples:

  • SQL Injection (SQLi)
  • Cross-site scripting (XSS)
  • Remote Code Execution (RCE)
  • Insecure Direct Object Reference (IDOR)
  • Horizontal and vertical privilege escalation
  • Authentication bypass & broken authentication
  • Business Logic Errors vulnerability with real security impact
  • Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
  • Cross-Origin Resource Sharing (CORS) with real security impact
  • Cross-site Request Forgery (CSRF) with real security impact

Legalities

This policy is aligned with widely recognized best practices for vulnerability disclosure. It does not authorize any actions that are illegal or that might cause byrd to violate any legal obligations, including but not limited to:

  • The Computer Misuse Act (1990)
  • The General Data Protection Regulation 2016/679 (GDPR) and the Data Protection Act 2018
  • The Copyright, Designs and Patents Act (1988)
  • The Official Secrets Act (1989)

byrd affirms that it will not seek prosecution of any security researcher who reports a security vulnerability in a byrd service or system, provided that the researcher has acted in good faith and in accordance with this disclosure policy.

Reporting a vulnerability

If you have discovered something you believe to be an in-scope security vulnerability, first you should check the above details for more information about scope, then submit a vulnerability report via email to security@getbyrd.com.

In your submission, include details of:

  • The website or page where the vulnerability can be observed.
  • A brief description of the type of vulnerability, for example an 'XSS vulnerability'.

Whenever possible, your report should contain evidence of benign, non-destructive exploitation. This aids in swiftly and accurately assessing the report while decreasing the risk of duplicate submissions or malicious exploitation of vulnerabilities, such as subdomain takeovers.

Learn more about security at byrd

Your data is our responsibility.

Everything at a glance

Learn More about security at byrd. Meet the team responsible for the security.
Find out more.

security at byrd#

byrd's Security

How we secure our Digital Workplace, Infrastructure & Applications, Data and more. Find out more.

FAQs

One of byrd's security design principles is transparency. We've collected the most commonly asked questions. Find out more

Black and white image of people searching on computer.
As seen on