Software installed into a running system, such as plugins added through an admin screen, never passes through your repository, so a manifest or lockfile scan cannot see it. To cover it, inventory plugins from the running system itself and feed that list into the same vulnerability process.
How runtime installs work
The Jenkins documentation describes two methods for installing plugins on the controller: using the Plugin Manager in the web UI, or using the Jenkins CLI install-plugin command. Either way, the plugin is loaded by Jenkins from an update center, not from your source tree. The same pattern appears in content management systems, IDEs, chat platforms and many internal tools.
Nothing in version control records the change unless you make it do so.
Why scanners miss it
Scanners read what they are pointed at. A plugin installed through a UI lives in a data directory on a server, so unless the scanner reads that server, it is absent from results. Meanwhile plugins are code with broad access, and advisories for them are common.
| Install route | Recorded in repository | Seen by manifest scan |
|---|---|---|
| Declared in a build file | Yes | Yes |
| Plugin list file applied at deploy | Yes | If the file is parsed |
| Added by hand in an admin UI | No | No |
| Added by an automation script | Only the script | No |
Build an inventory
- List every system that supports plugins: CI servers, CMS sites, wiki tools, IDE fleets.
- For each, find the command or API that lists installed plugins with versions.
- Export the list on a schedule to a central file or your SBOM system.
- Match the names and versions against advisories as you would for libraries.
- Record the owner of each system, so findings have a home.
Move toward declared plugins
Better than inventorying drift is stopping it. Where the platform supports it, keep the plugin list in a file under version control and apply it at deploy time, so the repository becomes the record. Then a lockfile style scan sees the plugins. Restrict who can install plugins by hand.
Update discipline
Plugins often lag behind. Some are abandoned. See Jenkins plugin unfixed vulnerability: what happens and what to do for the options when no fix exists: remove, replace or isolate.
A quarterly review
Once a quarter, compare the plugin inventory to what the team believes is installed. Remove anything unused. Every plugin removed is attack surface and scanner noise gone. See also does a dependency scan cover scripts loaded from a CDN for another off repository dependency.
Safeguard offers asset discovery, SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan. Whatever tool you use, include runtime installed software in scope.
Quick check
Are plugins part of my software supply chain?
Yes. They are third party code running with the privileges of the host system.
Who should be allowed to install plugins?
A small named group, with changes recorded. Open install rights make the inventory unreliable.
Sources
Last reviewed: 19 October 2026.
