Security Engineering Skills to Learn: 4 New Defend the Org Skills

Defend the Org launched in May with five skills: detection engineering, threat hunting, incident response, security operations, and MITRE ATT&CK mapping. Every one of them starts the same way. Something already happened, and your job is to find it, understand it, and shut it down.

That is most of the job for most defenders most of the time. It is also a ceiling. You can run a clean queue for three years, catch things nobody else caught, and still not be in the room when the architecture gets decided. The work that prevents incidents happens somewhere else — in design reviews, in pull requests, in the forty lines of Python that turn a good idea into something that runs every five minutes.

In the four months since launch we've shipped four skills that live in that other room: Scripting, Code Review, System Design, and Threat Modeling.

They aren't four unrelated additions. Read in order, they are one arc — design the system, build the tooling, review the change, then attack the design on paper before somebody else attacks it in production.

Scripting: Python for log parsing and security automation

Almost every security job comes down to a version of the same task: take messy data and turn it into an answer someone can act on. Parse the log nobody else wants to parse. Turn a JSON export into the spreadsheet a stakeholder actually asked for. Write the detection idea as code. Collapse ten thousand alerts into the forty that matter.

Scripting is the multiplier on every other skill in this list. It is also the part of the interview loop most candidates underprepare for. The coding screen for a security role is rarely algorithm trivia and almost always data wrangling under time pressure.

Who it's for: detection and response engineers, SOC analysts automating the thing they have now done twice, security engineers building internal tooling, and anyone with a security engineering coding screen on the calendar.

Every lab hands you a function signature and states exactly what it must return — the shape, the ordering, what happens on empty input, what happens when a field is missing. You write the body. Python runs in your browser, so there is nothing to install and no environment to stand up. Run against the visible tests as often as you like. When you submit, hidden tests run too, and they exist for exactly one reason: to catch the solution that works on the happy path and falls apart on a malformed line, an empty list, or a timestamp sitting exactly on the window boundary.

See how Scripting works.

Code Review: finding security flaws in pull requests

Every vulnerability in production started as a line of code somebody approved. Code review is where that decision gets made, and where most flaws are either caught or missed. Not running a scanner — making the judgment call a senior engineer makes on every review: what is really wrong, what is noise, and whether this change is safe to merge.

Who it's for: application and product security engineers, senior and staff engineers gating pull requests, security champions embedded on development teams, and anyone building a secure SDLC.

You review real pull requests, laid out the way GitHub lays them out — a Changes tab where you leave findings on specific lines, and a Repository tab where you browse the surrounding code the change now touches. Then you are graded on four things, only one of which is "did you spot the bug":

• Findings — recall and precision. Catching the real issues is half the skill. Spraying comments on clean code costs you points, exactly the way it erodes trust on a real team.
• Classification. A SQL injection is Security → Injection, not a logic nit. The taxonomy is the vocabulary of the craft, and using it correctly is how reviewers communicate.
• Severity and disposition. Does your call match the senior call for this finding in this context? A Critical can be non-blocking if it is already tracked. A Medium can block if the pattern will compound.
• The final call. Approve, Request Changes, or Comment — and it has to follow from the findings you actually left.

A junior finds ten problems and requests changes on all ten. A senior finds the same ten, blocks on the two that matter, notes the rest, and approves with comments. The gap between those two reviews is the whole module. See how Code Review works.

System Design: security architecture and trust boundaries

This is the only proactive discipline on the platform. Every other skill teaches you to respond to something that has already gone wrong. System design teaches you to build so that fewer things can go wrong at all.

Architecture is the cheapest place to fix a security problem and the most expensive place to ignore one. Get the trust zones, the least privilege boundaries, and the identity flows right, and entire classes of attack stop being possible rather than being caught later.

Who it's for: security architects, platform and infrastructure engineers, staff-plus engineers who own how systems fit together, and any team running secure design reviews.

You work on a real canvas. Place components, drop them into trust zones, wire the edges with protocols, and submit. What you are graded on is invariants, never topologies — "the database is unreachable from the internet," "all authentication traffic crosses an IdP." That distinction matters more than it sounds. There are many defensible ways to build a system that works and very few that uphold the right invariants, so grading on invariants means a design we didn't anticipate still passes. If a rule rejects a good design, the rule is wrong.

See how System Design works.

Threat Modeling: finding design flaws with STRIDE

Threat modeling is the deliberate inverse of system design. There, you build. Here, the architecture is finished and frozen, and your job is to find how it breaks anyway.

You read the diagram, trace what talks to what and who trusts whom, spot the threats, put each one in the right category, and prescribe the fix. It is the exact exercise a security design review puts in front of you — and interviewers use "threat model this system" as a standard screen for security roles.

Who it's for: product and application security engineers, teams running design reviews, engineers who own the security section of a design doc, and anyone preparing for a security engineering interview.

Threats get categorized with STRIDE, the same framework real security teams use, and the framework itself is part of the curriculum — you learn which questions apply to which kind of element rather than asking all six of everything. A threat without a mitigation is just a complaint, so every finding needs the design change that closes it. And flagging something that is already handled costs you, because a threat model that flags everything protects nothing.

See how Threat Modeling works.

How these four skills fit the secure SDLC

Design the system. Build the tooling. Review the change. Attack the design on paper. That is the secure development lifecycle, and it is the half of security work that moves people from running the queue to owning the outcome.

They don't sit beside the original five either. A detection you write in the detection engineering module is a thing you could just as easily ship as code in a scripting lab. The architecture you design in system design is the kind of diagram you get handed, frozen, in threat modeling. That overlap is the point. Real engagements don't respect module boundaries, and neither should the practice.

How we teach them: hands-on labs, no home lab

Four principles run underneath all four modules.

• Precision is graded as hard as recall. Every one of these labs contains things that look concerning and are fine. Comment on a clean line in a code review and it costs you. Flag an encrypted, authenticated service as exposed in a threat model and it costs you. Ship a script that passes the visible tests and a hidden test built specifically to defeat it will find you out. Crying wolf is a real failure mode on a real team, so it is a real failure mode here.
• There is more than one right answer. These are judgment disciplines, not answer keys. System design grades invariants precisely so that an unanticipated but valid architecture still passes. Code review has multiple defensible calls on the same diff. We would rather write a harder grader than teach you to pattern-match one blessed solution.
• The feedback is the lesson, not the score. A failure comes back specific and anchored to your work — the path that shouldn't exist, highlighted on your own graph; the reason your function returned the wrong thing on record 40,001. No vague critiques, no percentage with nothing behind it. And if you get stuck, every Easy and Medium lab has a walkthrough that goes one hint at a time, lets you try each step yourself before revealing it, and never touches your score. It teaches the reasoning, not the solution.
• Nothing to install. Python runs in your browser. The canvas, the diagram, the pull request — all of it runs in a tab. No home lab, no VM, no weekend lost to setup before you have learned anything.

Which security skill should you learn first?

If you are already working in security, start with the one closest to the job you want next rather than the one closest to the job you have. An analyst aiming at detection engineering should start with Scripting. Anyone tilting toward product or application security should start with Threat Modeling — it is the fastest way to find out whether you can read a design cold.

If you are still breaking in, Scripting is the most portable skill on this list and the one most likely to show up in your interview loop. Each of the four has a Beginner track that runs the labs in order, so you are never guessing what to do next.

Four new skills in four months, and the catalogue keeps growing. Grab a seat and start building the half of the job that prevents the incident instead of chasing it.