Security

Isolation

Every job runs in a fresh container with a workspace created for it and removed when it ends. Machines are reused between jobs. A job from a fork's pull request is the last job its machine runs, and the machine is then terminated; an idle machine terminates after five minutes. Caches and artifacts are scoped to the repository that wrote them.

Credentials

Apex never holds a long-lived cloud credential on your behalf. permissions: id-token: write gives a job a short-lived identity token, which the job exchanges for credentials that expire with it. Our own infrastructure follows the same rule: no long-lived cloud keys for people, for CI, or for workloads.

Secrets

A secret is a write-only value. It is sealed at rest with KMS and opened only when a job of a trusted run in its repository starts; a fork's pull request gets none. It is masked in logs and never printed. The local-reproduce command names every secret a job used and never includes its value.

The GitHub App

The App asks for checks (read and write), to report each job; contents, pull requests and workflows (read and write), so that pinning actions can be proposed as a pull request; actions, metadata and secrets (read — secret names only); organisation members (read), to tell who owns an organisation, for paying for its installation; and organisation administration (read), used only to read your Actions billing for the savings figure; and packages (read and write), so a job's GITHUB_TOKEN can pull from the GitHub Container Registry. It receives webhooks and does not poll.

A job's GITHUB_TOKEN is a short-lived token minted for that job. It reaches only the job's own repository, carries at most these permissions, and is narrowed by the workflow's permissions:. A job from a fork's pull request gets a read-only token for its own repository.

Reporting a vulnerability

Write to security@apexactions.com. We acknowledge within one business day, keep you informed while we investigate, and credit the report if you want us to. Please do not test against another customer's data.

Safe harbour

Security research done in good faith, within the rules below, is authorised. We will not bring or support legal action against you for it, we will not treat it as a breach of the terms of service or the acceptable use policy, and if a third party does, we will say so. In return:

• Test only against what is yours. Use your own account, your own installation and your own repositories. Never another customer's data, jobs or secrets, and never our production infrastructure beyond what a customer's own job can reach.
• Stop at proof. Once you can show the issue, stop. Do not read, change or delete data that is not yours, do not pivot further, and do not keep what you found.
• No denial of service, no social engineering, no physical attacks. Volume, phishing and pretexting are out of scope and are not research.
• Give us time. Tell us first, in private, and give us ninety days to fix it before you say anything publicly. We will keep you informed, and we will tell you when it is fixed so you can publish.

In scope: apexactions.com, app.apexactions.com, the GitHub App, the job isolation on our runners as reached from your own job, and the apex command-line tool. Out of scope: anything hosted by a third party, findings that require a compromised customer account, and reports from automated scanners with no demonstrated impact.

We do not currently run a paid bounty programme. We do credit reports, we do say thank you, and we do fix things.