Skip to content
academia.sh
tr
Log in

Course Intermediate

The Secure Development Lifecycle

Published Updated

By the end of this course

Start course

01

The DevSecOps Approach

The measured difference between folding security into the development flow and keeping it as a separate gate: in which stage the same set of items is born, in which stage it is caught, and how many stages late that is, how many times shift left cuts the per-stage fix cost, and the item class for which catching things early does not help at all, the automated testability of security requirements, the requirements that abuse cases surface, spreading security competence across teams, and risk-based allocation of limited development capacity.

  1. 01 The Difference Between DevSecOps and DevOps The same 23-item set is run through two flows: a single security gate standing before deployment catches 10 items, never sees 5 of them, and leaves 120 changes waiting in the queue by day 60; once the check is spread across six stages, all 23 items are caught and the average delay drops from 1.94 stages to 0.13 stages. The cost of spreading it out is that 177 of 200 alerts are false positives.
  2. 02 Shift Left The fix cost per stage is derived from the work that gets undone, and the same 23-item set is run through two flows: on the 18 items common to both, the late flow costs 318 hours, the early flow 68 hours, a 4.68 multiplier, and once the check load is subtracted from the 250 hours prevented, a net gain of 217.5 hours remains. The multiplier is not a single number — it is 22.5 for an item born in the requirement stage and 13 for one born in deployment; half of the early flow's cost comes from the single item shift left can never touch.
  3. 03 Security Requirements Testability is derived from three parts and run on 20 security requirements: 13 are automatically testable, 3 are checked by eye because of a single missing part, and 4 can never move into any class without being rewritten, because of their qualitative predicate. Five abuse cases grow the list by 40 percent, and 7 of the 8 incoming requirements are in denying mode; the 40-hour load of manual checking drops entirely once the missing parts are written.
  4. 04 Security Champions The distribution of security competence is measured over five teams' 35 weekly reviews: the central team alone covers 16 reviews and 19 go through without a security eye, and coverage saturates with four champions. A single champion covers an average of 0.86 teams, and even with a champion on every team, 6 reviews a week are left to the center; when a fifth champion is added, catching items that require expertise drops from 2 to 1, because the center no longer sees those reviews.
  5. 05 Risk-Based Prioritization The 23-item stack carries 68 developer-days of effort and 667 hours of deferred cost; 22-day sprint capacity is given to four different sorting criteria. The born-first ordering closes 6 items while the low-effort ordering closes 13 items with the same budget, and prevented hours per unit rise from 10.95 to 17.10. Only 2 items in the stack are inside under every criterion, 5 are outside under every criterion; the fate of the remaining 16 items is decided by the criterion choice.

02

Threat Modeling

Measuring which item can be found at the design stage and how many hours finding it costs: the duration of a threat modeling session and its hours per item, counting the flows that cross a trust boundary in a data flow diagram, the flows that stay invisible when no boundary is drawn, the raw threat count that systematic threat generation produces and the share of it that is meaningful, elimination time, the coverage of scenario-based modeling and its intersection with the systematic method, the cost of the cheapest path in an attack tree and how many times closing a node multiplies the root cost, how much of the model's output converts into work items, and the written acceptance of residual risk.

  1. 01 The Purpose of Threat Modeling A threat modeling session's own measure: in an 18-item inventory, the session takes 40 developer hours, finds 10 items, saves 866 hours against 4.0 hours per item, produces a cost difference ranging from 4x to 30x when the same item is caught late, brings total fix hours down from 1,872 to 1,006, and leaves the eight items the session never touches carrying 48.4% of the total hours.
  2. 02 Data Flow Diagrams The topic's core measurement: in a graph of 17 nodes, 26 flows, and six trust zones, 23 flows cross a trust boundary, and these crossings produce a total of 58 items at 2.52 per flow, with 58.6% of the items coming from flows that go from a lower to a higher level; a coarse outer/inner drawing sees only 7 of the 23 crossings and only 15 of the 58 items, and the 16 crossings that stay invisible carry 43 items.
  3. 03 Threat Classification Methods Systematic threat generation's two numbers: applying six categories to 43 graph elements produces 156 raw threats, 108 of which (69.2%) are valid for this system and 48 of which turn out invalid, elimination spends 72 minutes for no return, the total session load comes to 666 minutes, and generation limited to exposed elements alone finds 92.6% of the valid threats 63.5 minutes cheaper.
  4. 04 Risk-Focused Modeling Scenario-based modeling's coverage measurement: five scenarios producing 51 threats, 39 of which intersect with the systematic set and 12 of which are chain threats not defined on any single element, scenarios missing 63.9% of the systematic set, 24 of the missed ones falling in the denial-of-service category, the scenario method running at 0.234 threats per minute — 1.44 times the speed of systematic generation — and the union of the two methods coming to 120 threats.
  5. 05 Attack Trees Cost measurement of goal-backward decomposition: in a tree of 12 leaves and three sub-goals, the root cost is 9 fictional units and the cheapest path is two steps, closing 10 of the 12 leaves never changes the root cost at all, the single most efficient closure yields 1.22x for 2 countermeasure units, a four-countermeasure-unit OR node yields 1.89x, the greedy order closes the root at 28 units, and the same result is reached at 16 units by picking one OR node per branch.
  6. 06 Using Model Output Measures the model output's conversion into work items: 120 threats fall into 24 countermeasures, only 11 of which carry all three of owner, acceptance criterion, and release target and turn into work items, closing 73 threats (60.8%); the 13 lost items carry 47 threats and 97 effort-days, 4 of which are accepted in writing and 9 of which remain silent residual risk carrying 33 threats on their own.

Final exam

The Secure Development Lifecycle — Final Exam

In preparation

This course's question bank is not complete yet. The exam opens here automatically once enough questions are added.

Start typing to search.

↑↓ ↵ Esc navigate · open · close