Security and network

This page covers what the sfpm actions need from your repository and runner, what they send over the network, and how they handle credentials. It is written for teams that review workflows before they run them.

Token permissions

Set contents: read on your workflow. It is enough for every action.

permissions:
  contents: read

The actions do not read GITHUB_TOKEN. They take no github-token input and make no GitHub API calls. validate-pr reads the PR number and base SHA from the event payload only. Nothing requires write scope.

Credentials

The actions assume the DevHub and target orgs are already authenticated in the runner. Your workflow owns that step, usually with sf org login jwt and secrets stored in your repository.

• Installation keys and auth URLs are registered as secrets, so the runner masks them in logs.
• validate-pr in mode: org caches only the scratch org username and org ID, in the GitHub Actions cache, keyed by PR number. It does not cache an access credential. On a cache hit, it re-authenticates through the DevHub.
• The GitHub Actions cache is readable by any workflow in the repository. Treat it as shared state, not as a secret store.

Network egress

The table lists every destination the actions can reach.

Loading an action downloads nothing. The action code ships in the release tag commit. The destinations in the table are used only by the operations that need them.

A registry mirror is supported for the package installs in install and deploy. npm's default replace-registry-host behavior applies to those registrations, so an internal mirror only needs to be allowed for that use.

There is no telemetry. Tracing uses OpenTelemetry only when you set OTEL_EXPORTER_OTLP_ENDPOINT to your own collector. The codebase has no default or fallback endpoint.

Install scripts

Package installs in install and deploy use npm install --no-save --ignore-scripts. Lifecycle scripts of installed packages do not run on the runner. Artifacts are treated as data (source and manifests), not as code to execute at install time.

Runtime environment

The bundled actions set SF_DISABLE_LOG_FILE=true unless your environment already sets it. This disables file-based logging in @salesforce/core. Logs stay in memory, which suits ephemeral runners. Child processes started by the actions inherit the setting.

Allowlisting

If your organization allowlists actions, reference the actions by sub-path (b64hub/sfpm/packages/actions/<name>), not the bare repository. An allowlist entry for b64hub/sfpm alone may not match.

The expected entry format is b64hub/sfpm/packages/actions/*@<sha>. This format has not been verified against a real organization policy. Confirm it in your own organization before you rely on it.

The sfpm actions do not use any further uses: references. The allowlist footprint is the sfpm actions themselves. A typical build workflow also uses:

• actions/checkout
• actions/setup-node
• actions/upload-artifact and actions/download-artifact, when a build passes dist/ output between jobs
• pnpm/action-setup, when a publish job runs sfpm publish, which calls pnpm publish

Release bundle

Each action's action.yml points at an esbuild bundle. The bundle is built at release time from the tagged source and exists only on the commit that a release tag points to. The bundle build script and the bundle source are in the repository for review.

To check a release, rebuild the bundle from the tag's parent commit and compare the output with the bundle at the tag. Byte-identical output is not yet a guaranteed property of the build. Use the comparison as evidence, not as proof.

Reporting a vulnerability

Report suspected vulnerabilities privately through GitHub Security Advisories. Do not open a public issue. The maintainers acknowledge reports within five working days.