Update roadmap for 2026 (and possibly beyond)

[evankanderson]

Summary

Per suggestions in Slack, updating the Minder roadmap to call out key areas for design and implementation will help new contributors understand where to focus their efforts. I've been keeping a lot of this in my head / in meeting notes or Slack messages that may have aged out, so it's helpful to get the content into a more visible format.

Testing

N/A - this is documentation.

[coveralls]

Coverage is 60.624% — evankanderson:roadmap-early-2026 into mindersec:main. No base build found for mindersec:main.

[Gitjay11]

It's good update. The 2026 roadmap looks great, it's really helpful to see the long-term vision laid out clearly, especially around Rule Output Handling, Rule Testing Infrastructure, and the Identity improvements.

After looking at it, I just had one question:
I noticed the old Future considerations section was completely removed. Was dropping items like GitOps Policy Management, JIT Provider Permissions, and SLSA Provenance Automation okay? Even if they aren't immediate priorities, it might be worth keeping a small section at the bottom for them, so we can know that it is missing.

looks good to me.

[evankanderson]

It's good update. The 2026 roadmap looks great, it's really helpful to see the long-term vision laid out clearly, especially around Rule Output Handling, Rule Testing Infrastructure, and the Identity improvements.

After looking at it, I just had one question: I noticed the old Future considerations section was completely removed. Was dropping items like GitOps Policy Management, JIT Provider Permissions, and SLSA Provenance Automation okay? Even if they aren't immediate priorities, it might be worth keeping a small section at the bottom for them, so we can know that it is missing.

This was intentional, though not all were actually removed:

