Accepted Risk (Won't Fix) For Issue Remediation

[codejasleen]

Currently, every rule violation eventually results in a remediation issue until the rule becomes compliant.

However, there are cases where a repository owner intentionally decides that a particular violation is an accepted risk and does not plan to remediate it. In those cases, repeatedly creating new remediation issues for the same violation isn't useful.

One possible approach would be to introduce an explicit Accepted Risk workflow for Minder-created remediation issues.

The current idea is to reuse GitHub's existing wontfix label. If a repository owner applies the wontfix label to a remediation issue created by Minder, Minder would treat that as an explicit Accepted Risk decision. It would record that state for the corresponding repository/rule, close the issue, and avoid creating new remediation issues for subsequent evaluations until that Accepted Risk state is removed.

This keeps the workflow explicit, avoids trying to infer intent from comments or issue state, and fits naturally into the existing GitHub issue workflow.

Open question: Is reusing GitHub's existing wontfix label the right trigger for Accepted Risk, or would a different workflow fit Minder better?
@evankanderson

[evankanderson]

Remediation PRs have the same challenge; an explicit accepted-risk state feels like a reasonable solution.

A few questions to clarify thinking (I don't know answers yet, but I'm hoping we can figure out a sketch for the answer alongside our solution to this):

1. How can organization owners track and review the accepted risks?
2. Can "accepted-risk" be undone? If so, how (what API) and by whom (what permission on what resource)?
3. Does "accepted-risk" change the rule evaluation status, or only remediation actions?

One idea I've played with in other contexts is to have policy exceptions be time-bounded; that is, you can't say "I accept the risk that this port is open" but instead you say "I accept the risk that this port is open for 2 quarters (while the team builds a cleaner solution / vendor migrates to other API / etc)". After 2 quarters, if it's not done, you have to go ask for another time-bounded exception.

[codejasleen]

Remediation PRs have the same challenge; an explicit accepted-risk state feels like a reasonable solution.

A few questions to clarify thinking (I don't know answers yet, but I'm hoping we can figure out a sketch for the answer alongside our solution to this):

1. How can organization owners track and review the accepted risks?
2. Can "accepted-risk" be undone? If so, how (what API) and by whom (what permission on what resource)?
3. Does "accepted-risk" change the rule evaluation status, or only remediation actions?

One idea I've played with in other contexts is to have policy exceptions be time-bounded; that is, you can't say "I accept the risk that this port is open" but instead you say "I accept the risk that this port is open for 2 quarters (while the team builds a cleaner solution / vendor migrates to other API / etc)". After 2 quarters, if it's not done, you have to go ask for another time-bounded exception.

Accepted Risks should be visible as a collection rather than only being tied to individual issues, so organization owners can periodically review active exceptions.

My thought is that once Accepted Risk is stored by Minder, it should also be managed by Minder. The initial creation could come from the GitHub wontfix label on a Minder-created issue, but removing an Accepted Risk should happen through a dedicated Minder API. That keeps GitHub as a trigger rather than the source of truth.
The permission should be checked against the same resource that owns the Accepted Risk (my current thought is the repository), using the same authority that is allowed to manage policy for that repository.

Evaluation vs. remediation: I don't think Accepted Risk should change the rule evaluation itself. The rule should continue to evaluate as FAIL; Accepted Risk should only affect remediation actions. That conveys "this repository violates the policy" and "we've intentionally accepted that violation."

Time-bound exception seems to be a great idea. An expires_at field seems like a natural way to model that.

[evankanderson]

I'm wondering whether we should have some sort of "accepted risks" collection at the project level which allows for both automatic (e.g. from issue close with comment) as well as manual (minder command) creation of exceptions / accepted risks.

Pro

• adds additional options (e.g. blanket exceptions for certain rules) via manual operation
• fits our existing permissions model without needing a lot of extra modelling

Con

• Needs more-careful API design to cover broader cases (e.g. how does an exception match a rule evaluation -- what are the degrees of freedom?)
• Possibly extra complexity for end-users.

[codejasleen]

I really like the project-level collection approach, but to keep the initial implementation manageable, i think to intentionally limit the first version to repository + rule exceptions? That gives us a solid abstraction while avoiding broader matching semantics until we have concrete use cases for them.
For the lifecycle i think of (create, active, remove/expire).

I'm wondering whether we should have some sort of "accepted risks" collection at the project level which allows for both automatic (e.g. from issue close with comment) as well as manual (minder command) creation of exceptions / accepted risks.

Pro

• adds additional options (e.g. blanket exceptions for certain rules) via manual operation
• fits our existing permissions model without needing a lot of extra modelling

Con

• Needs more-careful API design to cover broader cases (e.g. how does an exception match a rule evaluation -- what are the degrees of freedom?)
• Possibly extra complexity for end-users.

[codejasleen]

@evankanderson Just wanted to follow up on this. Should we move forward with this approach?

I really like the project-level collection approach, but to keep the initial implementation manageable, i think to intentionally limit the first version to repository + rule exceptions? That gives us a solid abstraction while avoiding broader matching semantics until we have concrete use cases for them. For the lifecycle i think of (create, active, remove/expire).

I'm wondering whether we should have some sort of "accepted risks" collection at the project level which allows for both automatic (e.g. from issue close with comment) as well as manual (minder command) creation of exceptions / accepted risks.

Pro

• adds additional options (e.g. blanket exceptions for certain rules) via manual operation
• fits our existing permissions model without needing a lot of extra modelling

Con

• Needs more-careful API design to cover broader cases (e.g. how does an exception match a rule evaluation -- what are the degrees of freedom?)
• Possibly extra complexity for end-users.

[evankanderson]

I think it's fine to currently define the matching more narrowly, as long as there is room to expand the definition later. That's an API definition thing -- I'm guessing that we'd want a list of ruletypes and some sort of selector on the entities, but we could start with an exact-match string for the entities, and max length 1 on the ruletype list.

For lifecycle, I think Create, List, Delete (and automatic deletion after expiry) could be a good start. Eventually, I can imagine "extend" as an update operation, but I'd probably suggest that updating the covered entities or ruletypes would be creating a new exception and then deleting the current one.

[codejasleen]

I think it's fine to currently define the matching more narrowly, as long as there is room to expand the definition later. That's an API definition thing -- I'm guessing that we'd want a list of ruletypes and some sort of selector on the entities, but we could start with an exact-match string for the entities, and max length 1 on the ruletype list.

For lifecycle, I think Create, List, Delete (and automatic deletion after expiry) could be a good start. Eventually, I can imagine "extend" as an update operation, but I'd probably suggest that updating the covered entities or ruletypes would be creating a new exception and then deleting the current one.

makes sense, I'll start working on this.

[codejasleen]

hey @evankanderson ,for automatic expiry requirement, i looked into the existing periodic processing patterns in minder. There are cron/ticker based implementations but i don't see an existing persistent cleanup mechanism that we can directly reuse for accepted risks.
So should we introduce a small background worker owned by the accepted Risk package that periodically deletes expired records, or is there something else i should know?

[evankanderson]

Look at the mechanism we use to purge old session state: https://github.com/mindersec/minder/blob/main/deployment/helm/templates/session_expiration_purge_job.yaml

I think that's probably a reasonable pattern to follow for now.