getplumber/plumber

Is your feature request related to a problem? Please describe. GitLab security policy workflows rely on a designated Security Policy Project. Teams standardize on one policy project ID so drift and wrong links are visible. Without automation, projects omit the link or point to the wrong project, weakening centralized policy and audit evidence. Product alignment: ISSUE-601 — Missing security policy source on project (docs today: Platform). CLI should emit ISSUE-601 when implemented. Describe the solution you'd like Add securityScanningPolicyMustBeLinkedToDesignatedProject: Input: Expected policy project ID or path in .plumber.yaml. API: Read where GitLab stores the linked policy project for the analyzed project (tier/version dependent; skip with a clear reason if unsupported — e.g. non-Ultimate, or the GraphQL field is unavailable on the user's GitLab version). Finding: ISSUE-601 when missing or not matching config. Severity: medium (project-level, not pipeline-level) Configurati

Is your feature request related to a problem? Please describe. Large projects often accumulate too many Maintainers or Owners, which bypasses branch protection intent and expands who can change CI/CD variables, runners, and protected branches. Some teams require at least N Owners for continuity. Branch protection in Plumber does not measure how many accounts hold each role. A member-quota check gives a clear pass/fail. Product alignment: ISSUE-507 — Members' role quotas are not respected for projects Describe the solution you'd like Add projectMemberRolesMustRespectQuotas: List project members via GitLab API. Count members per access level (Guest … Owner). Compare to configured min/max per role; emit ISSUE-507 when any role count falls outside its configured range. Configuration in .plumber.yaml gitlab: controls: projectMemberRolesMustRespectQuotas: enabled: true owner: min: 2 max: 5 maintainer: min: 0 max: 8 # deve

Is your feature request related to a problem? Please describe. GitLab has built-in support for JUnit test reports that display test results directly in merge request widgets. Plumber currently outputs JSON, terminal text, SARIF, and GLSAST, but none integrate with GitLab's test report visualization. Security and compliance findings would benefit from the same first-class treatment as test results: visible in the MR widget, with pass/fail indicators per control, without having to open the full job log or download an artifact. Describe the solution you'd like A new --junit flag (matching the existing --sarif / --glsast / --pbom naming) that produces a JUnit XML file where: Each Plumber control maps to a <testsuite> (one suite per control name). Each finding maps to a <testcase> with a <failure> element containing the message + remediation + doc URL. Controls that ran and found nothing produce a single passing <testcase> per suite (so the suite is visible in the widget even when clean).

Feel free to propose other implementation details / output structure. Is your feature request related to a problem? Please describe. Users who want to attach Plumber results to GitLab MR descriptions, wikis, or external documentation have no way to get a portable, readable text output. The current --output flag produces JSON only, and the terminal output uses ANSI escape codes that don't copy-paste well. The existing MR-comment rendering (control/mrcomment.go) covers the MR widget path but is not surfaced as a CLI artifact. Describe the solution you'd like Add a --summary-markdown <path> flag to plumber analyze that writes a clean Markdown-formatted compliance report to a file (matching the existing --sarif / --glsast / --pbom / proposed --junit flag naming). The Markdown should include: Project name, analyzed ref / commit, and analysis timestamp. Overall compliance score + threshold + pass/fail headline. A table of all controls with compliance % and issue count (mirrors cmd/render_de

Is your feature request related to a problem? Please describe. A visual representation of the content of the pipeline can help users understand what they have running a lot better. Describe the solution you'd like Have a flag --dependency-graph must be set to a local file path. Example: --dependency-graph dep.png Outputs a png image containing a neat visual representation of the directed acyclic graph (DAG) making up every job and their inclusions in that pipeline. Describe alternatives you've considered None