back to article Jenkins warns of security holes in these 25 plugins

Jenkins, an open-source automation server for continuous integration and delivery (CI/CD), has published 34 security advisories covering 25 plugins used to extend the software. Eleven of the advisories are rated high severity, 14 are medium, and 9 are said to be low. The vulnerabilities described include: cross-site scripting …

  1. karlkarl Silver badge

    We always predicted that Jenkins was going to be a constant security hazard.

    We allow ours to only listen on localhost and then port forward 8080 through an SSH tunnel as needed. Likewise it uses an SSH tunnel to the SVN, Git and Perforce hosts so it can poll/pull updates. For all intents and purposes it is "offline".

    Though for some of our smaller projects we actually just prefer some ratty shell scripts scanning git repos and if a change is detected, doing a build and calling "make" in them. I feel most people can get away with just that.

    1. Ptothgriffiths

      Fully agreed. We did similar, used the open source technology my company created to make our Jenkins invisible to the internet. Outbound only connectivity. We used webhooks with embedded zero trust SDKs to connect it to any external public resources (e.g., GitHub).

  2. Kevin McMurtrie Silver badge

    Industry standard

    You're not doing modern DevOps unless you're throwing access tokens at the most blogged about Jenkins plugins and GitHub Marketplace tools in your CI pipeline.

  3. Anonymous Coward
    Anonymous Coward

    Advisory exhaustion

    These "Jenkins Security Advisories" come out a couple of times a month, on average. I subscribe to the feed and do a short write-up for our "Jenkins interest" Teams channel in the hope that at least some of the many, many people administering many, many Jenkins instances in our organization pay attention. (Some groups have proper Operations teams running it, but often it's left up to random developers.)

    Doing a write-up is useful because the format of the advisories is terrible. Severities are listed separately from the problem descriptions, for example.

    Unfortunately, I suspect that without dedicated staff, there are just too many of these and people get tired of trying to install what fixes are available, or culling plugins they have no real need for.

    And that's a problem, because Jenkins is not only a huge attack surface, but a particularly tempting one, since it's building software. And often developers have access to it, and developers are often among the worst users for security – running all sorts of things with excess privilege, downloading and running code and binaries of uncertain provenance, and so forth. An attacker compromising a developer's laptop and then pivoting through Jenkins to add malware to in-house or product software is an obvious and plausible tactic.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like