Part 1 : Security in DevSecOps

Hey everyone 👋

So here’s the deal: I’m not a DevOps engineer. I come from the Incident response/Forensic side. But in my current organization, we’re working on DevSecOps, and that means I had to start learning how security fits into the DevOps world.

I thought, instead of keeping all this in my notes, why not share it here? I’m trying to simplify things as much as possible. If you find mistakes or think I should add something, just let me know.

This is a journey, and I’m still learning too.

Where Does Security Fit in DevSecOps?

When we talk about DevOps pipelines (Continuous Integration and Continuous Delivery), security can’t just be an afterthought. We have to weave it into every stage.

• CI (Continuous Integration): Fast cycle, quick checks. Mostly useful for catching small mistakes like hardcoded passwords, dangerous functions, or dependency issues. Think of it as your “first line of defense.”

• CD (Continuous Delivery): This is where the deeper stuff happens—like scanning, penetration testing, and verifying that everything is safe before going live.

Bottom line: CI is for quick wins in security, while CD is for serious checks.

Step 1: Pre-Commit (Before the Code Even Lands)

This is the stage where developers are still writing or committing code. From a security perspective, this is where we want to stop problems before they even enter the repo.

Here’s what to focus on:

• Data classification: Figure out which data is sensitive (personal info, passwords, financial data, etc.). Different data types need different protection levels.

• Platform risks: Choosing a cloud, OS, database, or framework? Each has its own security risks. Understand them before locking in your choice.

• Tool support: Make sure your toolchain supports security scans (SAST, DAST, IAST).

💡 Tip: Treat this stage like a health check. If something feels risky—new API, new user role, new database—it’s worth reviewing from a security lens.

Quick Threat Modeling (Don’t Panic, It’s Simple)

“Threat modeling” might sound heavy, but think of it like asking common-sense questions:

1. Did we just change the attack surface (e.g., opened a new port, exposed an API)?

2. Did we add/upgrade any major library or framework?

3. Are we touching sensitive areas like authentication, encryption, or access control?

4. Are we handling new sensitive data?

5. Are we touching critical or high-risk code?

If the answer is yes to any of these, slow down and do a deeper review.

Tools That Can Help (So You’re Not Doing This Alone)

Good news: you don’t have to do everything manually. There are plenty of tools and plugins that can catch security issues right as developers are coding.

Here are some handy ones:

• VS Code Plugins:

  • Semgrep – smart code scanning

  • Checkov – IaC (Infrastructure as Code) scanning

  • cfn_nag – scans AWS CloudFormation

• IntelliJ / Eclipse Plugins:

  • Built-in code inspections (Java, etc.)

  • FindBugs / SpotBugs – bug detection

  • Find Security Bugs – security-focused checks

• For .NET / Visual Studio:

  • Puma Scan

  • Security Code Scan

  • Microsoft DevSkim

• Commercial Options (if your org wants premium tools):

  • Checkmarx

  • Coverity

  • Fortify

  • Veracode Greenlight

Think of these as “spell checkers for code security.” They highlight issues in real time while developers type or when they hit save.

-------------------------------------------------------------------------------------------------------------

Example: Spotting Risks in a Repo

Let’s say you scan your repo with a tool like SCC (Sloc Cloc and Code), and it tells you that the main language being used is Dockerfile.

As a security person, that’s an “aha” moment. Why? Because Docker means containers, and containers bring their own security challenges—like image scanning, Dockerfile best practices, and proper configuration.

So just by knowing the tech stack, you already know what security areas to focus on.

-------------------------------------------------------------------------------------------------------------

Wrapping It Up

The main point is this: Security in DevOps doesn’t have to be scary or complex.

Start small:

• Catch issues early with pre-commit checks and IDE plugins.

• Ask simple threat-modeling questions whenever something major changes.

• Use the right tools to automate scanning so developers get feedback fast.

By doing this, security becomes part of the normal workflow—not a blocker at the end.

---------------------------------------------Dean------------------------------------------------------

Keep following and keep checking my best — we will proceed further in the next article.