• Automate the generation and signing of SLSA provenance statements: removed intentionally. Provenance statements should be issued by the build machinery where possible, rather than taped on after the build (if you couldn't observe the build, how do you know it was good?). It should be possible to write Minder rules to add e.g. GitHub Actions provenance tooling to builds, but I don't currently see a good reason to add core features around SLSA provenance.

• Register GitLab and Bitbucket repositories: covered by the section on "Expand Provider Coverage", though Forgejo seems to have pulled ahead of Bitbucket in terms of popularity, I think.

• Export a Minder 'badge/certification'...: covered by the section on "Status Sharing and Export (Badges)". Core Minder should simply expose an API that anyone can use to extract data for badging, though we might consider adding an official badge at some point (though you'd still need to verify that the rules being badged made sense / aligned with the target designation).

• Temporary permissions to providers vs long-running: this should be an option with external remediation, see the section on "Improve Rule Output Handling".

• Create PRs for dependency updates: this seems to be competing with Dependabot / Renovate / Mend, and I'd rather simply support existing tools than compete.

• Drive policy through git (config management): This is complete! See https://docs.mindersec.dev/user_management/github_actions, and https://github.com/mindersec/minder-action (I need to update the docs for the OpenSSF donation). You can grant GitHub Actions (and possibly other identity robots in the future) permissions on a project, and then use standard automation to apply policy. If we make Minder an identity provider for rules ("Rule Identity Improvements"), you could even ouroboros and have a Minder rule manage your Minder project.

• Integrations with additional OSS and commercial tools: This should be done through ruletypes, and shouldn't require any changes to the core (which is what this roadmap focuses on).

• Help package authors improve OpenSSF Scorecard scores: This seems like a particular version of "OSS tools" integration...

[Gitjay11]

Thankyou so much for the thorough breakdown. Everything makes sense, especially the point about SLSA provenance belonging at the build system level, and great to hear GitOps policy management is already done via minder-action. The ouroboros idea of a Minder rule managing its own project is great.
No concerns from my side. everything is good.

[Vyom-Yadav]

Some thoughts, but a solid roadmap (also sorry for the delay)

[Vyom-Yadav]

leverage rule evaluation to collect

I don't think inventory creation should depend on some edge trigger. I think it shouldn't leverage rule evaluation and the inventory should be created when that particular inventory-creation-request is triggered. Relying on some other trigger seems to me like it could miss continuous compliance that inventory likely aims towards.

[evankanderson]

Rule evaluation is simply a policy mechanism -- it can be edge-triggered or timer-triggered (e.g. via reminder). I think the particular goal of the user request here was to have an inventory of either Dockerfiles for images (if you have a repo which builds a lot of images) or of e.g. Claude skills, which could then be used to generate catalogs, etc.

[Vyom-Yadav]

That is good idea. I'm thinking how would the API for such a thing look like? Currently rule creation is fairly simple as you know the entities. BUT if rules create custom entities, then it would be difficult to track the entities themselves.

When I start thinking about this, my head goes towards CRDs in some sense (we can define some, let users define others). A source SBOM for a project (for example) as an entity should not be hidden in any rule. Its needed to be defined explicitly.

[evankanderson]

This is a roadmap thing, so I don't want to completely define the format, but using the output support, we might do something like:

  remediate:
    type: entity
    # Expects an array of new entries which replace any existing ones created by this rule
    entity:
      # Loads the current build definitions from `output[builds]`, where the fields are the
      # defining properties
      # example value: [
      #   {"name": "dev", "server": "dev-ci"},
      #   {"name": "uat", "server": "prod"},
      #   {"name": "prod", "server": "prod"}
      # ]
      - key: builds  # JSONPath expression
        types:
        - build
        # Currently always uses the same provider; might be adjustable later
      - key: images
        types:
        - artifacts

[Vyom-Yadav]

Is the goal here to separate read/write? Github app has just read and for remediation token from outside is supplied for write? How would that work? Which system will feed minder the tokens it requires for remediation? (I'm assuming it's not a human dispatching tokens)

[evankanderson]

Given that a number of supply chain attacks have specifically targeted security providers, it would be great to be able to have the main Minder app not have any exciting "write" permissions in the repo. Instead, you could have a separate "remediation" app which had the exciting permissions. This could either live co-located with Minder (ease of use, no additional protection), or you could use your own GitHub app running outside the Minder environment.

For the latter, you could use something like a periodic workflow that wakes up and queries the Minder API for new necessary remediations. For each remediation, read it from the ruletype definition and fill in the output content, and then apply the result. You could either run this as a cronjob, or actually have an interactive UI for reviewing the recommended remediations before applying them. You could even mix the two -- automate e.g. PR creation and comments, but require human review of anything that would change API settings like branch protection or permitted actions policy.

[Vyom-Yadav]

Both valid points, I think minder should also output a formally verifiable audit trail alongside.

[evankanderson]

You mean using something like a transparency log? I've considered that, but it seems like a pretty big investment, so I'd want to see an actual user request it. Right now, you can use the provider's audit system to track Minder actions (e.g. every Minder GitHub remediation shows up in the GitHub org audit log).

Formal verification is also a big ask, as you'd need some way to tie each usage of a write credential to a specific remediation in such a way that the system couldn't re-use those credentials to issue additional API writes.

[Vyom-Yadav]

This reminds me of https://github.com/kudobuilder/kuttl in some sense. I would suggest anyone working on this to take a look at how kuttl works. Last time I worked with Kyverno, I used kuttl extensively to test policies over there: kyverno/policies#546. Now they seem to use chainsaw though, worth taking a look again: https://kyverno.github.io/chainsaw/0.2.3/guides/kuttl-migration/

[evankanderson]

Yeah, I'm definitely interested in taking inspiration from elsewhere if there are good tools. The current rule_test stuff is very much "a fire engine we built on the way to the fire" to quote one of my mentors.

[Vyom-Yadav]

a fire engine we built on the way to the fire

Saved.

[Vyom-Yadav]

Isn't Trusty eol now?

[evankanderson]

Yeah, we need to actually retire it. In general, I'd like to retire all of these in favor of general-purpose rule evaluation that could call out to the appropriate sources and suggest things without needing Minder core to change at all.

[Vyom-Yadav]

Generic JSONPath based evaluation engines which can fetch from anywhere. But they can be abstracted into something like a CRD(ish) as well.

[evankanderson]

I meant more along the lines of using the Rego (or JQ) evaluator. Rego seemed most promising, since it could leverage OSV or other vulnerabilities databases using the DataSource support.

[Vyom-Yadav]

May I introduce you to the gorgeous: https://launchpad.net/

[evankanderson]

Sorry, I meant that someone would need to pay someone to work on it. Though maybe it would be Canonical paying you to work on better on-prem GitLab support. 😁

[Vyom-Yadav]

Yes, I will let you convince them.

[Vyom-Yadav]

I think expanding to support more container registries should be a separate item. Those I think carry higher value than some other forges at the moment.

[evankanderson]

Good point. We can add that as an additional item under "improved provider support"

[evankanderson]

I added an item for "Expand OCI Registry Provider Coverage" as well as "Other Provider Coverage" to start the thoughts on managing NPM, PyPI, etc publishing.

[Vyom-Yadav]

Authenticating to external data sources for example some hyproprietary data source containing known exploits, malware, etc. (for some scanning?)

I'm not sure what is the goal here. But one layer of auth using provider, then another layer for some third party using oidc, etc. seems confusing.

Data sources in general should not have things to authenticate to another data source is what I mean.

A data source should not have auth details for B data source.

B should be a separate data source which can be queried using an API by A.

[evankanderson]

The idea here is that a rule X may want to call a data source A. The data source A might be licensed or otherwise access-controlled. (Maybe it's simply using LLM inference, and you want to control costs...)

So, you need some way to ensure that it's only rule X from project P that's calling the API. OIDC (ala GitHub Actions) feels like a good way to express this.

We already have a special carve out for "use the current provider's identity" because it was really helpful for GitHub, but I'd prefer not to build a general-purpose secrets store into Minder, because that feels icky. Also, something like OIDC could be used with OpenBao / Vault / OctoSTS / various cloud providers to access their existing secrets stores (which have auditing, etc), so that feels like it would be an escape hatch if you needed to use something like a shared secret (API key, etc) for auth to data source A.

[Vyom-Yadav]

I really like this one. This also extends to a continuous compliance dashboard. SLAs and stuff may be the next thing.

[evankanderson]

Yes, that's the idea. We need some way to permission something (not sure what it is) to be able to say "this one thing is public" without making the whole project public. Part of the work here is designing what something is.

[evankanderson]

Thanks for the review! Do you want me to fill out the OCI repository providers section in more detail now, or in a follow-up PR?

[evankanderson]

This is a roadmap thing, so I don't want to completely define the format, but using the output support, we might do something like:

  remediate:
    type: entity
    # Expects an array of new entries which replace any existing ones created by this rule
    entity:
      # Loads the current build definitions from `output[builds]`, where the fields are the
      # defining properties
      # example value: [
      #   {"name": "dev", "server": "dev-ci"},
      #   {"name": "uat", "server": "prod"},
      #   {"name": "prod", "server": "prod"}
      # ]
      - key: builds  # JSONPath expression
        types:
        - build
        # Currently always uses the same provider; might be adjustable later
      - key: images
        types:
        - artifacts

[evankanderson]

Given that a number of supply chain attacks have specifically targeted security providers, it would be great to be able to have the main Minder app not have any exciting "write" permissions in the repo. Instead, you could have a separate "remediation" app which had the exciting permissions. This could either live co-located with Minder (ease of use, no additional protection), or you could use your own GitHub app running outside the Minder environment.

For the latter, you could use something like a periodic workflow that wakes up and queries the Minder API for new necessary remediations. For each remediation, read it from the ruletype definition and fill in the output content, and then apply the result. You could either run this as a cronjob, or actually have an interactive UI for reviewing the recommended remediations before applying them. You could even mix the two -- automate e.g. PR creation and comments, but require human review of anything that would change API settings like branch protection or permitted actions policy.

[evankanderson]

Yeah, I'm definitely interested in taking inspiration from elsewhere if there are good tools. The current rule_test stuff is very much "a fire engine we built on the way to the fire" to quote one of my mentors.

[evankanderson]

Yeah, we need to actually retire it. In general, I'd like to retire all of these in favor of general-purpose rule evaluation that could call out to the appropriate sources and suggest things without needing Minder core to change at all.

[evankanderson]

Sorry, I meant that someone would need to pay someone to work on it. Though maybe it would be Canonical paying you to work on better on-prem GitLab support. 😁

[evankanderson]

Good point. We can add that as an additional item under "improved provider support"

[evankanderson]

The idea here is that a rule X may want to call a data source A. The data source A might be licensed or otherwise access-controlled. (Maybe it's simply using LLM inference, and you want to control costs...)

So, you need some way to ensure that it's only rule X from project P that's calling the API. OIDC (ala GitHub Actions) feels like a good way to express this.

We already have a special carve out for "use the current provider's identity" because it was really helpful for GitHub, but I'd prefer not to build a general-purpose secrets store into Minder, because that feels icky. Also, something like OIDC could be used with OpenBao / Vault / OctoSTS / various cloud providers to access their existing secrets stores (which have auditing, etc), so that feels like it would be an escape hatch if you needed to use something like a shared secret (API key, etc) for auth to data source A.

[evankanderson]

Yes, that's the idea. We need some way to permission something (not sure what it is) to be able to say "this one thing is public" without making the whole project public. Part of the work here is designing what something is.

[Vyom-Yadav]

@evankanderson

Thanks for the review! Do you want me to fill out the OCI repository providers section in more detail now, or in a follow-up PR?

I think followup is fine, this can be merged. Thanks for writing this down, great ideas for future LFXes or future volunteers.

[evankanderson]

Updated with your feedback, @Vyom-Yadav ; I'll need you to approve this before it can merge.

[evankanderson]

Rule evaluation is simply a policy mechanism -- it can be edge-triggered or timer-triggered (e.g. via reminder). I think the particular goal of the user request here was to have an inventory of either Dockerfiles for images (if you have a repo which builds a lot of images) or of e.g. Claude skills, which could then be used to generate catalogs, etc.

[evankanderson]

You mean using something like a transparency log? I've considered that, but it seems like a pretty big investment, so I'd want to see an actual user request it. Right now, you can use the provider's audit system to track Minder actions (e.g. every Minder GitHub remediation shows up in the GitHub org audit log).

Formal verification is also a big ask, as you'd need some way to tie each usage of a write credential to a specific remediation in such a way that the system couldn't re-use those credentials to issue additional API writes.

[evankanderson]

I added an item for "Expand OCI Registry Provider Coverage" as well as "Other Provider Coverage" to start the thoughts on managing NPM, PyPI, etc publishing.

[evankanderson]

I meant more along the lines of using the Rego (or JQ) evaluator. Rego seemed most promising, since it could leverage OSV or other vulnerabilities databases using the DataSource support.

[github-actions]

This PR needs additional information before we can continue. It is now marked as stale because it has been open for 30 days with no activity. Please provide the necessary details to continue or it will be closed in 30 days.

[evankanderson]

@Vyom-Yadav -- can you approve this?