Allow customization of scan execution policy stage insertion

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

• Close this issue

Release notes

Introduce additional configuration for scan execution policies that allows for customizing the stage policy jobs will run in, or the position of the injected stage.

Problem to solve

Currently, scan execution policies have fixed behavior for injecting jobs. Jobs are always injected into the "test" stage if it exists; otherwise they are injected into a special stage (created by the execution policy) that is either after the "build" stage (if it exists) or at the beginning of the pipeline.

For customers with long pipelines, running SEP jobs in their existing "test" stage or after "build" can lead to a significant delay before SEP jobs start. In the interest of developer productivity, a customer might want to ensure that SEP jobs run as soon as possible in order to populate things like the merge request widget and allow faster iteration in addressing any scan findings.

Proposal

I don't want to be too specific about implementation, but the most obvious possibility to me is introducing a parameter on scan execution policies that allows the user to specify which stage jobs should be added to. The user could then provide their existing first stage. The limitation of this approach is that some customers may not have a consistent set of stages across their pipelines, so it would be ideal to offer a way to inject a stage as well, controlling where it is injected. Perhaps this could look like a "scan_after" parameter that defaults to "build" and sets which stage scan jobs will be placed after... a blank value could mean that scan jobs are placed at the beginning of the pipeline.

Intended users

• Alex (Security Operations Engineer)
  • Enjoys increased flexibility in designing scan execution policies
• Sasha (Software Developer)
  • Benefits from receiving scan results earlier in the pipeline

Feature Usage Metrics

Customer use of any newly added parameter will be the best metric of success.

Does this feature require an audit event?

Unlikely, there should be existing coverage for modification of policies.