Sometimes, yes. To regenerate lockfiles, update tools run your package manager, and for a few ecosystems the manifest itself is executable code. One widely used bot disables external code execution once you give it registry access, and makes you opt in. Treat this as a security question when you evaluate a tool.
Why an update can execute code
Not every manifest is plain data. In some ecosystems a manifest file is a script, so computing the new dependency set means running it. The documentation of one major bot says this applies to bundler, mix and pip, and has a setting to allow the tool to execute external code in the manifest during updates.
Separately, a tool that updates lockfiles usually does not parse each lockfile format itself. The documentation of another bot says it uses the package managers themselves, run as shell commands, because trying to reverse engineer each format is brittle. That means credentials and the project's configuration reach a real package manager process.
What the safeguards look like
According to the first bot's reference, when you give it access to one or more private registries, external code execution is automatically disabled to protect your code from compromised packages. As a result, some version updates may fail. If you set the allow value, the manifest code runs during the update, and the code has access only to the package managers in the registries associated with that update entry.
That is a clear trade. Safe by default, with some failures, and an explicit opt in that scopes access.
The second bot's documentation adds a related point on credentials: they are reformatted into environment variables or config files that each package manager understands. If conversion is missing for some manager, updating artifacts can fail, which is a safe failure, not an open door.
What could go wrong
| Risk | Scenario |
|---|---|
| Malicious package executes during update | A manifest or install script pulls hostile code that runs with the update job's access |
| Credential exposure | A registry token available to the job is read by executed code |
| Lateral reach | The job runs on a shared runner with network access to internal systems |
| Silent drift | An opt in setting is enabled once and forgotten |
Questions to ask before you enable a tool
- Where does the update job run: the vendor's infrastructure, or your runners?
- What network access does it have? Can it reach internal services?
- Which credentials are available to it, and are they read-only?
- Does it execute manifest code or install scripts when regenerating lockfiles, and can that be turned off?
- What is logged, and for how long?
- Is the opt in setting recorded in your configuration and reviewed?
Hardening steps
- Keep the default that blocks external code execution, and accept some failed updates.
- If you must allow it for one ecosystem, scope it to that entry only and note why.
- Run self-hosted update jobs on isolated runners, with network egress limited to the registries they need.
- Give the job read-only registry credentials.
- Combine with a delay on brand new releases so a hostile release is more likely to be found and pulled before it reaches you. Our post on delaying new releases with a cooldown explains the trade.
Quick check
Is it safe to allow manifest code execution for one ecosystem?
It is a risk you accept knowingly. Scope it to one update entry, use read-only credentials and isolate the runner.
Why did some updates start failing after I added a registry?
In the documented behavior, adding registry access turns off external code execution, so updates that need it fail.
Safeguard scans your dependencies for known advisories and builds an SBOM from manifests and lockfiles, so you can see what a new version brings in before merge. Policies and gates check pull requests. Fix pull requests are off by default, with every category on Manual. A free scan is available.
Sources
- Code host documentation: update bot options reference, external code execution
- Update bot documentation: private package support and artifact updating
Last reviewed: 19 October 2026.
