A SwiftPM build tool plugin runs in a sandbox that blocks network access and restricts file system access. It can read the package directory and write to specific output directories. The proposal still names the risk of running third party build tools, so review plugins as you would any code that runs during your build.
What a plugin is
Under Swift evolution proposal SE-0303, a plugin is a Swift script in a plugin target that uses the PackagePlugin API. It does not do the build work itself. It returns build commands. SwiftPM runs it after package resolution and before building, once for each target that lists it.
What it can and cannot do
| Area | Allowed or blocked |
|---|---|
| Network | Blocked by the sandbox |
| Read | The package directory, target context, input files, dependency closure |
| Write | A per plugin work directory and the built products directory |
| Tools | Executables from the plugin's declared dependencies |
| Libraries | PackagePlugin and the Swift standard library at first |
Each generated build command also runs in a sandbox that blocks network access and allows writes to the output directories the plugin names.
Where the risk remains
The sandbox limits damage, but a plugin still runs on developer machines and CI. It runs the tools it declares, and those tools generate code that is compiled into your app. A malicious or compromised plugin could generate source that behaves badly at runtime, even if it cannot call out during the build.
The proposal says plainly that running third party build tools carries inherent risk. It suggests that requiring the root package to approve plugins could help, and defers that to a later proposal. Check current Xcode and SwiftPM behaviour for how approval works today.
A review checklist
- List every plugin your dependency graph brings in, including transitive ones.
- Read what each plugin generates and which tools it runs.
- Prefer plugins from maintainers you can identify, and pin their versions.
- Re-review when a plugin updates, as you would for any code dependency.
- Keep plugin versions in your dependency inventory, next to libraries.
- Run CI builds with the same resolved versions you reviewed.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change to dependencies can be checked before it merges, which is where a new plugin should be reviewed.
Safeguard builds an SBOM and scans your dependencies for known vulnerabilities, and you can run a free scan at gold.safeguard.sh/scan to see what your own project pulls in.
Quick check
Can a build tool plugin call a server?
Per SE-0303 the sandbox prevents network access for the plugin and its generated commands.
So are plugins safe by default?
They are constrained, not risk free. Generated code still ships in your app, so review the plugin and pin it.
Sources
Last reviewed: 19 October 2026.
