In an application security context, there’s a layer of obfuscation when it comes to tracking visibility at the branch level. Security testing in many enterprises still occurs only in the release branch. There are a number of reasons for this, including the cost and complexity of managing security issues in multiple versions or branches.
Feature branches enable developers to work together as well as individually with a copy of the main codebase. Projects are often worked on for hours, days, weeks, or even months for some products. When a developer is working on a specific feature, when is the best time to tell them about a potential security flaw they are introducing? If you answered while the developer is still developing the feature, you are correct.
Security analysis must break out of main branch / release branch style of compliance scanning and be performed earlier in the life cycle so that developers can get security results delivered to them while they are still in the context of developing the feature. They are much more likely to fix issues immediately without needing to remember to do it later. But although this may seem simple to do, there are factors that introduce complications in the triage process.