DevSecOps: Where to Start, a Step-by-Step Plan

DevSecOps is not the purchase of a single scanner but a change in process: security becomes part of every stage of development. Start with a maturity assessment and a list of critical systems, then close the quick wins (SCA, secrets, artifact repository), embed checks in CI/CD with soft quality gates, train people and measure results. Here is the plan we apply in projects in Kazakhstan and Central Asia.

Step 1. Understand where you are now

Start with an inventory: how many applications and teams you have, where code is stored, how CI/CD and releases are organized, and which checks already exist. It helps to rely on maturity models: OWASP SAMM (Software Assurance Maturity Model) is an open framework that helps assess current secure development practices, build a balanced program iteratively and measure progress; OWASP DSOMM (DevSecOps Maturity Model) is an OWASP project focused specifically on DevSecOps. Together they fix the starting point and the target level, so the goal is not reduced to the phrase "we want to be more secure".

NIST SP 800-218 (SSDF) can serve as a foundation for process requirements. It is a set of high-level secure software development practices, published in February 2022. It fits any software development lifecycle model and gives customers and suppliers a common language for discussing security.

Step 2. Define risks and priorities

Not all applications are equally critical. Internet banking and an internal wiki require different levels of control. Build a list of critical systems based on the data they process, their exposure to the internet and their business impact, and start the rollout with them. This list also becomes the basis for the budget, since the cost of rollout depends on the number of applications, teams and chosen tools.

Step 3. Quick wins

• SCA and open-source control. Minimal false positives, maximum effect. See the differences between SAST, DAST and SCA.
• Secrets outside the code. Find passwords and tokens in repositories and move them to a secrets store. More on secrets.
• A secured artifact repository with blocking of malicious packages.

These measures deliver visible results within weeks without breaking development processes, and they give leadership first results to look at.

Step 4. Build checks into the pipeline

Each check has its place:

• Commit / pull request: SAST on changed code, secrets scanning.
• Build: SCA, SBOM generation, container image scanning.
• Test environment: DAST, FAST for the frontend.
• Production: regular DAST scanning and monitoring.

From the very beginning, agree on quality gates: which findings block a release and which become tasks. Start softly, with reporting, and tighten the rules gradually. For scheduled DAST scans, a scheduled mode works well, for example a nightly run that needs minimal involvement once configured. The technical side for GitLab is covered in how to embed SAST and SCA in GitLab CI.

Step 5. Choose tools through a pilot

Do not buy a tool based on a vendor's presentation. Take 3–5 repositories from different teams, test the candidates on the same data, and assess the share of true findings, scan speed and convenience for developers. How to organize such a test is described in our article on a 30-day SAST and SCA pilot.

Step 6. Train people

Tools are useless if developers do not understand their results. Short practical courses on secure development and finding triage pay off fastest. We run corporate training in AppSec and DevSecOps. A good practice is to appoint a "security champion" in each development team, who triages findings first and helps colleagues.

Step 7. Measure

• Share of applications covered by checks
• Mean time to remediate (MTTR) for critical vulnerabilities
• Number of vulnerabilities found before production vs after
• Share of false positives

Metrics are not needed just for the sake of reporting: they show where the process stalls, and they justify further funding.

Common mistakes

• Buying a tool and "turning everything on": the team drowns in thousands of findings.
• Blocking releases from day one: development starts bypassing the checks.
• Running DevSecOps with the security team alone, without development and DevOps.
• Not assigning owners for remediation: findings without a responsible person do not get closed.

If you need an action map tailored to your organization, you can request it on the DevSecOps implementation page.

Roles and responsibilities

DevSecOps does not work while security is the responsibility of a single department. A practical split looks like this: the security team defines policies and requirements, analyzes high-risk findings and monitors metrics; developers fix defects in their own code and dependencies; DevOps engineers embed checks into pipelines and maintain the tooling infrastructure; product owners make decisions on exceptions and priorities. For large organizations with several teams, it helps to appoint a security lead in each team, who becomes the point of contact with the security team.

How to keep momentum during rollout

The most common failure scenario is a large project with delayed results. A rollout that takes a year before delivering any value loses leadership support and team enthusiasm. A better approach is short iterations of two to four weeks, each delivering a concrete, visible result: secrets found and closed, a malicious package blocked, a report on the state of critical applications. After each iteration, review priorities based on the metrics from the previous section.

It is also worth planning how to handle the accumulated security technical debt. Old code almost always contains hundreds of findings. Do not try to close everything at once: record the current state as a baseline, prevent new critical issues from appearing in changes, and steadily reduce the old debt in a separate backlog.

How DevSecOps differs from traditional AppSec

The classic approach to application security relies on periodic checks before release, often carried out by external specialists. DevSecOps moves part of these checks into daily work: automated scans on every change, fast feedback for developers, and unified policies for all teams. In-depth periodic checks do not disappear: penetration testing of critical systems and expert analysis remain an important part of the program, but now they complement continuous control rather than replace it.

What changes for developers

Success depends on how the new checks feel in day-to-day work. Findings should appear where developers already work: in the pull request, in the IDE, in the task tracker. Every finding should include a clear description, its location in the code and a remediation recommendation. Messages such as "500 problems found" without context cause rejection, while three specific findings with a ready fix are actionable. That is why at the start it is better to configure scanners strictly for critical defect classes and expand coverage as the team gets used to them.

Timing matters too. If a check in the pull request takes tens of minutes, people will start bypassing it. Heavy scans are moved to nightly runs or release branches, while fast checks (secrets search, SAST on changed files, SCA on manifests) stay in the main flow.

How to make the case to leadership

Leadership rarely cares about tool names. It is better to talk to them in the language of risk and cost: which systems are critical, what would happen in an incident, what requirements regulators and customers impose, and how much time manual pre-release checks take today. Baseline measurements (coverage, remediation time, number of production findings) provide a reference point, and the trend in metrics over a few quarters becomes the argument for continuing the program. Prepare a plan of several iterations with a clear result in each, and the budget discussion becomes concrete.

Frequently asked questions

Sources

• OWASP SAMM
• OWASP DevSecOps Maturity Model (DSOMM)
• NIST SP 800-218: Secure Software Development Framework (SSDF) v1.1
• OWASP DevSecOps Guideline: DAST