🧩 Develop Phase — Practical DevSecOps Controls

Intro: The best time to make security cheaper is while code, contracts, templates, and configuration are still easy to change. In mature DevSecOps, the develop phase is not “write code, then ask security later.” It is where teams set the defaults that determine whether the rest of the pipeline stays clean or keeps re-discovering the same problems.

What this page covers

what the develop phase should own in a modern Product Security program;
which older practices still help and which have been replaced by stronger patterns;
practical checks for source code, API contracts, Dockerfiles, Terraform, and Kubernetes YAML;
fast examples for pre-commit, IDE, and merge-request workflows.

Core idea

The strongest message reinforced by the uploaded DevSecOps books is still correct: security works best when it is part of the engineering system, not a detached review queue. The modern version of that idea is:

developers get secure defaults and fast feedback;
high-risk changes get more review depth, not more paperwork;
the first security feedback loop happens in IDE / pre-commit / pull request, not only in pre-production;
threat modeling becomes incremental, because design changes continuously.

Older practice versus current practice

Older pattern you will still see	Why teams used it	2026-friendly version	Practical guidance
Separate security review after development	Security was centralized and delivery was slower	Continuous review in PRs plus targeted deep review for high-risk changes	Keep a short escalation path for auth, crypto, multi-tenant isolation, payments, secrets, and admin-plane changes
Big upfront design package	Waterfall-style governance	Lightweight design notes plus delta threat modeling	Ask “what changed in trust boundaries, identity, data handling, and blast radius?”
GitFlow everywhere	Release management simplicity	Short-lived branches or trunk-based development for most product work	Use stronger branch protection and release evidence instead of long-lived branch complexity
Manual checklist review only	Easy to start	Checklist + automated linters + reusable policy checks	The checklist should guide judgment; the bots should catch repetition
Security team runs all scanners	Traditional shared-service model	Self-service scanners with platform-owned policy and central visibility	Developers should see results where they already work

What belongs in the develop phase

1. Secure coding and review defaults

At minimum, every product team should have:

branch protection;
mandatory review on protected branches;
secret detection before merge;
language-aware linting or SAST in IDE or pre-commit;
explicit handling of security-sensitive code paths.

2. Contract-first security for APIs

If the service exposes an API, treat the API definition as code:

auth scheme must be explicit;
error semantics must be intentional;
schema validation must be strict enough to reject junk;
versioning and deprecation behavior must be reviewable.

3. Security review of non-app code

Develop phase is also where teams change:

Dockerfiles;
Helm values;
Terraform or OpenTofu;
Kubernetes YAML;
reverse-proxy and web server configuration;
build scripts and reusable pipeline components.

Do not wait until deploy time to look at them.

Practical review triggers

Escalate for deeper security review when a change:

introduces a new internet-facing route or endpoint;
changes authentication or authorization logic;
changes session, token, cookie, or secret handling;
introduces a new third-party action, container image, or dependency feed;
changes cloud trust, workload identity, or service-account scope;
changes tenant isolation or admin-plane capabilities;
adds new data classes, export flows, or customer-visible integrations.

Practical snippet — pre-commit checks for common engineering artifacts

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

  - repo: https://github.com/returntocorp/semgrep
    rev: v1.116.0
    hooks:
      - id: semgrep
        args: ["--config", "p/ci"]

  - repo: https://github.com/adrienverge/yamllint.git
    rev: v1.37.1
    hooks:
      - id: yamllint

  - repo: local
    hooks:
      - id: redocly-openapi-lint
        name: redocly-openapi-lint
        entry: npx @redocly/cli lint openapi.yaml
        language: system
        pass_filenames: false

      - id: checkov-iac
        name: checkov-iac
        entry: checkov -d infra
        language: system
        pass_filenames: false

Use this as a fast local gate, not as the only gate.

Practical snippet — GitHub Actions example for “develop-phase” checks

name: devsecops-develop-phase

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  fast-feedback:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '22'

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install tools
        run: |
          pip install checkov
          npm install -g @redocly/cli

      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2

      - name: OpenAPI lint
        run: redocly lint openapi.yaml

      - name: IaC scan
        run: checkov -d infra --quiet

Practical snippet — legacy versus current branch policy

Older but still workable

- feature branch
- pull request
- human review
- CI checks
- merge to protected main

Stronger modern version

- short-lived branch
- CODEOWNERS for sensitive paths
- mandatory status checks
- secret scanning before merge
- signed or at least attributable commits for high-trust repos
- release evidence linked to the merge and build

Design-under-change questions

Use these when “the code is the design” and you still need security signal:

Did we introduce a new trust boundary?
Did we expand who can call this component?
Did we change what data is accepted, emitted, cached, or logged?
Did we increase the authority of the workload, service account, or pipeline?
Did we add a dependency, action, image, template, or third-party service?
If this change is wrong, what is the blast radius?

Common mistakes in the develop phase

treating Dockerfile, Terraform, and OpenAPI as “not really code”;
letting IDE feedback be optional for the most failure-prone languages and frameworks;
overusing heavyweight review gates for low-risk changes while under-reviewing auth and identity changes;
assuming SAST output is a replacement for secure design review;
waiting until staging to discover secrets, missing auth, or invalid contracts.

Where older guidance is still useful

The uploaded books still land well on a few points:

configuration as code is still non-negotiable;
repeatability is still a security feature;
small incremental changes still reduce blast radius;
developer-visible security tooling is still more scalable than centralized scanning factories.

What changed is the tooling and the packaging around those ideas, not the ideas themselves.

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.