top of page
Search

Part 4: Detecting High-Risk Code Changes with Code Owners & Pull Request Security

  • Oct 3
  • 3 min read
ree

Every codebase has certain files that you just don’t want anyone to casually edit.


Think about:

  • Authentication and login logic

  • Password handling and crypto libraries

  • Admin panels and backend controls

  • Code that touches private user data

  • Deployment scripts and pipelines


If these pieces of code are changed without proper review, the result could be security vulnerabilities, downtime, or even a data breach. That’s why we need a system to detect high-risk code changes and enforce extra approvals.


This is where Code Owners files, custom alerts, and pull request templates come into play.



What are Code Owners?

A Code Owners file is a simple text file you place in the root of your repository. It tells GitHub, GitLab, or Bitbucket who “owns” which parts of the code.


Think of it like a digital lock:

  • If someone changes a sensitive file, the lock requires approval from the person or group listed as the code owner.

  • Without approval, the change can’t be merged.

Rules that appear later override earlier ones.

For example:

  • All developers can edit code by default.

  • But if someone touches AccountController.cs, the security team must approve it.

  • Even the  Code Owners file itself is protected (because changing it could bypass the whole system).



Why This Matters

Let’s say a junior developer accidentally modifies a password hashing function. Without code owners, the change might slip through with just a casual peer review. With code owners, the security team must approve it before it gets merged.


This gives you:

  1. Control – High-risk code can’t be changed by mistake.

  2. Visibility – Security teams see changes that matter.

  3. Accountability – The right people approve sensitive updates.



Detecting Risky Code Changes with Alerts

One of the security teams took this a step further. Instead of only depending on code owners, they hash sensitive files and write unit tests to ensure nothing changes silently.


Here’s a C# example:

[Theory]
[InlineData("/Web/AccountController.cs",
"2aabf33b66ddb07787f882ceed0718826af897q7")]
[InlineData("/Shared/Services/Cryptography/Hash.cs",
"87f88d137d37a7ed908737552eed0c524133b6")]
public void HighRiskCode_ChecksumTest(string file, string checksum)
{
    bool match = checksum.Equals(Hash.GetChecksum(file));
    if(!match) NotificationService.RequestCodeReview(file);
    Assert.True(match);
}
What this does:

  • Each high-risk file has a checksum (unique fingerprint).

  • If the file changes, the test fails.

  • When it fails, the system notifies the developer, their manager, and the security team.


This runs automatically in Continuous Integration (CI). So if someone modifies crypto code, you’ll know immediately.

Security Checklists with Pull Request Templates

What about developer awareness?


That’s where pull request templates come in.

A template is just a Markdown file that gets pre-filled when someone opens a pull request.


For example:
### Security Checklist
- [ ] Have I reviewed this change for security risks?  
- [ ] Am I touching authentication, crypto, or private data?  
- [ ] Have I notified the security team if needed?
Developers must check these boxes before submitting. It’s not automatic enforcement, but it creates awareness and accountability.

Separation of Duties in Approvals

The final piece of the puzzle is workflow separation:

  • Developer opens a pull request.

  • Code owners are automatically assigned.

  • Security team (or other owners) review the changes.

  • Once approved, the merge triggers build pipelines and deployments.

This ensures no single person can sneak in a risky change. Approvals must come from the right group of people.

------------------------------------------------------------------------------------------------------------

Putting It All Together


This combination gives you:

  • Prevention (owners block unapproved changes)0 -- CODEOWNERS 

  • Detection (unit tests catch file modifications) -- Add checksum-based unit tests 

  • Awareness (checklists guide developers) -- Leverage templates 

  • Governance (audit trail of approvals) -- Require approvals


By combining these, you create a secure GitFlow workflow where high-risk code is guarded, reviewed, and deployed with confidence.


 
 
 

Comments

bottom of page