nandi.uk / gleam
Fork of daniellemaywood.uk/gleam — Wasm codegen work
2
Fork 0

Configure Feed

Select the types of activity you want to include in your feed.

gleam / docs / threat-model.md
5.7 kB

Public threat model#

Last updated: 2026-04-23

For vulnerability reporting please see the GitHub Security Advisories page.

In scope#

  • The Gleam compiler, build tool, language server, formatter, Hex package manager client, and Wasm interface, all located in the gleam-lang/gleam GitHub repository.
  • The precompiled binaries for Gleam published to GitHub releases for the gleam-lang/gleam GitHub repository.
  • All Gleam packages within the gleam-lang GitHub organisation and their Hex publications.
  • Gleam's GitHub Actions CI workflows and GitHub code repositories.
  • The Gleam websites:

Out of scope#

  • Security of third-party Gleam packages published to the Hex package manager.
  • Security of Hex package management system server-side components.
  • Securing of runtimes used by Gleam code, such as Erlang's BEAM and JavaScript's V8.
  • Security of third-party operating system packages and installers for Gleam.

Assumptions#

  • Third party providers such as GitHub, and Vultr meet their security obligations and are not compromised.

Threats#

GitHub account phishing or hijacking#

A bad actor could attempt to gain access to a GitHub account.

  • MFA is enforced for GitHub accounts.

Malicious or compromised Gleam GitHub organisation member account#

A bad actor with a gleam-lang member account could attempt to interfere with code repositories, actions workflows, and the content of issues, pull requests, and discussions.

  • Pull requests and reviews are required for making changes to code.
  • Regular members do not have permissions to perform destructive actions on GitHub.
  • Vandalised content within issues, pull requests, and discussions can be restored by GitHub support.
  • Gleam's GitHub Actions workflows can be re-run without any side effects beyond using workflow minutes.

Hex account phishing or hijacking#

A bad actor could attempt to gain access to a Hex account.

  • MFA is enforced for Hex accounts.

Malicious or compromised Hex account#

A bad actor with access to a Hex account could attempt to publish malicious versions of Gleam packages.

  • Hex requires MFA for destructive actions such as package publication.
  • Hex is immutable and existing package versions cannot be modified after publication.
  • Hex provides tooling for viewing diffs between package versions to aid with auditing new code.
  • Hex's security team will remove malicious package releases.
  • Gleam's Hex client always uses version locking to prevent differing versions of dependencies from being added unintentionally.

Vultr account phishing or hijacking#

A bad actor could attempt to gain access to a Vultr account.

  • MFA is required for Vultr.

Vultr VPS infiltration attacks#

A bad actor could attempt to gain access to the Vultr VPS.

  • SSH authentication uses SSH keys and password authentication is disabled.
  • The VPS has a restrictive firewall enabled.
  • The VPS has automatic OS security updates enabled.
  • Minimal software is installed on the VPS and all workloads run inside containers.

Compromised Vultr VPS#

A bad actor with root access to the VPS that serves the packages site could steal data from it or vandalise the website.

  • No secrets are stored on the VPS.
  • All configuration for the VPS is stored on GitHub so the VPS can be destroyed and replaced quickly and easily.
  • The packages website data is public, so there is no threat of theft of private data.
  • The packages website data can be recomputed from Hex and is backed-up externally, so there is no threat of permanent data loss.

Malicious or compromised Rust dependency#

A bad actor with access to publish new versions of our Rust dependencies could attempt to inject malicious code into the gleam binary.

  • We use Rust's dependency version locking to avoid unexpected versions of dependencies from being included in our application.
  • A cooldown period is used with dependabot to avoid including new dependency versions that may not have been security scanned yet.
  • Dependency versions are not upgraded shortly before or during the RC process, to minimise risk of new versions with vulnerabilities making it into a release.
  • The cargo-deny tool is used to alert when a dependency version used has a published CVE.
  • GitHub code scanning and CodeQL is enabled to alert to further vulnerabilities.

Malicious or compromised Hex dependency#

A bad actor with access to publish new versions of our Hex dependencies could attempt to inject malicious code into the subtree of one of our Hex packages.

  • The Gleam core packages do not have any third-party dependencies.

Compromise or tampering of precompiled release binaries#

A bad actor could attempt to cause a malicious or modified binary to be published to GitHub Releases, or replace release assets after build.

  • The release workflow uses GitHub OIDC and artefact attestations to produce provenance for release assets, published alongside release archives as .sigstore files.
  • Checksums are provided for release archives for users' integrity checking.
  • The GitHub Actions workflow configuration files are scanned for vulnerabilities using GitHub CodeQL.
  • GitHub Action versions are pinned using SHAs, and use of tools such as gh is used instead of third-party Actions where possible.