Security for developers

Key takeaways For a builder, security isn’t a final gate you clear before launch — it’s a set of habits woven through the whole process. Shift left: think about how things break at design time, when fixing them is cheap. Keep security in the workflow so it happens by default, not by heroics. And lean on a repeatable checklist so nothing important gets skipped. This lesson ties the path together into how you actually work, building on secure coding.

You already know how to write safer code line by line. This lesson zooms out to the whole build: where security fits in the process, how to spot problems before you write the code, and how to make good habits automatic. The goal is educational — understand why each step earns its place so you reach for it without being told.

Shift left

“Shift left” pictures your project as a timeline running left to right — design, coding, testing, launch. The earlier (further left) you consider security, the cheaper it is to get right.

A weakness spotted while you’re sketching the design is a few minutes of rethinking. The same weakness spotted in testing means reworking code that’s already written. Found in production, it can mean an incident, a scramble to patch, and real data at risk. The cost climbs steeply the longer it hides.

So don’t bolt security on at the end. Bake it into design and coding, the same security mindset you’d bring to any part of the craft. Security that lives at the start is prevention; security that only shows up before launch is cleanup.

Threat model early

Before you write code, spend a few minutes on a quick, structured question: what are we protecting, from whom, and how could it go wrong? That’s threat modeling, and it belongs at design time.

It doesn’t need special tools — a short conversation and a few notes will do. Sketch what data and functions matter, who might want to abuse them, and where an attacker could push. You’re mapping the threats, vulnerabilities and risk for this system while the design is still soft enough to change cheaply. The output is a short list of “here’s what we should defend and how,” which then drives the choices below.

A developer’s security checklist

Threat modeling tells you what matters; a checklist makes sure you actually cover it. This one ties the whole path together — treat it as the defaults you apply to every project.

  • Validate input and avoid injection. Treat everything from outside as hostile until checked, and never let data become code — the heart of secure coding and the defense against web application attacks.
  • Authenticate and authorize properly. Prove who the user is (authentication basics) and check what they’re allowed to do (authorization and access) — they’re two separate steps and skipping either is a hole.
  • Manage secrets. Keep API keys, passwords, and tokens out of code and out of version history — see secrets management.
  • Keep dependencies patched. Most of what you ship is other people’s code; update it and watch for known vulnerabilities, including in your Git and repository security hygiene.
  • Use TLS and secure config. Encrypt data in transit and don’t ship insecure defaults — securing networks & services and hardening systems.
  • Test and scan. Layer in testing plus SAST (scans your source), DAST (probes the running app), and dependency scanning (flags vulnerable libraries).
  • Least privilege in production. Give each part of the system only the access it truly needs, so a compromise stays small.
  • Log and monitor. You can’t respond to what you can’t see — set up monitoring and incident response so problems surface.

Automate the guardrails

A checklist only helps if it runs. The reliable way to make security non-optional is to move the checks off your memory and into automation.

Put your scans and tests into CI so they run on every change: SAST, dependency scanning, secret detection, and your test suite all as pipeline steps — GitHub Actions is a common home for them. When a check fails the build, security stops being something a busy developer can quietly skip. The machine remembers the checklist so you don’t have to.

Plan for failure

Even with all of the above, assume something eventually gets through — that humility is itself a security practice. The question isn’t only “how do we keep attackers out?” but “when one gets in, how fast do we notice and recover?”

That’s defense in depth: layers, so no single failure is fatal. Make sure you have logging to reconstruct what happened, backups you’ve actually tested restoring, and a written response plan so people aren’t inventing one under pressure. Monitoring and incident response turns “we got breached” from a catastrophe into an event you handle.

Quick check: "shift left" in security means…

Recap

  • Security is a set of habits woven through the whole build, not a final gate.
  • Shift left: problems are cheapest to fix at design time and most expensive in production.
  • Threat model early — “what are we protecting, from whom, and how could it go wrong?” — before the code exists.
  • Work the developer’s checklist: input validation, auth, secrets, patching, TLS, testing/scanning, least privilege, and logging.
  • Automate the guardrails in CI so security isn’t optional, and plan for failure with layers, backups, and a response plan.

Next up: staying safe online