Skip to main content

​
Authentication and Integrations

  • GitHub and Slack integrations use OAuth flows.
  • Request signatures are validated for Slack and GitHub webhooks.
  • OAuth state and PKCE protections are used in the Slack-initiated GitHub flow.
For detailed Slack OAuth scopes and rationale, see Slack Permissions.

​
Token Handling

  • Integration tokens are stored server-side.
  • Reconnect flows are supported when tokens expire or are revoked.

​
Data Scope

GitNotifier stores only data needed to deliver notifications and preferences (for example, account mapping and reminder/mute preferences).

​
Team Access Model

  • Only the admin needs to complete initial app setup.
  • Team members connect later via invitation or Slack App Home flow.

​
Platform and Infrastructure Security

GitNotifier is built entirely on the Cloudflare platform and runs on serverless runtimes (Cloudflare Workers). This makes our workloads safer than traditional VMs or Docker containers, for several reasons:
  • No servers to compromise. There is no long-lived VM, host OS, or container image that we operate, patch, or harden. There is no SSH, no shell, and no persistent host an attacker could pivot into.
  • Strong isolation. Each request runs in a lightweight, memory-isolated V8 isolate rather than a shared VM or container. The attack surface is far smaller than a full operating system with its libraries and background daemons.
  • Ephemeral and stateless. Execution is short-lived and stateless, with no persistent local filesystem and no background processes. There is nothing for malware to install into or persist across requests.
  • Automatically patched. Cloudflare keeps the underlying runtime current across its global network, which removes an entire class of “unpatched host” and outdated base-image risks that VMs and containers carry.

​
Dependency Security

We keep our dependencies current automatically with Renovate. Renovate opens pull requests to pull in the latest releases and patch known CVEs promptly, so we do not sit on outdated, vulnerable packages.

​
Supply Chain Protection

We use pnpm to reduce the risk of supply chain attacks. When an npm package is compromised, there is a window between when the malware is published and when it is detected and removed from the registry. pnpm gives us a buffer during that window through several mitigations:
  • Blocked install scripts. pnpm does not automatically run postinstall scripts for dependencies, which is the mechanism most compromised packages use to execute code on install.
  • Release-age delay. pnpm delays installing newly published versions until they have aged (the minimumReleaseAge setting), so a version that is later found to be malicious is most likely pulled from the registry before we ever install it.
  • Committed lockfile. Our lockfile is committed to the repository, so installs are reproducible and dependencies do not update unexpectedly.
For the full list of pnpm supply chain mitigations, see Mitigating supply chain attacks.