Currently CpsScmFlowDefinition enforces sandbox mode on the grounds that whole-script approval is unrealistic (an administrator would need to approve every SCM revision, and Jenkins cannot automatically approve revisions like it could from GUI changes to a CpsFlowDefinition by an administrator).

There should however be an option to simply trust the script as it comes from the SCM. This could be checked by default if Jenkins were unsecured; for a secured Jenkins, the default should remain to use the sandbox, though you could switch to trusted mode with a stern warning in form validation explaining that you are responsible for auditing all changes to that SCM repository, and noting that attackers with SCM access could take over control of Jenkins in ways that might make auditing difficult. (For example, someone with push access to a Git repository could push a script which obtains the API token of a legitimate Jenkins administrator, mails it to the attacker, then deletes the current build record; and finally force-push the attacking script out of existence except via the reflog.)

Pending such an option, the workaround is given by the tutorial here: define a CpsFlowDefinition with an approved script that checks out the SCM and uses load to run it. This has the same effect at the price of more awkward configuration.