How do you pin plugins and shared libraries in Jenkins?

To pin things in Jenkins, set a default version on every shared library and refuse overrides, reference libraries by tag or commit, and keep a written list of installed plugin versions that you reinstall from. Jenkins has no GitHub style action pins, so the work sits in two places: libraries and plugins.

What is there to pin in Jenkins?

Jenkins pulls outside code in through two doors.

1. Plugins, installed on the controller from an Update Center.
2. Pipeline shared libraries, fetched from source control when a build starts.

Neither is pinned by default in the sense a lockfile would pin a package. Each build can run whatever the library branch currently holds, and a new plugin version can arrive the next time an admin presses update.

How do shared library versions work?

The Jenkins handbook says a library has a name, a retrieval method, and optionally a default version. The version can be anything the SCM understands; for Git that means branches, tags and commit hashes all work. A Jenkinsfile can ask for one with a version specifier, and the handbook shows @Library('my-shared-library@1.0') _ and a commit style otherlib@abc1234.

Three settings decide how firmly that version holds:

• If no default version is set, the pipeline must name one. The handbook's example uses a branch, @master, which is the moving target you want to avoid.
• If "Allow default version to be overridden" is enabled, a Jenkinsfile can request a different version. The handbook notes that if you specify a version in Jenkins configuration, you can block scripts from selecting another.
• "Load implicitly" libraries are used by every pipeline at the default version, with no annotation needed.

A constructed case: a team keeps its deploy helper in a library on the main branch. A merged change breaks every pipeline at once because the default version is main. If the library were pinned to tag v2.3.0, the change would sit unused until someone bumped the tag.

What about libraries you did not configure?

The handbook describes a retrieval method in which the GitHub Groovy Libraries plugin lets a script use an untrusted library named like github.com/someorg/somerepo with no additional configuration; the repository is loaded from the master branch with an anonymous checkout. That is convenient and also a way for a script author to pull a repository nobody reviewed. Treat that feature as something to disable or restrict unless you need it.

Trusted global libraries run with more power. The handbook says libraries marked trusted can run any methods in Java, Groovy, Jenkins internal APIs, Jenkins plugins or third party libraries. Review changes to them like production code and pin them to a reviewed tag.

How do you pin plugins?

Jenkins does not offer a native lock for plugin versions on modern controllers. The handbook states the old pinned plugins feature was removed in Jenkins 2.0. The practical alternatives are procedural:

• The Update Center only offers the latest release of a plugin. To use an older release an admin downloads that archive and installs it manually.
• The CLI command install-plugin accepts a file, a URL or a short name, so automation can install from an artifact store you control.
• The Script Console can list every installed plugin with its version, which gives you a baseline to commit to a repository.
• The Plugin Manager shows a health score per plugin, which helps with deciding when a version is worth leaving.

Keep the plugin list in version control, rebuild test controllers from it, and bump versions in a pull request.

How to check or apply this

1. Export the current plugin list with versions and commit it.
2. Install plugins in automation from an internal artifact location instead of clicking in the UI.
3. Set a default version on every shared library, using a tag or commit.
4. Turn off "Allow default version to be overridden" where you can.
5. Search Jenkinsfiles for library references to branches such as master or main and replace them.
6. Restrict or disable dynamic retrieval of arbitrary GitHub libraries.
7. Add a scanner to the pipeline so that new plugin and dependency advisories are matched against what you pinned.

Quick check

Sources

• Jenkins handbook, Extending with Shared Libraries
• Jenkins handbook, Managing Plugins
• Jenkins handbook, Securing Jenkins

Last reviewed: 18 October 2026.