Skip to content

Vulnerability handling

This page describes how security vulnerabilities in LAVA are reported, triaged, and handled.

Reporting

Follow the Linaro Vulnerability Disclosure Policy (VDP), also published by security.txt (according to RFC 9116).

If you think you have found a security vulnerability in LAVA, send an email to the Linaro Product Security Incident Team (PSIRT) at psirt@linaro.org. We will do our best to respond and fix any issues as soon as possible.

When reporting, please include:

  • the affected component (server, dispatcher, worker, lava-dispatcher-host)
  • the LAVA version or git commit
  • steps to reproduce the issue
  • exploit code, if available

As with any bug, the more information you give, the easier it is to diagnose and fix.

Let us know your disclosure plans if you have any, as they might affect our disclosure plan. Indicate any sensitive information you don't want us to share; we reserve the right to share any information you give with trusted third parties and eventually the public unless you request otherwise.

If we consider the report not to be a security vulnerability, we will inform you and direct the bug to the normal support process.

Scope

In scope: the LAVA components in the lava repository: the LAVA server, dispatcher, worker, and lava-dispatcher-host.

Out of scope:

  • third-party dependencies; report those to their maintainers
  • operator-configured deployments; misconfiguration of the host system (systemd units, Docker, network) is the operator's responsibility

Process

The Linaro PSIRT handles reports with the following steps:

  1. Triage — the report is assessed to understand the potential impact.
  2. If we can reproduce the vulnerability, we carry the process through to disclosure.
  3. If we can't reproduce it, we inform you and close the report.
  4. If we consider the report not to be a security vulnerability, we inform you and direct the bug to the normal support process.
  5. Risk assessment — a risk-based decision is made whether the vulnerability will be remediated in the product or addressed through other means, for example risk acceptance or transference (such as configuration changes).
  6. Temporary remediation — we decide if and how the vulnerability can be temporarily mitigated, before providing a permanent solution.
  7. Permanent solution — if the risk assessment concludes that the vulnerability will be remediated in the product, we fix it as soon as possible. Depending on the impact and risk, the fix may be provided as a hotfix, in a release, or in a major release.
  8. Disclosure — vulnerability information is communicated as appropriate, for example by notifying affected users only or by publishing a public security advisory.

We also perform retrospective work and incorporate the lessons learned from any vulnerability into our processes and products.

Disclosure

Please do not disclose the vulnerability publicly until a fix has been released.

Frequently asked questions

  1. Do you have a bug bounty program? The LAVA project or Linaro does not offer a bug bounty program.