Secure source code management

Pipeline security begins before automated execution - it begins in the repository. Secure source code management is the first link in the CI/CD chain, and ensures that only legitimate, reviewed and traceable code reaches the build.

A well-protected pipeline is of no use if the repository can be manipulated directly, silently or without validation.

---

🎯 Objectives

• Ensure that all code included in the pipeline is legitimate and authorised;
• Prevent malicious or accidental changes to production branches;
• Ensure traceability, review and integrity of the history of commits and tags.

---

🛠️ Practices

1. Protection of main branches (main, release, prod)

   • Prevent direct push: only allow changes via pull/merge request;
   • Require reviewers (e.g. two-eyes for L1, four-eyes for L3).

2. Mandatory review with an auditable history

   • All changes must go through technical review;
   • Review must be traceable, with logs preserved.

3. Signing of commits or tags in critical applications

   • For L3, digital signing of commits, or at least of release tags, is mandatory;
   • E.g. GPG, Sigstore, SSH verified.

4. Prohibition of history rewriting (force push, retroactive rebase)

   • Repositories must block push --force on protected branches;
   • The change policy must be clearly documented.

5. Granular, role-based permission management

   • Write access restricted by branch or project;
   • Integration with enterprise identity mechanisms (SSO, RBAC, etc.).

6. Controlled branch lifecycle

   • Branches must be kept clean, with standardised naming and a known lifetime;
   • Short-lived branches (feature/bugfix) must not have access to secrets.

---

⚖️ Proportional application by risk level

Level	Mandatory requirements	Enhanced requirements
L1	Branch protection; minimum review	Standard naming; no force push
L2	Mandatory review; history locking	Standardised merge and naming policy
L3	Digital signatures; segregated access	Formal audit of changes and protected tags

---

📌 Practical examples

• GitHub

  • Branch protection rules: prevent force push, require a PR with approval;
  • verified commits with GPG or Sigstore (OIDC).

• GitLab

  • Protected branches: write control per member;
  • Merge request rules with code owner approval.

• Azure Repos

  • Branch policies: mandatory reviewers, build validation;
  • Prohibition of squash or rebase on critical branches.

• Bitbucket

  • Merge checks, branch restrictions, commit signature enforcement.

---

📉 Mitigated risks

• Introduction of malicious code directly into the repository (OSC&R: SC0001);
• Silent substitution of code (OSC&R: CI0004);
• Unauthorised releases by tag or branch outside the process;
• Manipulation of history to conceal malicious activity.

---