DevSecOps: shifting security left

Why "shift left"?

Picture the life of a feature as a line from left to right: idea, design, code, build, test, release, run. Shift left means moving security checks towards the left side of that line, so they happen earlier. A design flaw found on a whiteboard costs a ten-minute conversation. The same flaw found in production can cost an emergency fix, a lost weekend, a breach notice to customers and a regulator, and lost trust.

In the old model, a separate security team tested the app a few days before release and handed over a long PDF of problems. Developers had already moved on, deadlines were close, and most findings were either rushed or ignored. DevSecOps (development, security and operations) replaces that with small, automatic checks in every pull request and every pipeline run, plus a few human practices like threat modelling.

Security is everyone's job

• Developers validate input, use parameterised database queries and never hard-code secrets.
• Reviewers look for missing access checks in pull requests, not just style.
• DevOps engineers add scanners to the pipeline, give every service the least privilege it needs, and keep base images patched.
• The security team becomes an enabler: it chooses tools, writes guidance, trains "security champions" (one interested developer per team) and helps with threat models.

Threat modelling: thinking like a defender

Threat modelling is a structured conversation about what could go wrong with a design before it is built. Four simple questions guide it: What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job?

Start with a data flow diagram (DFD): a simple drawing of external entities (users, a payment gateway), processes (your API), data stores (databases, buckets) and the arrows between them. Then mark the trust boundaries: the places where data crosses from a less trusted zone to a more trusted one, such as from the internet into your API. Most threats sit on those boundaries.

[Student phone] --HTTPS--> | trust boundary | --> [Canteen API] --> (Orders DB)
                                                        |
                                                        +--> [Payment gateway]  (external)

Then walk through each element and arrow with STRIDE, a checklist of six kinds of threat. For each one, ask "could this happen here?" and note the defence.

The OWASP Top 10 for DevOps people

OWASP (the Open Worldwide Application Security Project) is a non-profit that publishes free security guidance. Its Top 10 is a list of the most common web application risks. The table follows the 2025 edition; the 2021 edition is still widely quoted, so check owasp.org for the exact wording.

Secure defaults

A secure default is a setting that is safe unless someone deliberately changes it. People rarely change defaults, so the default decides how secure most systems are. Examples: new storage buckets are private, containers run as a non-root user, debug mode is off in production, network access is denied unless allowed, and every new service account starts with no permissions.

Security gates that do not block everything

A security gate is a pipeline step that fails the build when a scanner finds a serious problem. If the gate fails on every low-severity finding, developers learn to ignore it or ask for it to be switched off. A good gate is strict about what matters and quiet about the rest.

• Severity threshold: fail on critical and high findings; show medium and low as warnings.
• Baseline: fail only on new findings in this change, and track older ones as a backlog to burn down.
• Exceptions with expiry: when a finding cannot be fixed yet (no patch exists, or it is a false positive), record an exception with an owner, a reason and an expiry date. After the date, the gate fails again.

# security-gate.yaml: read by the pipeline's gate step
fail_on: high            # fail on high and critical
exceptions:
  - id: DEMO-2026-0012
    reason: "No fixed version of the PDF library yet; input is only from staff"
    owner: priya@example.com
    expires: 2026-12-31