DevSecOps vs DevOps
Tiffin is a small lunch-ordering web app. Its team merges code a dozen times a day, and a pipeline builds, tests and deploys every change within minutes. That speed is DevOps working well. But if the only security check is a review two days before a big release, a leaked password or a vulnerable library can ride that fast pipeline straight into production. DevSecOps closes that gap.
The rule
Security is everyone's job, at every stage, automated like the tests.
DevOps joined development and operations: one team owns code from commit to production, and automation makes delivery fast and repeatable. DevSecOps adds security to that same loop instead of bolting it on at the end. Three ideas carry it:
- Shared ownership. Developers, operators and security people all own security. The security team builds guardrails and teaches; it is not the only line of defence.
- Shift left. Draw the delivery process as a line from idea to production. Moving checks toward the left, earlier, finds problems when they are cheapest to fix.
- Automation. A check that runs on every change beats a check that someone remembers to run.
This is the Tiffin pipeline you will protect through the whole course:
# tiffin/.pipeline.yml
stages: [build, test, scan, package, deploy]
scan:
steps:
- run: secret-scan . # no passwords or keys in the code
- run: dependency-scan . # no libraries with known holes
- run: static-analysis src/ # no risky code patternsThe same pipeline that runs unit tests now also runs security tests, and a serious finding fails the build just as a failing test would.
The shortcut
For every risk, ask: "What is the earliest stage that could catch this?" Then put an automated check there, and keep a later check as a safety net.
On the laptop
A pre-commit hook scans the change and blocks the commit. Cost to fix: ten seconds.
The trap is thinking DevSecOps means buying scanners. Tools without shared ownership just produce reports nobody reads. The habit comes first; the tools make the habit cheap.
Drills
Answer fast — trust the rule.
What does "shift left" mean in DevSecOps?
Tiffin's requirements.txt pins a library version with a known serious vulnerability. Where is the cheapest place to catch it?
What does DevSecOps add to DevOps?
Which of these goes against the DevSecOps approach?
Remember
- Security is everyone's job, at every stage, automated like the tests.
- Ask "what is the earliest stage that could catch this?" and put a check there.
- Tools without shared ownership only make unread reports.