Plumber.
Build clean.
Ship with confidence.

Your delivery process is part of your infrastructure

Continuous integration and continuous delivery connect a proposed change to something an organisation may eventually run. Along that path, jobs execute tools, retrieve dependencies, build packages, handle credentials and publish artefacts. For me, this is enough reason to treat the pipeline as a system with its own architecture, owners and security boundaries.

A workflow can be short and still carry significant authority. A few lines may determine whether an external contribution runs in a privileged context or whether a publication job receives a powerful token. The small size of a YAML file tells us very little about the importance of its decisions.

GitHub's own guidance recommends narrowly scoped token permissions, full commit hashes for action references and care around privileged workflows processing untrusted contributions. These are concrete engineering controls, with consequences for what code can run and what it can reach. GitHub's secure use reference is a useful companion to this discussion.

My definition of a clean pipeline is quite practical: someone else should be able to read it, identify the boundaries, understand a failure and review a change without reconstructing six months of conversations. Good naming, small jobs, explicit permissions and a clear release path make that possible. Security becomes easier to maintain when the delivery process is understandable.

What Plumber brings to the workbench

Plumber's open-source CLI analyses GitHub Actions and GitLab CI pipelines and repository settings. Its documented checks include unpinned actions or images, remote scripts executed through a shell, and missing protection on the default branch. Results can be consumed in the terminal or exported, including as JSON and SARIF.

That combination matters to me. The engineer needs a finding they can investigate close to the code. The security team needs a result they can track. A machine-readable report gives us a foundation for connecting the two without asking somebody to manually retype a screenshot into a spreadsheet.

The Plumber website distinguishes the CLI, with advisory fixes, from a broader platform offering with organisation-wide visibility, history, drift alerts and AI-assisted remediation. I see two useful scales here: start with a repository you own, then consider how you will maintain visibility across a portfolio. Choose the deployment and data flows that fit your organisation.

The attractive part is how easily the subject becomes tangible. Open a finding, inspect the relevant workflow, discuss the intended behaviour and propose a reviewable change. You have something specific to improve. That is a much better starting point for collaboration than asking a team to simply “make the CI more secure”.

One technical subject, three management conversations

A CISO, a CIO and a GRC practitioner can look at the same finding and ask different, equally reasonable questions. The value of shared evidence is that they can discuss the same underlying change while keeping their own responsibilities clear.

For the CISO, I would start with authority and reach. A weakness in a throwaway test job and a weakness in a job that publishes production packages deserve different conversations. The finding needs context: exposed credentials, accessible environments, trusted inputs and the opportunities for a change to cross those boundaries.

For the CIO, I would connect remediation to operational continuity. A control that everybody bypasses because it breaks the delivery process will be expensive to maintain. Give the team time to test the fix, document the expected behaviour and make the safe path usable. The resulting process should be understandable when the original author is on leave.

For GRC, I would preserve the chain between the requirement, the implementation and the observation. A report has more value when it identifies a repository, a revision, a date and the configuration used. Add the remediation record and a fresh result, and you have a decision that another person can examine.

Plumber can contribute technical evidence to that work. Establishing compliance with a particular framework still requires scoping, control mapping, assessment and organisational judgement. A scanner's grade cannot perform those responsibilities on its own.

Three situations worth discussing with your team

A dependency reference changes under your feet

Imagine a release workflow referring to a third-party action through a movable tag. The repository itself may not change when the code behind that reference changes. My response would be to review the dependency, pin the selected commit, assign ownership for updates and test each proposed update. Plumber's documented unpinned-reference checks make this a useful first conversation. Pinning creates a review point; keeping that reference current remains ongoing work.

A check passes because the policy became weaker

Imagine a pull request that removes an inconvenient control from the scanner configuration. The next run looks healthier, but the intended requirement has changed. My recommendation is to review policy changes with the same care as workflow changes. Keep the previous result, explain the change and record who accepted it. A rising score should be interpretable against a known baseline.

An exception never finds its way back to an owner

Imagine a temporary exception accepted during an urgent delivery. Two months later, nobody can explain its scope or whether the reason still applies. I would give each exception an owner, a rationale, an expiry and a follow-up action from day one. Automated findings help keep the technical subject visible; the team must supply the accountability around it.

These are illustrative operating scenarios. They are also a useful way to introduce pipeline security without turning the discussion into a competition over who can list the most tools. Pick one real workflow, follow its authority and decide what you would improve first.

A concrete example from SysWarden

I apply the same reasoning to my own project. In the SysWarden Plumber workflow checked on September 30, 2026, the downloaded report for revision 3e66ea186f5b recorded a grade of A, with 100/100 points, and no critical, high, medium or low findings in that report.

I am pleased with that result. I also want the claim to stay precise: it describes this pipeline analysis, on this revision, under the configuration and checks used for that run. It is neither a universal security certification nor a native runtime test verdict. A future workflow or policy change deserves a fresh assessment.

That distinction is especially relevant while SysWarden v4.10.0 is undergoing validation. Our policy calls for Integration, Verification and Validation, or IVV, for intermediate releases, and adds full Qualification for Upgrade generations such as v5.00.0 LTS. Pipeline checks contribute to the evidence around delivery. Native tests, migration checks, restoration checks and release acceptance have their own work and their own verdicts.

My ambition is to make every positive statement traceable to the evidence that supports it. A grade is a welcome result. A dated result that someone can inspect is more useful still.

Start with one repository. Make the result useful.

If you want to try Plumber, begin with a repository you are authorised to assess and a workflow whose purpose you understand. The official GitHub guide covers local scans, authentication, CI integration, report uploads and score thresholds. Follow the current instructions for your environment and review the requested permissions.

I would run an initial assessment, read the findings with the maintainer, then choose a small number of changes with clear security value. Make each change through review and test the affected delivery path. Keep the original report and the result after remediation. This gives the team a useful before-and-after record and a chance to understand the tool.

Once that baseline is understood, decide which conditions should block a merge or release. Plumber supports a minimum score gate; the details belong in a reviewed policy that the team can explain. Decide how incomplete collection and unverified checks are handled too. A job that could not inspect something should remain visibly different from a verified passing result.

Keep reporting choices deliberate. The official integration documents that enabling public score publication shares the repository name and score with the hosted score service. That may be appropriate for a public project. For an internal repository, make the visibility decision with the relevant owner before enabling it.

Then keep the process alive: review changes to workflows and scanner configuration, assign findings to people, revisit exceptions and verify the integration after updates. My preferred outcome is a routine that the team can maintain calmly, including on a busy release day.

Why I am proud to support Plumber

I like solutions that help different professions work on the same problem. Plumber gives developers something concrete to inspect, security teams something actionable to discuss, and management a starting point for asking better questions about software delivery.

Its open-source foundation matters to me too. The repository gives us a place to inspect the implementation, raise a well-documented issue and contribute an improvement. That makes the relationship with a security tool more constructive: when something needs clarification, there is a visible project and a technical conversation to join.

As an ambassador, I want to encourage that kind of adoption. Try it, read the findings, challenge the assumptions and share useful feedback. Give the team behind Plumber a reproducible example when you find a problem. Celebrate the improvements you can demonstrate, and keep working on the next one.

We ask users to trust the software we deliver. Taking care of the process that creates it is part of earning that trust. Plumber is an excellent ally in that effort, and I am very happy to help bring it to more teams.

Build something useful. Take care of the pipeline. Keep the evidence. That is a direction worth backing.