CHAPTER DEEP READ · ACCELERATE · CH 6
Accelerate: The Science of Lean Software and DevOps · Ch 6 · Forsgren, Humble & Kim · 2018
Behind every app on your phone there is a group of people racing to build new features. There is also a second group whose job is "don't let the bad guys in, don't leak anyone's ID number." In most companies these two groups are, quietly, enemies: one thinks the other is slowing everything down, the other thinks the first is being reckless. Chapter 6 asks whether those two things really are a choice of one or the other.
Common sense says the more effort a team spends on security, the slower it must ship. The data comes out backwards: the teams that deliver fastest and most reliably spend about half as much time fixing security problems as the teams at the bottom. They move faster and have less security trouble.
Picture renovating an apartment. Design, knock out walls, run the wiring, paint. Three months of work, all finished — and on the last day the building inspector arrives. He takes one look: the fireproofing that was supposed to go inside the walls isn't there.
Now you have two options, and both are bad. Tear the walls open and redo most of three months' work. Or sign a form saying you'll be more careful next time, and leave the risk inside the wall.
Worse still, there are only one or two inspectors for the entire company and hundreds of crews waiting on them. He has become the bottleneck for the whole building. So everyone learns the same lesson: route around him.
This chapter's answer is not "hire more inspectors." It is to take that one gate at the end and break it into three small things you do all the time:
One: sit down with him for ten minutes before you start. Asking "could this go wrong?" while you are still drawing the plan is ten thousand times cheaper than opening a wall. And you ask it for every feature, rather than saving it all up for one conversation at the end.
Two: deliver pre-inspected materials to the site. This is the clever one. Instead of posting someone at every site to catch mistakes, put the already-approved cement, wiring and fittings on the shelf, ready to grab. Workers take the easy path, so they take the approved one. Making the right thing the least effortful thing beats explaining the rules a hundred times.
Three: turn the checks into automatic gates on the line. Every time work is handed in, a machine sweeps it: any known-leaky old fittings in there? did anyone leave the front door key lying on the step? Nobody waits; the answer comes back in minutes.
Do all three and the inspector's job changes shape: he is no longer standing at the door stopping people, he is building the road. He spends his time preparing the materials and the machines — and once the road is good, hundreds of crews find the right path on their own. The shortage of inspectors stops mattering.
There's a side effect that explains the strange result: because problems are found the same day they're made, there is far less rework. That is why these teams end up faster, not slower.
Security isn't a door in front of the release; it's a set of small things you do along the way — and the security team's real job is to pave the secure road so well that walking it is easier than going around it. The honest cost: paving is an up-front investment. Those ready-made materials need someone to keep updating them, and if the machines cry wolf too often, people learn to ignore them very quickly.
Want the mechanisms, the research findings, the comparison tables and the diagrams? → Switch to the deep read
You think security and speed sit on a seesaw — more security means slower, faster means you're burying landmines. This chapter takes the seesaw apart with data: teams that build information security (infosec) into daily delivery are not only more secure, they ship faster — high performers spend roughly 50% less time remediating security issues than low performers. The practical shift is just as sharp: the security team's output stops being review comments and becomes a paved road — pre-approved, ready-to-use libraries and toolchains, plus checks that run automatically in the pipeline.
CVE-2017-5638). Identifiers are what let tools automatically answer "is the version I'm running affected?"This is Chapter 6 of Part I ("What We Found"), one of the shortest chapters in the book but a pointed one. It follows Chapter 5 (loosely coupled architecture lets teams test and deploy independently) and sets up Chapter 7 (lean management practices, including the famous result that external change approval boards do not improve stability). The two are really the same argument seen twice: do those end-of-line gates, erected in the name of control, actually protect you — or do they only manufacture queues?
In the real world this chapter is the empirical basis for the word DevSecOps, and the upstream source of today's platform-engineering "paved road" and supply-chain work (SBOM, SLSA). DORA later hardened it into a standalone capability, evolving the name from shifting left on security to today's pervasive security.
Make the old world's pain concrete. A 40-person payments team builds features for a quarter and books a pen test for two weeks before release. The consultant works five days and returns 40 findings, 6 of them flagged "critical, must fix before release." The trouble: 2 of those aren't code bugs, they're design decisions made three months earlier — where the token lives, how long it's valid. Changing them means going back to the design, changing data structures, rerunning every test.
The team has two options. Slip (push the release a month; the business is furious), or accept the risk (sign a form saying it'll be fixed next quarter, then don't fix it next quarter). In practice almost everyone picks the second. That is the irony of the end-of-line security gate: it exists to stop risk, and what it actually produces at volume is known, accepted risk.
The second pain is a structural mismatch in headcount. Security people are always vastly outnumbered by developers — the rule of thumb the DevOps community has repeated for years is roughly dev : ops : infosec ≈ 100 : 10 : 1 (a rough industry figure, not a number this chapter reports). At that ratio, "every feature is manually reviewed by security" doesn't work arithmetically: either the review becomes a rubber stamp, or the security team becomes the most congested segment of the whole pipeline.
The third pain is that the cost of fixing climbs steeply with time. The same issue is a ten-minute conversation at a whiteboard, half an hour in code review, and — once it's in production — an emergency release, downstream notifications, possibly data backfill and public disclosure. The end-of-line gate stacks every finding into the most expensive bucket.
So the chapter's question is: can security stop being a door and become a road? And if it does, does speed pay for it? The answer to the second half is the most valuable line in the chapter.
The line worth memorizing is the statistic: high performers spend about half as much time remediating security issues as low performers. Note the shape of that claim. It doesn't say high performers are more secure and therefore a bit slower, and it doesn't say they traded security for speed. It says the same teams are better on both axes at once.
The mechanism is the "rework radius" from Fig 1: the cost of a security problem is already fixed, at the moment it is found, by how long ago it was introduced. The end-of-line gate stacks every finding into the most expensive bucket, so the bill is three months of rework; shifting left spreads findings along the way, so the bill is one commit's worth of edits. What gets saved isn't "security work" — it's redoing work that was already finished.
This is how the chapter places security inside the book's causal model: shifting left on security is a technical practice; it drives continuous delivery capability, which drives delivery performance and organizational performance. Security isn't a constraint bolted to the side of delivery — it is part of delivery capability itself.
The first practice is: conduct security reviews for all major features, in a way that does not slow the delivery process down. That second clause is the most-skipped qualifier in the chapter — it rules out "add an approval step" as a solution.
Concretely it's two things. First, security people participate in design: while there is still only a whiteboard and a doc, work through the threat-modeling questions — what data does this touch, who wants it, where would they come in. What changes here is a design decision (where the token lives, how permissive the default is, which fields shouldn't be collected at all), and the cost is one conversation. Second, security people attend the iteration demos: high-frequency, small-batch contact replacing low-frequency, large-batch review.
The nuance matters: what moves earlier is participation, not approval authority. Move security earlier and still hand it a veto plus scheduling privileges and all you've built is an earlier door — lead time stretches just the same. The chapter wants a collaborator, not an earlier gatekeeper.
The second practice carries the most engineering weight: the security team's output should be things that make it easy for developers to do the right thing — pre-approved, easy-to-consume libraries, packages, toolchains and processes.
Why is this the pivotal one? Go back to that 100 : 10 : 1 ratio. Manual review capacity grows with the size of the security team, while the number of features needing review grows with the size of engineering — a race you lose by construction. A pre-approved library is different: it's a build-once, used-ten-thousand-times asset. Security spends two weeks getting an auth library right; a hundred teams then call it without security being in the room. That is the only way to move a security team from linear capacity to leveraged capacity.
The industry later named this the paved road: the platform team provides a default-secure main highway, and taking it is the path of least resistance; you may drive off-road, but then the review and the justification are yours to carry. The point is that the default is the secure option. A developer reaching for the org's internal HTTP client instead of npm install-ing a stranger's package usually isn't acting on security training — the internal one has better docs, ships in the scaffold, and has someone to call when it breaks.
This also explains why "more security training" and "publish a secure coding standard" tend to underperform: they raise how much people know, and the bottleneck was never knowledge — it was that the right path costs more effort than the wrong one.
The third practice: security requirements and security tests become part of the automated test suite and the deployment pipeline, rather than a parallel, human-driven process running alongside it.
In practice that means placing checks by feedback latency across the pipeline's stages — the same logic as the test pyramid from Chapter 4: cheap and certain goes early, expensive and fuzzy goes late.
Notice that last shift: penetration testing isn't abolished, it's moved off the critical path. That's how the "without slowing delivery" qualifier actually lands in a pipeline — split security activities into blocking and asynchronous, and put the overwhelming majority in the second bucket.
Three decisions actually have to be made on the ground: when does security engage? which checks block the release and which don't? and does the security team spend its scarce hours reviewing or paving? As tables:
Table 1 · When security engages: the same work, in different places, differs by an order of magnitude
| Engagement point | What it catches | Feedback latency | The honest cost | When to pick it |
|---|---|---|---|---|
| Design (threat modeling) | Architecture-level issues: should this data be collected, where is the trust boundary, is the permission model tractable. No later layer can fix this one | One conversation | People-intensive; needs experienced security engineers, can't be automated, hard to do for every small feature | New systems, anything touching sensitive data, changes to auth / payments / permission models |
| Coding (pre-approved libs) | Whole classes of implementation bug: injection, crypto misuse, token mishandling — eliminated by defaults, not by remembering | Zero (developers never feel it) | Large up-front investment; libraries need long-term maintenance, and an abandoned paved road is worse than no road | Almost always; leverage rises with org size — the security team's first investment |
| Pipeline (automated scans) | Known patterns: leaked secrets, dependencies with CVEs, dangerous constructs, bad infrastructure config | Seconds to minutes | False positives corrode trust; tools need selection, tuning and upkeep — an ongoing cost, not a one-off | Table stakes for every team; start with secret + dependency scanning for the fastest return |
| Staging (DAST) | Runtime and integration issues: misconfiguration, auth bypass, exposed admin endpoints | Tens of minutes | Slow, coverage depends on crawl quality, needs an environment that resembles production | Internet-facing web and API services; limited return on internal batch jobs |
| Pre-release human gate (classic pen test) | Creative attack chains that automated tools never assemble | Days to weeks | This is precisely what the chapter criticizes as a gate: it stacks findings into the priciest bucket and forces a choice between slipping and accepting risk | Keep it, but off the critical path: run it periodically, fix asynchronously, use it to calibrate |
| Production (monitoring / runtime) | Whatever everything else missed, plus zero-days: anomalous behavior, real attack traffic | Real time (but you're already live) | You're already in production; risk of hurting real users, noisy, needs an on-call to absorb it | High-value, high-exposure systems; it's a backstop, not a replacement for the earlier layers |
Table 2 · Choosing automated checks: what to do first, and what should block a release
| Check | What it catches | False positives | Where to put it | Cost / trap |
|---|---|---|---|---|
| Secret scanning | Passwords, API tokens, private keys in commits | Very low | Pre-commit + CI, hard block | Only stops new ones; anything already leaked must be rotated — deleting the commit does nothing |
| Dependency / SCA | Third-party versions carrying known CVEs | Low (though reachability is often overstated) | Every CI build, block by severity | A reported CVE may not sit on your call path; without reachability analysis the backlog drowns you |
| SAST | Dangerous constructs in source (injection, broken access control, deserialization) | High — the main obstacle | Non-blocking at first, scoped to this change; tighten once signal holds | Turning it loose on the whole codebase yields thousands of legacy findings and the team gives up |
| IaC / config scan | Public buckets, over-broad network rules, missing encryption | Low | CI, hard block | Rule sets must track the cloud provider; exceptions need explicit registration and an expiry |
| DAST | Things that only surface when it's running | Medium | Scheduled against staging, non-blocking | Slow; coverage depends on whether it can log in and crawl the deep pages |
| SBOM generation | Catches nothing — produces the list of what you're made of | N/A | Emitted and archived at build time | No protection on its own; the value shows the day a new vulnerability lands and you can answer in seconds |
If you can do only one thing: turn on secret scanning and dependency scanning. Deterministic rules, low noise, broad coverage, and results that don't require a security expert in the room — which is exactly the chapter's "without slowing delivery" qualifier. If you can do a second thing: take the security-relevant code that gets copy-pasted most (auth, crypto, input validation), turn it into a well-maintained library, and put it in the scaffold. That one move usually out-levers every scanner combined.
All three practices are standard equipment in mainstream engineering organizations today; only the names changed. Design-time engagement is threat modeling. Pre-approved libraries and toolchains are platform engineering / the paved road. Automated scanning in the pipeline is DevSecOps. GitHub shipping dependency scanning as a default toggle (Dependabot), cloud vendors baking IaC scanning into deployment tooling — both are vendors completing practice two on an organization's behalf: making the right thing the default thing.
In interviews and architecture reviews it hands you two data-backed questions. Someone says "we need better security, so let's add a pre-release security approval": how will you keep that door from becoming a queue? If you can't, is it stopping risk or only speed? Someone says "security is slowing us down": is your security work happening at design time or before release? The slowness of the latter comes from where it sits, not from security.
EVIDENCE FROM INDUSTRY
CVE-2017-5638; the upstream patch had been available since March 2017, and the intrusion began after May of the same year — more than two months in which the organization could not determine which of its systems were running the affected version. That is exactly what the "dependency scanning + SBOM" rows in Table 2 exist to solve: the hard part was never that a patch existed, it was knowing you were affected.1. The thesis: security and speed are not a seesaw. Teams that build security into daily delivery come out ahead on both axes.
2. The number to remember: high performers spend about 50% less time remediating security issues than low performers. What's saved isn't security work — it's rework.
3. The mechanism is the rework radius: a problem's cost is set by how long ago it was introduced. The end-of-line gate stacks every finding into the priciest bucket.
4. The gate's cruelest effect: built to stop risk, it mass-produces known, accepted risk — because a design-level finding two weeks before release leaves only "slip" or "sign here."
5. Practice one: security reviews for all major features, conducted so they don't slow delivery — security joins design and iteration demos. What moves earlier is participation, not approval authority.
6. Practice two (the highest leverage): make the right thing the easy thing — pre-approved, easy-to-consume libraries, packages, toolchains and processes. This is the only way to move a security team from linear capacity to reusable assets; the industry later called it the paved road.
7. Practice three: security testing in the deployment pipeline, layered by feedback latency — secret scanning hard-blocks in seconds, dependency scanning blocks by severity in minutes, SAST starts scoped to new code, DAST runs non-blocking against staging.
8. Penetration testing isn't abolished, it's moved off the critical path: from "approve this release" to "calibrate what the earlier layers missed."
9. The classic failure: install a scanner, declare victory, hand developers thousands of alerts. The chapter says the reverse — the security team takes on more engineering work — and once false positives corrode trust, the dashboard reads "covered" while real protection is zero.
10. Calibration: a short chapter of principles, not procedures; voluntary survey plus inferential analysis with causality running both ways; written in 2018, so later supply-chain attacks and the "shifted too far left" correction are its necessary patches.