Independently of the slsa source threat model and security checks implementation, I think the user experience can be greatly improved by adding a slsa source pull request check. This would prevent accepting PRs when the slsa controls have been disabled and the slsa level defined in the policy is no longer met.
There are no security implications when merging a reviewed PR into the branch but if a PR is merged when the controls are disabled, the control continuity will be interrupted. To fix it, the user needs to reset the policy and reset the dates, meaning that assurance on controls being in place for previous pushes can never be expressed again (even when they were).
This can be prevented by checking the controls of the repo match the policy and preventing the pull request approval until the repo is back in shape.
Independently of the slsa source threat model and security checks implementation, I think the user experience can be greatly improved by adding a slsa source pull request check. This would prevent accepting PRs when the slsa controls have been disabled and the slsa level defined in the policy is no longer met.
There are no security implications when merging a reviewed PR into the branch but if a PR is merged when the controls are disabled, the control continuity will be interrupted. To fix it, the user needs to reset the policy and reset the dates, meaning that assurance on controls being in place for previous pushes can never be expressed again (even when they were).
This can be prevented by checking the controls of the repo match the policy and preventing the pull request approval until the repo is back in shape.