DevSecOps Program · Part 1 — Foundation: Identity, Secrets & Repo Hygiene

This is Part 1 of the DevSecOps Program — the foundation the entire program stands on. Before a single scanner runs in your pipeline, four things have to be true: the right people (and only the right people) can reach your systems, your secrets live in a vault rather than your code, every change flows through a reviewed and evidenced path, and you actually know what you run. Get these wrong and every later phase is built on sand — a SAST gate is meaningless if a developer can push straight to production, and a signed artefact is worthless if the signing key is sitting in a .env committed to Git. This part is deliberately unglamorous and deliberately thorough: it is the highest-leverage security work a startup will ever do, and almost none of it requires buying a tool. It requires configuration discipline and a few hours of focused effort.

Scope of this phase

Every part of this program is scope-bounded so you know exactly when you are done and are not tempted to boil the ocean.

• In scope: human and machine identity and access to your core systems (source control, cloud, CI/CD, package registries); a managed secrets baseline and the removal of secrets from code; branch protection and change control expressed as code; and a lightweight, maintained asset inventory.
• Explicitly out of scope (later parts): pipeline security gates like SAST/SCA (Part 2), supply-chain scanning and artefact signing (Part 3), runtime monitoring and incident response (Part 4), and formal governance and metrics (Part 5). You will prepare the ground for these here, but you do not implement them yet.
• Definition of done: the exit checklist at the end of this part. When every box is ticked, you are ready for Part 2 — and not before.

The four foundations are independent enough to parallelise across a small team, but all four must be complete before the program advances. Let's take them one at a time.

Foundation 1 — Identity & Access

Identity is the perimeter. In a cloud-native startup there is no network moat; the thing standing between an attacker and your production data is whether they can authenticate as someone who has access. That makes identity the single highest-value control in the whole program.

Single sign-on and MFA, everywhere

Consolidate authentication behind one identity provider (Google Workspace, Microsoft Entra, Okta — whichever you already pay for) and enforce multi-factor authentication on every system that supports it: source control, cloud console, CI/CD, package registries, and your IdP itself. Phishing-resistant factors (passkeys / WebAuthn / hardware keys) are strongly preferred over SMS or TOTP for anyone with production or admin access.

The non-negotiables:

• MFA enforced by policy, not left to individual opt-in.
• SSO wherever a system supports it, so access is granted and revoked in one place.
• No shared logins. Every human has their own identity; every action is attributable.

Least privilege from day one

It is far harder to claw permissions back than to grant them narrowly at the start. Model access as roles mapped to IdP groups, not permissions granted to individuals:

Joiners, movers, leavers

The most common real-world breach path is not a zero-day; it is an offboarded contractor whose access was never removed. Write down — and then automate as far as you can — what happens when someone joins, changes role, or leaves. Deprovisioning must be immediate and complete, and because you routed access through SSO and groups, disabling one identity revokes everything at once. Run a quarterly access review: for each role, confirm the members still need it. That review is also your first piece of ISO 27001 / SOC 2 access-control evidence — keep the records.

Foundation 2 — Secrets

A secret in a Git history is a secret that has leaked. Treat it that way. This foundation gets credentials out of your code and into a managed store, and stands up the detection and rotation you will rely on for the rest of the program.

Get secrets out of code and into a vault

Every API key, token, database credential and signing key belongs in a managed secrets store — a cloud provider's secrets manager or KMS, or HashiCorp Vault — never in source, never in a committed .env, never in a CI config file in plaintext. Applications read secrets at runtime from the store (or from injected environment variables sourced from it), and access to the store is itself governed by the least-privilege roles from Foundation 1.

Catch secrets before they are committed

The cheapest place to stop a leaked secret is the developer's own machine, before the commit ever exists. Install a pre-commit hook that scans the staged diff:

# runs on every local commit — blocks secrets before they enter history
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks             # scan the staged diff for credentials
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: detect-private-key   # block committed private keys

This is a Foundation control, not a pipeline gate (that comes in Part 2) — its job is to stop the leak at the source. A server-side scan of full history is a belt-and-braces addition; run one over your existing repositories now to find anything already committed.

When a secret leaks: the rotation runbook

Assume it will happen. Having a written, rehearsed response turns a potential incident into a routine chore. The runbook is short and always the same:

1. 1Rotate first, investigate second. Generate a new credential and revoke the exposed one immediately — before working out how it leaked. The exposed value must be treated as compromised the moment it touches a shared history.
2. 2Purge the source. Remove the secret from the code and, where feasible, from Git history. But never rely on history rewriting as your safety net — rotation is what actually protects you.
3. 3Check for use. Review logs for any access with the exposed credential between exposure and revocation.
4. 4Record it. A short note — what leaked, when, how it was rotated — is both an improvement input and audit evidence.

