To try the hands-on steps you will need a project with dependencies and a scanner such as npm audit or Trivy. Everything here is free.
To try the hands-on steps you will need a project with dependencies and a scanner such as npm audit or Trivy. Everything here is free.
DevSecOps means building security into the pipeline instead of bolting it on at the end. You add automated checks that catch vulnerable dependencies, leaked secrets, and risky code on every push, so problems are found in minutes by a machine rather than in production by an attacker. Security stops being one team is gate and becomes everyone is habit, checked automatically.
For the college passout or career switcher who has heard security is important but has never seen how it actually fits into the day to day flow of shipping code.
Someone commits an access key to a public repository by accident. Within minutes, automated bots that scan public code for exactly this find it and start spinning up servers on the stolen account. This is not a rare horror story, it happens constantly, and the window is measured in minutes, not days. The old model of a security review at the very end, long after the mistake shipped, cannot move that fast. DevSecOps is the answer: move security earlier, automate it, and catch the leak before it ever leaves your machine.
In practice this means adding security checks to the pipeline you built in Part 7. Here is a scan step catching a known vulnerable library before it ships.
$ npm audit
lodash <=4.17.20
Severity: high
Prototype Pollution in lodash
fix available via `npm audit fix`
1 high severity vulnerabilityOne command found a known flaw in a library you depend on, named the severity, and offered a fix. Run this in your pipeline and a vulnerable dependency fails the build instead of reaching users.
Everything else in this series built the machine. This part is about not handing that machine to an attacker. And the core reason to do it early comes down to cost.
Shift left: it is cheaper to fix early
The phrase you will hear is shift left, and it means move security checks earlier in the process, toward the moment code is written, rather than leaving them to the end. The reason is money and time. A flaw caught while you are writing the code is a quick edit. The same flaw caught in production is an incident, a scramble, and sometimes a breach with legal weight. The cost of fixing a problem grows sharply the later you find it, which is the whole argument for building security into every step.
The exact numbers vary by study, but the shape is always the same steep climb. That climb is why teams put security scanners right in the pipeline, where they run on every push and catch problems while they are still cheap.
What to scan in the pipeline
A few kinds of automated check cover most of the value, and each looks at a different part of your project. You do not need all of them on day one, but knowing what each finds tells you where your risks hide.
| Check | What it looks at | Catches |
|---|---|---|
| Dependency scan | Your libraries | Known vulnerable packages |
| Secret scan | Your commits | Keys and passwords in code |
| Static code scan | Your source code | Risky patterns and bugs |
| Image scan | Your container images | Flaws in the base image |
Your dependencies are the biggest risk
Here is a fact that reshapes how you think about security. Most of the code in a modern app is not code you wrote. It is the libraries you pulled in, and their libraries, often hundreds of packages deep. That means most of your vulnerabilities live in your dependencies, not in your own lines. A single flawed library, used by thousands of projects, becomes everyone’s problem at once, as the industry learned painfully from widespread library flaws that forced emergency patching across the whole world in a weekend.
This is why dependency scanning gives the most security for the least effort, and why it is the first check to add. A scanner compares your libraries against a public database of known vulnerabilities and flags anything risky, like the lodash finding at the top of this part. Keep your dependencies updated, let the scanner run on every build, and you close off the most common way real systems get breached. It is the single highest value habit a beginner can build.
Secrets: keep them out of code
A secret is any credential: a password, an API key, a token. The rule is absolute: secrets never go in your code or your Git history. Once a secret is committed, treat it as leaked, because history is hard to scrub and easy to copy. Instead, secrets live in a dedicated secrets manager, and your app or pipeline pulls them in at run time. The code references a name, never the value.
A secret scanner in the pipeline is your safety net for the human moment when someone pastes a key into a file by mistake. It blocks the commit before the secret ever reaches the shared repository, turning a potential breach into a small, private do-over.
Least privilege: give the minimum access
One principle underlies most of cloud security: least privilege. Give every person, service, and pipeline the smallest set of permissions it needs to do its job, and nothing more. A deploy pipeline that only needs to update one app should not hold keys to the entire account. The reason is blast radius. When something is compromised, and eventually something will be, least privilege limits how far the damage can spread. Broad, convenient permissions are how a single leaked key turns into a full account takeover. Narrow ones turn the same leak into a contained, survivable problem.
Where the scans fit in the pipeline
The elegance of DevSecOps is that the scans are just more stages in the pipeline you already know from Part 7. Nothing new to run by hand. When code is pushed, the pipeline builds it, then scans dependencies and secrets, then runs tests, and only a clean run reaches deploy. Each scan is a gate, and a failing gate stops the line the same way a failing test does. Security becomes part of the same green or red signal developers already watch.
A lot of security comes down to a handful of default choices, made the safe way. Here are the common ones, insecure habit next to the secure one, so you can spot them in any project you inherit.
| Area | Insecure | Secure |
|---|---|---|
| Secrets | Hardcoded in the code | In a secrets manager |
| Permissions | Admin rights for everything | Least privilege |
| Dependencies | Never updated | Scanned and patched |
| Base image | Large and outdated | Slim and current |
A growing risk is the supply chain: not the library you picked, but the dozens it quietly pulls in behind it. Attackers now target these by publishing packages with names close to popular ones, hoping for a typo, or by slipping malicious code into an update of a trusted package. This is why teams pin exact dependency versions rather than always grabbing the newest, and review what an update actually changes before pulling it in. The lesson from Part 3 returns in a security key: the word latest is a risk, not a convenience, and a locked, scanned set of dependencies is safer than a moving one.
Automate the boring, do not drown developers
DevSecOps done badly becomes a firehose of findings that developers learn to ignore, the same alert fatigue from Part 12 in a new costume. A scanner that reports two hundred low severity issues on every build does not make anyone safer, it just trains people to click past the noise, and the one critical finding drowns with the rest. Security that nobody acts on is theater.
My view: automate the checks that are clear and high value, and fail the build only on those. A leaked secret or a critical, fixable vulnerability should stop the pipeline cold. A pile of low severity notes should go in a report to review later, not block anyone is work. The goal is a small number of security gates that developers trust and respect, because every one that fires means something real. Tune for signal, not for the biggest possible list of findings, and security becomes a habit people keep instead of a checkpoint they resent.
What does shift left mean in security? Answer: it means moving security checks earlier in the software process, toward when code is written, instead of leaving them as a final gate before release. You do it by adding automated scans to the pipeline, dependency, secret, and code checks, so problems are caught in minutes while they are cheap to fix. Add that the cost of fixing a flaw rises sharply the later it is found, which is the whole reason, and you have shown you understand the why, not just the buzzword.
You will not be the security expert as a junior, but you will be expected to not be the weak link. That means never committing a secret, paying attention when a dependency scan flags your build, and knowing that a leaked key must be rotated immediately, not quietly deleted. The junior who says I think I just pushed a key, help me rotate it right away is far safer to work with than the one who hides the mistake. Basic security hygiene, done consistently, is most of what a team needs from you early on.
Free, about fifteen minutes. Take any project with dependencies and run a scan:
npm audit for Node, pip-audit for Python, or scan a container image from Part 8 with a tool like Trivy. Read the report and find the highest severity issue. Then, if a fix is offered, apply it and run the scan again. How to check you did it right: the scan lists real vulnerabilities with severities, and after fixing, the high severity count drops. You just did the single most valuable security check there is, in one command.Security is a culture, not just a scanner
Every scanner in this part is a tool, and tools alone do not make a system secure. The same truth from the very first part of this series applies here: DevOps is culture plus tools, and DevSecOps is no different. A pipeline full of security checks does nothing if people route around it under deadline pressure, share credentials in chat, or ignore the findings because that is how it has always been done. The scanners raise the floor. The culture decides the ceiling.
What a healthy security culture looks like is unglamorous. People feel safe reporting a mistake fast rather than hiding it, because a key rotated in five minutes is a non-event and one hidden for a week is a breach. Reviews ask is this the least access this needs as a normal question, not an accusation. And security is framed as helping ship safely, not as the department of no that blocks everything. As a newcomer you cannot set that culture, but you can live it: own your mistakes quickly, ask the safe-by-default question, and treat the scanners as teammates rather than obstacles. That attitude, more than any single tool, is what teams are really hiring for.
Security questions beginners ask
Do I need to be a security expert for DevOps?
No. You need good hygiene: no secrets in code, dependencies scanned and updated, least privilege by default. Deep security is a specialty, but the basics are everyone’s job now, and getting them right prevents the most common breaches without expert knowledge.
What is a CVE?
A CVE is a numbered entry in the public catalog of known vulnerabilities. When a flaw is found in common software, it gets a CVE id so everyone can track and patch it. Dependency scanners work by matching your libraries against this catalog, which is why keeping libraries current matters so much.
I committed a secret by accident. What now?
Rotate it immediately, meaning revoke the old one and create a new one, and assume the old is compromised. Removing it from a later commit is not enough, because it still lives in history and may already be copied. Rotation, not deletion, is the real fix, and speed matters.
Does DevSecOps slow down shipping?
Done well, no. Automated checks run in seconds inside the pipeline and only stop you for real problems. Done badly, with noisy low value alerts, it does slow teams down, which is exactly why tuning for signal matters. Good security automation is nearly invisible until it saves you.
You can now build safety into everything you have learned to ship. That completes the core toolchain and mindset. The last three parts turn all of it into a plan: Part 16 builds a home lab to practice, Part 17 prepares you for the interview, and Part 18 lays out your roadmap.
New here? Start with Part 7 on CI/CD, where these scans run, and Part 14 on the cloud and its shared responsibility model. The Part 5 Git basics tie into keeping secrets out of history.
References
OWASP Top Ten
OWASP DevSecOps Guideline
CVE Program
About The Author
DrJha