Declare every plugin in a required_plugins block with an explicit source and a version, run packer init in CI, and review any third-party plugin before approving it. HashiCorp's own documentation recommends that you vet and verify third-party plugins, because image builds run them with your cloud credentials.
Why image builds are a dependency surface
Packer builds machine images, which then become the base for servers. The build uses plugins for builders, provisioners and post-processors. Each plugin is a program Packer downloads and runs. If an image build is compromised, every server started from that image inherits the problem, so plugin choice is a supply chain decision.
What the required_plugins block does
Packer documentation says the block, available from Packer 1.7.0, maps each local plugin name to a source address and a version constraint. It records two things it calls critical for reproducible builds: where the plugin was downloaded from, and which version, exact or minimum, the build needs. It suggests this as a way to pin approved versions across your team.
The source follows a hostname, optional subfolder, namespace and type layout. Use github.com for plugins published as GitHub releases. Any other hostname must be an HTTPS endpoint serving the required directory structure, such as an internal mirror or artifact repository.
Constraint choices
| Constraint style | Effect | Risk |
|---|---|---|
| Minimum, such as at least a version | Any newer release satisfies it | A new release is picked up on the next init |
| Exact version | One version only | Updates need an edit |
The docs show a minimum constraint in their example, but note that you can pin exact versions. For anything that touches production images, an exact version is easier to review and reproduce.
What packer init does
The init command downloads and installs plugins listed in required_plugins. By default it installs under a plugins directory in your home configuration folder, or in a path you set with the PACKER_PLUGIN_PATH environment variable. The command never deletes plugins that are already installed. An upgrade option moves installed plugins to the newest version that still satisfies your constraints.
Two details for CI. First, Packer also checks the plugin directory against your template when you build, and manually installed plugins must still satisfy the constraints in the template. Second, installed plugins in a shared runner persist, so use a clean, pinned environment or key the plugin cache on your template.
Vetting a third-party plugin
- Read who publishes it and whether the repository is maintained.
- Check the release assets include a checksum file. The installation docs describe a SHA256SUM file as required to load a plugin from a remote source.
- Read what the plugin does with credentials and network access.
- Pin the exact version in required_plugins and record why you approved it.
- Prefer an internal mirror for approved plugins, so builds do not depend on a public service being available or unchanged.
Do not treat the checksum as proof of trustworthiness. It shows the file matches what the publisher listed, not that the publisher is safe.
Keep builds and approvals in step
Add a CI check that fails when a template has a plugin source outside your approved list. Keep the approved list in the repository, reviewed like code. When a plugin needs updating, change the version in a pull request and rebuild a test image first.
Where a scanner fits
Images built by Packer still contain operating system packages and libraries. Safeguard's SBOM generation and dependency scanning can inventory what is in your built artifacts, and policy gates on pull requests can hold changes to templates until they are reviewed. Check your scanner's support for the formats you build. A free scan is at gold.safeguard.sh/scan.
Quick check
Does packer init remove old plugins?
No. The documentation says the command never deletes already installed plugins, though later runs may produce errors.
Does Packer support JSON templates for packer init?
No. The init documentation says legacy JSON templates are not supported and suggests converting them to HCL.
Sources
- packer init command reference, HashiCorp
- Packer block and required_plugins, HashiCorp
- Install plugins, HashiCorp
Last reviewed: 19 October 2026.