Any credential that has ever touched a Git history is rotated as part of adopting this phase. No exceptions.

Foundation 3 — Change control as code

This foundation is the quiet backbone of your entire future compliance story. Frameworks (ISO 27001 A.8.32, SOC 2 CC8.1) demand authorised, tested, reviewed changes with segregation between the author and the approver. A correctly configured Git workflow is that control — and expressing it as code makes it consistent, reviewable and self-evidencing.

Branch protection, expressed as code

Do not click branch-protection settings by hand across repositories; they drift, and there is no record of what the rule was or who changed it. Define them as code so the change-control policy is itself version-controlled and reviewed:

# Terraform (GitHub provider) — protect the default branch as code
resource "github_branch_protection" "main" {
  repository_id = github_repository.app.node_id
  pattern       = "main"

  required_pull_request_reviews {
    required_approving_review_count = 1
    require_code_owner_reviews      = true      # CODEOWNERS must approve
    dismiss_stale_reviews           = true
  }

  required_status_checks {
    strict   = true                             # branch must be up to date
    contexts = ["ci"]                           # Part 2 adds security checks here
  }

  enforce_admins         = true                 # rules apply to admins too
  require_signed_commits  = true
  allows_force_pushes    = false
  allows_deletions       = false
}

Read the block as controls: required_approving_review_count + require_code_owner_reviews is authorisation and segregation of duties (the author cannot approve their own change); required_status_checks is testing (and the hook where Part 2's security gates attach); require_signed_commits and the immutable history are your tamper-evident audit trail. Add a CODEOWNERS file so the right people are required reviewers for the code they own.

The payoff

Once this is in place, your change-management "process document" for an auditor is simply: here is the Terraform that enforces it, and here is the pull-request history proving it operated on every change. No Confluence page nobody updates — the control and its evidence are the same artefact. That principle carries through the rest of the program.

Foundation 4 — Asset inventory

You cannot secure what you do not know you run. The final foundation is the least glamorous and the most frequently skipped: a maintained inventory of your services, repositories, cloud accounts, data stores and the third-party services that hold your data. It does not need to be a fancy CMDB — a version-controlled file or a simple table is enough to start, provided it is kept current.

The inventory is the map every later phase reads: Part 2 needs to know which repositories to gate, Part 3 which workloads to scan, Part 4 what "normal" looks like, and Part 5 what is in scope for which framework. Capture, per asset: what it is, who owns it, what data classification it holds, and where it runs. Assign an owner to the inventory itself, and review it on the same quarterly cadence as your access review.

Definition of done — Foundation exit checklist

You are ready for Part 2 when every one of these is true:

• Identity: SSO consolidated behind one IdP; MFA enforced by policy on every system that supports it; phishing-resistant factors for admin/production access.
• Access: roles mapped to groups, least-privilege defaults, a documented and tested break-glass path, and a completed first quarterly access review (with records kept).
• Joiners/movers/leavers: a written process, with deprovisioning proven to be immediate and complete.
• Secrets: all secrets in a managed store; no secrets in code or committed .env files; pre-commit secret scanning installed; every previously-committed secret rotated; a written rotation runbook.
• Change control: branch protection defined as code on every active repository — required review, code-owner approval, signed commits, no force-push, admins included; CODEOWNERS in place.
• Inventory: a current, owned asset inventory covering services, repos, cloud accounts, data stores and third parties, with owners and data classifications.

Tick every box and the foundation is solid. Skip one and a later phase will quietly assume it is closed — which is exactly how gaps become incidents.

What's next

Part 2 — Shift Left builds directly on this foundation: with identity, secrets and a reviewed change path in place, we wire security testing into the pipeline itself — pre-commit hooks graduating into CI, SAST, SCA and secret scanning as merge gates, tuned so developers trust them rather than route around them. The required_status_checks hook you configured in Foundation 3 is where those gates attach. It ships next month.

Standing up this foundation is also the point where a platform starts to earn its keep: ISMShed captures the access reviews, the change-control evidence and the secrets-management posture as continuous, framework-mapped audit evidence across ISO 27001, ENS, NIS2, DORA, SOC 2 and GDPR — so the records this phase produces become your compliance story rather than a spreadsheet you rebuild before every audit. If you would like experienced hands to stand the foundation up against your own stack, Axelia's DevSecOps and GRC consultants run the program alongside you. Get Foundation right, and the rest of the program compounds from there.