Spike: Proof of Concept for Flexible Scan Execution Policy Trigger Conditions

Current recommendations require enforcement of jobs to run on all branches by using * or all branches in the policy configuration. This ensures that any branch that may end up being merged into main have necessary scans running (that MR approval policies depend on). The artifact must then be produced for both branches and consumed to perform evaluation of the two branches. We need to explore more refined rules for enforcing scan execution to provide users with greater flexibility and control.

Objective

Create a proof of concept (PoC) for implementing more flexible Scan Execution Policy trigger conditions, focusing on the ability to target specific branch types (e.g., default, protected) and pipeline sources.

Tasks

1. Add support for pipeline_source to differentiate between merge request pipelines and branch pipelines.
2. Implement a basic version of the new branch_type option in the SEP configuration, including:
   • target_default: for branches targeting the default branch
   • target_protected: for branches targeting protected branches
3. Implement the PoC behind a feature flag for controlled testing and feedback.

Technical Considerations

• Ensure compatibility with existing pipeline configurations and merge request pipelines.
• Consider how the new options interact with different security scan template selections (latest vs. default).
• Evaluate potential conflicts between new conditions and underlying security scan template behaviors.

Success Criteria

• The PoC successfully demonstrates the ability to trigger scans based on the new branch_type and pipeline_source conditions.
• The implementation does not break existing SEP functionality.
• The approach is scalable and can be extended for future enhancements.