Guidelines and consistency for creating a new policy

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem

As new teams work cross-functionally to enable policies in their area of the DevSecOps lifecycle, we want to introduce guidelines for Product, UX, and Development to help teams understand when it is ideal for creating a policy and how to contribute.

Topics may include:

• How to ensure consistent UX design across policies
• Common/recommended UX patterns
• When policies are a good fit vs when they aren't
• Product considerations to consider before implementing
• Development guidelines and how to get started

Guidelines - Work in progress

What are policies?

• Policies are an overlay category for enforcing rules globally and granularly to ensure security and compliance through controls or automation.

What are policies not?

• Policies are not a means for replacing good Authentication, Authorization, or Organizational management. For example, we don't want to create a policy that can better be solved with a new custom role or permission.
• Policies are not intended to replace settings on any level - e.g. instance, group, subgroup, project. Policies are a means of ensuring and enforcing security and compliance. They allow for granular scoping/enforcement and with policies-as-code, ensure that changes to those settings are controlled.

How to contribute

Why contribute to policies

Choosing between Action/Rule flow vs Rule/Action flow.

The test we had before was to test what users' intentions were when they came to the policy. And it decides what comes first. Ex

• For scan execution policy, when user create a policy their thought is: "I want to run a scan"
  • So it leads to Action first
• For MR approval policy, when users create a policy their thoughts are: "I want to set up a rule for MR"
  • So it leads Rule first
  • Additionally, the MR approval policy rule is complex, so it also makes sense for users to figure out the condition so they can decide who to approve to avoid back-and-forth editing.