Security

We are very grateful to the security researchers and users that report back security vulnerabilities. We investigate every report thoroughly.

Privacy

Solo.io has a privacy policy page that discloses what information may be collected and how it is used.

Reporting a vulnerability

To make a report, send an email to the private security@solo.io mailing list with the vulnerability details. For normal product bugs unrelated to latent security vulnerabilities, please log an issue with the related project issue tracker.

When to report a security vulnerability

Send us a report whenever you:

  • Think any product or project led by Solo.io has a potential security vulnerability.
  • Are unsure whether or how a vulnerability affects the specific technology.
  • Think a vulnerability is present in another project that the Solo.io product or project depends on. For example, Envoy, Docker, Istio, or Kubernetes.

When not to report a security vulnerability

Don’t send a vulnerability report if:

  • You need help tuning components for security.
  • You need help applying security-related updates.
  • Your issue is not security related.

Evaluation

The Solo.io security team acknowledges and analyzes each vulnerability report within three work days.
Any vulnerability information you share with the Solo.io security team stays private. We don’t disseminate the information to other projects. We only share the information as needed to fix the issue.
We will keep the reporter updated as the status of the security issue evolves.

Fixing the issue

Once a security vulnerability has been fully characterized, a fix is developed by the Solo.io team. The development and testing for the fix happen in a private GitHub repository in order to prevent premature disclosure of the vulnerability.

Public disclosure

On the day chosen for public disclosure, a sequence of activities takes place as quickly as possible:

  • Changes are merged from the private GitHub repository holding the fix into the appropriate set of public branches.
  • Release engineers ensure all necessary binaries are promptly built and published.
  • Once the binaries are available, an announcement is sent out on the following channels:

As much as possible this announcement will be actionable and include any mitigating steps customers can take prior to upgrading to a fixed version.