Introduction
Following on from my original blog ‘When “Shift‑Left” Leaves the Back Door Open: Why Governance Matters More Than Ever’ this is part 1 of a 3 part follow up series where I’ll discuss examples of tools and strategies I’ve used to implement some of the security considerations I outlined in the aforementioned post.
In this post I’ll be discussing the below aspects;
- Tooling
- Scanning Secrets
- Branch Policies
- Security Policies
App Security Platform tooling
There are many tools of choice for enforcing DevSecOps governance in Azure Dev-Ops (ADO). In this example I’m going to discuss GitHub Advanced Security (GHAS) as it covers the majority of the security requirements including Secret Scanning, SAST, and SCA and is straightforward to implement.
As is the case with all these tools it does come at a cost (GitHub Advanced Security Pricing) and although it’s not the cheapest of the major players its one of the cheapest and the fact its natively built into ADO is a big tick. By the click of a button you can enable it (make sure you have at least Project Admin permissions) — at which point it can start protecting your environment by scanning for old secrets and blocking new secrets and SAST and SCA scanning provide informational feedback on any discrepancies found in default or protected branches (I discuss SAST and SCA in more detail in part 2 blog).
To enable GitHub Advanced Security: Project > Repositories > Select Repo > Settings. Toggle the features you want turned on or off.
Secret Scanning
Once enabled, GHAS gets to work on scanning your code base for exposed secrets. During initial enablement it performs a scan for any historical secrets and surfaces any findings in the Advanced Secrets view for the repositories.
From here you can review the detected secrets and decide whether to accept the risk or remediate them using various git commands — but this does require a history rewrite so take this into consideration when planning your branch policies (covered later in this post)
Repos > Advanced Security > Change your Repo to view any secrets captured
Going forward GHAS can also block new secrets from being pushed preventing them from entering the repository. Developers are either required to justify the secret or remove it before attempting to commit again.
Branch Policies and Security Policies
Why is it important to protect your default and permanent branches? Without proper branch protection you open the door to introducing poor quality code into your precious branches.
Branch policies can enforce controls such as:
- Minimum number of PR reviewers
- Required PR reviewers
- Merge type controls
- Pre Merge Build validations
- Force work items to be linked to commits
They are straightforward to implement: Repos > branches, click on the ellipsis and select branch policies
You can also find the Security policies in the same place on the Security tab. There are a number of options in here designed to protect your branches.
These permissions can be set to groups and or individual users at the project or repo level but you can override this inheritance by setting the inheritance radio button to off.
The right settings will depend on your delivery model, risk appetite, regulatory context and team structure. Here’s how I personally have used some of the options:
- Bypass policies when completing pull requests: this allows the group/user to complete a PR even if the PR merge checks violate branch policies.
- Bypass policies when pushing: Enables the group/user to commit directly to the branch despite the branch having branch policies set.
- Contribute: If enabled the group/user can push changes to the branch — if disabled, they cant push anything to it. Ive only ever disabled this for non developer groups/users
- Edit policies: Allows the group/user to edit branch policies. I enable for Project Admins only.
- Force push (rewrite history, delete branches). The group/user can rewrite commit history. They can also delete branches altogether. I usually set this to DENY for all members, however temporarily enable if required e.g. if the secret scanner reveals historical secrets committed that need removing.
- Manage permissions: The group/user can control branch permissions such as who can push or bypass policies, who can force push. I enable for Project Admins only.
Its also worth pointing out you can set each of the above options to 1 of 3 states;
- Allow: the group/user can do the thing
- Deny: The group/user cant do the thing
- Not Set: Neither allowed or denied doing the thing — but they will inherit what is set further up the hierarchy i.e. repo or project level
Pre-deployment Approvals
How do we prevent bad code being deployed to our environments accidentally or otherwise? This is where Pre-deployment Approvals come in.
They allow us to appoint required users to ‘sign-off’ the deployment of code to any given environment. Unless the approver approves the deployment, the code cannot be deployed. I usually reserve this type of intervention for UAT deployment stages and upwards.
They are pretty easy to implement in Release pipelines; Click on the little person icon on the stage (environment) you want to implement the pre-deployment approvals for, select your approver(s) from the drop down list, and set an expiration date by which they must be approved. Then on the next attempt to perform a deployment the approver will receive a notification that the need to review/approve a deployment.
Project > Pipelines > Release > Select your release stage and click Edit.
Now you select your approvers and save
For yaml deployment pipelines there is more configuration required. You’ll need to select create an Environment for the stage you want to add the pre-deployment approvals to and then add your approvers within the environment. You’ll then need to bind this environment to the deployment stage in your pipeline as part of your yaml definition.
Creating a new Environment: Project > Pipelines > Environments> Create New Environment > Give it a name and leave other defaults.
Now Click on your new Environment, Approvals and Checks > Approvals then add approvers from the list and click create
Now update your yaml pipeline and associate with the Environment/Approval Checks. When this pipeline is triggered the deployment will be blocked until the approver approves it.
Some dummy yaml code to illustrate binding your Environment to your yaml deployment
- stage: DeployProd
displayName: "Deploy to Prod"
dependsOn: Another_Stage
condition: eq(variables['Build.SourceBranch'], 'refs/heads/prod')
jobs:
- deployment: DeployProd
environment: TestEnv //this should match the name of your new Environment to associate it
strategy:
runOnce:
deploy:
steps:
- task: DummyDeploymentTask@0
displayName: Push to Prod
Summary
In summary I’ve discussed DevSecOps governance tooling in the shape of GitHub Advanced Security and how out of the box it scans for historical secrets provisioning a GUI to enable developers to remediate any findings. Going forward secrets will also be blocked on push (if enabled). SAST and SCA scanning also provides informational results on code quality and Open Source Software violations. Branch and Security policies can also be implemented to prevent poor code from being merged into permanent branches, rewriting commit history or deleting branches altogether. Pre-deployment Approvals can also be employed to block code from being deployed to your environments without oversight. I hope you find this helpful on your journey towards a shift-left mind set and in my next post I’ll talk about techniques to actively block builds through SAST and SCA scan findings.
Originally published at https://techmusings.co.uk on March 27, 2026.
If you want to learn more about the Microsoft Team here at Capgemini, take a look at our open roles and consider joining the team!
DevSecOps Governance (Part 1): Tooling, Secret Scanning, and Branch Protection Strategies was originally published in Capgemini Microsoft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.