Security as a Definition of Done: Baking AppSec Into Every Sprint
We've watched too many teams treat security like a tollbooth at the end of the highway. You build for three months, you book a pen test for the week before launch, and you cross your fingers. Then the report lands, full of red, and now you're rewriting auth two days before the board demo. We've been the people called in to clean that up. It's not fun, and it's expensive, and most of it was avoidable.
Here's our position, plainly: security isn't a phase. It's part of what "done" means. A feature that handles user data but hasn't been threat-modelled, doesn't enforce its own access rules, and has no test proving it isn't finished. It just looks finished.
Why the late pen-test-only approach keeps failing
The pen test isn't the problem. Pen tests are great. The problem is making it the only line of defense, scheduled at the worst possible moment.
Three things go wrong, every time.
First, the findings show up when they're most expensive to fix. A missing authorization check caught at design time is a sentence in a doc. The same gap caught in a pre-launch pen test is a refactor, a regression risk, and a delayed release. The cost of a fix climbs steeply the longer it sits in the codebase, and a pen test is about as late as you can possibly catch it.
Second, it manufactures a false sense of safety. "We passed the pen test" gets read as "we're secure." But a one-week engagement against a frozen build tells you about that build, on that day, against whatever the tester had time to poke. Ship a feature the following Tuesday and you're flying blind again.
Third, and this is the quiet killer, it makes security somebody else's job. The engineers build, the testers find, the engineers begrudgingly patch. Nobody who wrote the code ever owned its safety. That dynamic guarantees the same classes of bugs come back next quarter, because the people writing the code never internalized why they mattered.
What "done" actually means for security
When we say security is part of the definition of done, we mean it shows up in the same places every other quality bar does: the design doc, the codebase, and the test suite.
Threat modelling at design time
Before we write the feature, we spend 30 minutes asking the uncomfortable questions. Who can call this? What happens if they're not who they say they are? What's the worst input someone can send? Where does the data go and who can read it later?
This doesn't need a heavyweight framework. A whiteboard and a senior engineer who's seen things will catch the big stuff. The point is to find the design-level mistakes while they're still just lines on a whiteboard, because those are the ones you can't patch your way out of later.
Secure defaults in the codebase
The cheapest security is the kind nobody has to remember. We push hard for defaults that fail closed:
When the safe path is also the easy path, you stop relying on every engineer making the right call at 6pm on a Friday.
Tests that encode security requirements
This is the part most teams skip, and it's the part we care about most. Security requirements are just requirements. So we test them like requirements.
If a non-admin shouldn't be able to hit the admin endpoint, there's a test that logs in as a regular user, calls the endpoint, and asserts a 403. If a user shouldn't read another tenant's invoices, there's a test that tries and expects to fail. These tests run on every commit, forever. The day someone refactors the middleware and quietly breaks authorization, the build goes red before the code ever reaches review.
A green pen test is a snapshot. A green test suite is a ratchet. It can't slip backward without somebody noticing.
The automation that runs on every commit
Humans are good at judgment and terrible at repetition. So we hand the repetitive checks to the pipeline and save the humans for the parts that need a brain.
On every commit and every pull request, four things run automatically:
The honest catch with these tools is noise. Out of the box, they cry wolf constantly, and a wall of low-severity warnings trains everyone to ignore all of them, including the real one. So the work isn't turning the tools on. It's tuning them. We triage the rules, suppress the noise with documented reasons, and set the bar so that when the pipeline fails, it means something. A check that's always red is the same as no check at all.
Tuned well, the automation clears the underbrush. By the time a senior engineer reviews a PR, the boring, mechanical findings are already handled, and the human attention goes to the things only a human can judge: is this authorization logic actually correct, does this design create a privilege escalation path, is this trade-off acceptable.
The economics, because this is really an economics argument
Strip away the principle and it's a money conversation. A bug gets cheaper to fix the earlier you catch it, and the curve is brutal.
Caught in design review, a flaw costs you a conversation. Caught by a test on commit, it costs a few minutes before the code merges. Caught in a pre-launch pen test, it costs a scramble, a re-test, and probably a slipped date. Caught in production, after a breach, it costs incident response, disclosure, regulatory attention, and the customer trust you spent years building. Those last two aren't on the same scale as the first two. They're not even the same kind of number.
Shifting the work earlier isn't us being purists. It's the cheapest way to ship. Every hour spent threat modelling buys back days of firefighting you'd otherwise pay for at the worst possible time.
What this looks like in a normal sprint
There's no "security sprint." That's the whole point. The work dissolves into the work you're already doing.
A ticket gets picked up. During design, the engineer spends a few minutes on the threat-model questions and notes the answers in the ticket. They build the feature on top of secure defaults that are already baked into the framework, so most of the safe behavior is free. They write the feature tests and the security tests in the same sitting, because to them it's all just "does this behave correctly." They open the PR, the pipeline runs SAST, dependency, secret, and DAST checks, and a senior engineer reviews code that's already passed the mechanical bar.
No separate phase. No gate at the end. No quarter-end scramble. Just a slightly different definition of what it means to call something finished.
Secure software, shipped fast
People hear "security-first" and assume "slow." We'd argue the opposite, and we've shipped enough to back it. The slow teams are the ones doing security in a panic at the end, eating rework and blown timelines. The fast teams made safety cheap by making it constant.
"Secure software, shipped fast" isn't a slogan we bolt onto a feature near the finish line. It's a property of how the team works, every commit, every sprint. Get the definition of done right and security stops being a thing you do to the software. It becomes a thing that's already true about it.