Skip to main content
Version: Next

Reporting a Vulnerability

The thin-edge.io project welcomes reports about security vulnerabilities, and asks that such reports are made privately so that a fix can be prepared before the problem becomes publicly known.

caution

Never report a suspected vulnerability through a public GitHub issue, pull request or discussion, and never post a proof of concept in a public forum. Use the private reporting channel described below.

Scope​

This process covers the software which is published from the thin-edge/thin-edge.io repository: the tedge command line interface, the mapper, the agent and the plugins which are built and released from that repository.

It does not cover community plugins and other community extensions, even when they are hosted under the thin-edge organization. Those are maintained independently and are outside the responsibility of the thin-edge.io maintainers. Report a vulnerability in a community plugin to the maintainers of that project, following whatever process its own repository documents.

If you are not sure whether a component is in scope, report it anyway. A report which turns out to be out of scope is redirected rather than ignored.

How to report​

Vulnerabilities are reported using GitHub's private vulnerability reporting, which is enabled on the thin-edge.io repository. A report creates a draft security advisory that is visible only to you and the thin-edge.io maintainers.

  1. Open the new advisory report form.

    You can also reach the same form from the repository itself, by selecting Security → Advisories → Report a vulnerability.

  2. Fill in the form, using the guidance in What to include in a report.

  3. Submit the report.

You need a GitHub account to submit a report, as the whole exchange with the maintainers happens in the comment thread of the draft advisory. You are notified there of any update, and you can keep adding information to the report at any time.

What to include in a report​

A good report is one that lets a maintainer reproduce and assess the problem without a lengthy exchange. The Cumulocity responsible disclosure policy describes what makes a good security report, and the same expectations apply here.

Try to provide the following information:

  • Affected versions: the output of tedge --version, and whether older or newer versions are affected.
  • Affected components: which binaries, plugins or services are involved, for example tedge-mapper, tedge-agent or tedge-p11-server.
  • Environment: the operating system, architecture and how thin-edge.io was installed, for example a Debian package, a container image or a build from source.
  • Configuration: the settings which are relevant to the problem, for example how the MQTT and HTTP listeners are bound, or how the device certificate is stored.
  • Reproduction steps: a minimal, step-by-step description, including any commands, MQTT messages or HTTP requests needed to trigger the problem.
  • Impact: what an attacker can achieve, and what access is required to do so, for example local access to the device, access to the local network or access to the cloud tenant.
  • Mitigation: any workaround or configuration change which reduces the impact, if you know of one.
  • Disclosure status: whether the problem is already known publicly, and whether you intend to publish anything about it.
caution

Remove secrets from anything you attach to a report. Log files, configuration dumps and packet captures may contain private keys, device certificates, cloud credentials, tokens and tenant URLs.

What happens next​

  1. A maintainer acknowledges the report and starts the assessment. Questions and clarifications are exchanged in the comment thread of the draft advisory.

  2. If the report is accepted, the maintainers determine the affected versions and the severity, and prepare a fix privately. You are informed about the outcome of the assessment, including when a report is rejected and why it is not considered to be a vulnerability.

  3. The fix is released and an advisory is published, as described in Security Advisories.

  4. Unless you ask otherwise, you are credited in the advisory as the reporter.

Please keep the details of the report private until the advisory has been published.

Vulnerabilities in dependencies​

thin-edge.io is built from a number of third-party components, and vulnerabilities are regularly disclosed against them.

  • If a vulnerability in a dependency is exploitable through thin-edge.io, report it privately as described above, even when the upstream problem is already public, so that the impact on thin-edge.io can be assessed and a release prepared.
  • If you only want to point out that a dependency should be updated, and the vulnerability is not exploitable through thin-edge.io, then a normal GitHub issue is enough.

Vulnerabilities in a cloud platform​

thin-edge.io connects to cloud platforms such as Cumulocity, AWS IoT and Azure IoT, but it is not part of them. A vulnerability in the cloud platform itself has to be reported to its vendor. For Cumulocity, follow the Cumulocity responsible disclosure policy.