Kiber təhlükəsizlik · 11 min read

What is DevSecOps and how to learn it?

DevSecOps means placing security not at the end of the software development process but at every stage of it — code, build, container, infrastructure and release. A DevSecOps engineer sets up automated checks in the CI/CD pipeline: code and dependency analysis, secret scanning, container image hardening, Kubernetes policies and infrastructure validation. This way, security becomes the job of the pipeline rather than of a separate department.

What is DevSecOps and how does it differ from DevOps?

DevOps is a workflow built so that software is written, built and released faster. DevSecOps adds control points to that flow: every change is automatically checked for vulnerabilities, leaked secrets and misconfiguration. Speed is not lost, because the checks run not manually but as the pipeline's own steps.

This approach is known as the shift-left principle. The logic is simple: fixing a mistake while the code is being written is far easier than fixing it in the production environment. NIST's Secure Software Development Framework (SSDF) and the OWASP DevSecOps guideline propose the same sequence — a separate check for each of the requirements, code, build and release stages.

What does a DevSecOps engineer do day to day?

Most of the role is not installing new tools but making the existing pipeline understandable and tolerable. If a long list of warnings appears after every commit, the team stops looking at them within a week. That is why the main product of a DevSecOps engineer is the quality of the signal.

• Integrating static code analysis (SAST) and dependency analysis (SCA) steps into the CI/CD pipeline and optimizing their run time.
• Triaging incoming findings: which is a real risk, which is a false positive, which is left for the next sprint.
• Secrets management: cleaning keys and passwords out of the repository, moving them to a secret storage system, writing a rotation procedure.
• Minimizing container images, enforcing image signing and blocking an unsigned artifact from running in the registry.
• On the Kubernetes side, narrowing RBAC roles, writing network policies, testing admission control rules.
• Running Terraform code through checks: open ports, broad permissions, unencrypted disks.
• Talking with the developer team — delivering a finding not as a ban but as a concrete suggested fix.

At which stages of the CI/CD pipeline is security checked?

1. Writing code: simple rules run in the developer's environment — dangerous functions and hardcoded values become visible immediately.
2. Commit and pull request: secret scanning and fast SAST rules run; if a key ends up in the repository, the merge is blocked.
3. Build: the dependency tree is checked with a full SAST scan and SCA, and library versions with known vulnerabilities are flagged.
4. Container: the image is built on a minimal base, scanned, signed, and provenance information is stored together with the artifact.
5. Before deploy: infrastructure-as-code (IaC) files — the Terraform plan — are evaluated against policy rules.
6. Inside the cluster: admission control rejects a manifest that does not comply with policy, and RBAC and network policies narrow the scope.
7. Runtime: behavior monitoring and configuration drift detection reveal manual changes and anomalous activity.

What knowledge do you need beforehand to learn DevSecOps?

DevSecOps is an intermediate-level track. This means you must understand the system itself before you learn security. Without knowing what works and how, it is impossible to read a scan result — the text that appears on the screen remains just a red line to you.

• Linux: file permissions, processes, services, reading logs, package management.
• Networking basics: ports, DNS, TLS, proxy logic, the difference between internal and external traffic.
• Git: branch, pull request, merging, removing a file from history.
• One scripting language: Bash is a must, and Python is very useful for automation.
• Container logic: what an image is, what a layer is, how a container differs from the host.
• The ability to read YAML and configuration — this is the language of the pipeline.

If you have no IT experience at all, going straight into DevSecOps is a waste of time. Building a foundation first through Linux administration or the defensive team (Blue Team) track gives faster results.

How do you learn DevSecOps — what should a step-by-step roadmap look like?

1. Foundation: Linux, Git and CI basics. Learn the anatomy of a pipeline — stages, artifacts, environment separation. Outcome: you should set up a simple CI job yourself.
2. Code and dependency analysis. Add SAST, SCA and secret scanning to the same pipeline. Outcome: you should be able to sort findings by severity and suppress false positives.
3. Container security. Image minimization, signing, runtime policies. Outcome: build two images of the same application and compare the size and the number of vulnerabilities.
4. Kubernetes. RBAC, network policies, admission control and handling of sensitive data. Outcome: a small cluster with the principle of least privilege applied to every pod.
5. IaC and cloud configuration. Terraform checks, configuration drift, narrowing permissions. Outcome: at least three misconfigurations stopped at the plan stage.
6. Final project. Build a secure pipeline from scratch and then audit it — what you found, what you fixed, what remains.

• At each stage one working artifact must remain: a repository, a configuration file, a report.
• Do not mix up the stages — moving to Kubernetes without knowing container logic is the most common mistake.
• At the end of each module, write a short note: what you are blocking, why, and with what exception.

Which tools do you learn to work with in DevSecOps?

Tool names change from year to year, while the categories remain. That is why the right measure of learning is not "how many tools do I know" but the question "can I read the output of this category". Someone who understands one SCA tool in depth moves to a second in a day.

How is DevSecOps practiced in the lab?

• Each module ends with one working environment — not slides, but a configuration and a report.
• The small-group format allows findings to be triaged together: three people interpret the same scan result in three ways, and the differences are discussed.
• The audit of the final project is carried out across participants — this also prepares the ability to explain in an interview.
• New groups start every month; at the end of the program, a Log Academy certificate is issued and preparation for international certifications is provided.

Which DevSecOps project can you build for a portfolio?

• A pipeline with scanning stages: for a small application, build a commit → SAST → SCA → image scan → deploy chain and document the blocking rule of each stage.
• A minimal image project: build the same application on a standard and on a minimal base image, and tabulate the difference in the number of vulnerabilities and in size.
• A Kubernetes policy set: write RBAC roles, network policies and admission control rules for one namespace, then test a prohibited manifest.
• A Terraform checking project: write infrastructure with a deliberately wrong configuration and set up rules that stop it at the plan stage.
• A secrets management example: remove a secret from the repository, move it to a secret storage system, write a rotation procedure.

1. Keep the project in a separate repository and state its purpose in one paragraph in the README.
2. Add a "Before / after" section: what was not blocked, and what is blocked now.
3. Write down the reason for every decision — why this rule is critical, why another stayed at warning level.
4. Show how you handle false positives; this is what is asked about most in interviews.
5. At the end, acknowledge the limitations: what was not tested, what the next step is.

Who is DevSecOps suited for, and who is it still too early for?

This track is designed for the intermediate level, and the minimum age for participation is 18. The easiest transition is for people who already write code or manage infrastructure, because they have already seen the pipeline from the inside.

What mistakes are most often made when learning DevSecOps?

• Tool collecting: installing ten tools and reading the output of none. Understanding one category in depth is more valuable.
• Treating every finding as "critical". A list without priorities turns the team off the checks completely.
• Not managing false positives. Writing an exception rule and documenting it is part of the job, not an escape route.
• Keeping secrets in the repository. A key that has not been removed from the history is still considered leaked.
• Checking security only after deploy — this is not DevSecOps, it is ordinary audit practice.
• Not protecting the pipeline itself: CI tokens with broad permissions and uncontrolled third-party steps are a real attack surface.
• Not talking to the developer. A rule that is not accepted is switched off a week later.

These mistakes share one root: seeing security as a barrier built against the team. The model that works is the opposite — a check becomes sustainable when it saves the developer's time.