Implementing DevSecOps in Unprepared Teams: A Practical Three-Month Roadmap
Developers are promised secure development but often receive an additional queue before release. Scanners surface hundreds of issues while release deadlines remain unchanged, leaving the author of the nearest commit to interpret the report. Within a week the team searches for ways to disable the checks. This resistance has a rational basis: workload increases, release rules become less clear, and no additional help appears.
In previous articles the threats to CI/CD, capabilities of SAST, DAST and SCA, secrets, containers and infrastructure as code were examined. The final piece assembles a process for a small team without an in-house security specialist. It addresses who owns findings, which checks to enable first, when to halt a release, and how to avoid turning the initiative into another unfinished project.
The following plan covers roughly three months for a team of five to eight developers with a team lead and product owner. One person may combine several roles. The timeline and scope serve as a starting point; the goal is a working process on a single service.
Why teams resist and what to discuss first
The claim that “developers do not care about security” rarely explains concrete delays. A scanner may produce unclear warnings, approvals may take days, and fixing an old dependency may require migrating half the project. Begin with the most recent painful incident: what delayed work, how much time was spent on analysis, who could have decided, and why the issue remained unanswered.
The conflict between speed and security splits into two parts. Machine time for scanning differs from team time spent waiting for answers. If analysis finishes in minutes yet the developer spends two days locating someone to explain the result, the problem lies in work organization. A new scanner will not fix approval queues.
The person introducing security requirements must explain the threat scenario and an acceptable remediation. The developer supplies technical context. The leader sets priority when remediation competes with a promised feature. Without a dedicated security engineer these duties still exist and must be agreed before any blocking rules are activated.
Step 1. Week one: allocate time and assign owners
A short internal agreement is required. Which service is piloted, which problems are unacceptable, who triages messages, and how much time is reserved for configuration and fixes. The document may fit on one page. If the sprint is already full, the leader must remove other tasks; the phrase “work on security when you have time” creates no capacity.
Appoint a coordinator from developers or testers interested in the topic. The role, described in OWASP SAMM as Security Champion, helps interpret findings, maintains rules, and collects questions. The coordinator needs training and dedicated hours; the title alone does not create expertise.
Roles and responsibilities are defined as follows:
- Product owner or leader – allocates time, adjusts priorities, accepts temporary risk within authority.
- Team lead – sets technical requirements, validates threat scenarios, selects remediation.
- Security coordinator – maintains checks, performs initial triage, ensures every task has an owner.
- Component owner – fixes code or configuration and verifies the issue is resolved without breaking required behavior.
Two to four hours per week for the coordinator plus planned remediation work in the sprint is a realistic starting allocation. A backup for leave and urgent cases must also be named.
Step 2. Week two: select one service and two checks
The pilot must be a real service with a clear owner, regular changes, and a test environment. A single session produces a simple diagram of data flows, external exposure, build pipeline, secrets in CI, and privilege differences. Dangerous scenarios such as cross-tenant data access or stolen tokens publishing images are then listed.
Initial checks are chosen to address those scenarios. Secret scanning before commit and in CI together with dependency analysis form a common starting pair. If the team mainly edits cloud templates, IaC scanning may deliver more value. Gitleaks and suitable open-source dependency scanners can be used immediately, yet configuration, updates, and result review still require time.
New rules run first in observation mode for one or two weeks. Confirmed dangerous findings are addressed immediately even without automatic blocking.
Steps 3–6: turning reports into tasks, enabling blocks, simplifying safe work, and measuring results
Each developer receives a task containing location, possible attack scenario, exploitation conditions, assigned fixer, and verification method. Legacy issues are placed in a separate backlog with priorities and deadlines; a baseline prevents every new commit from being blocked by historical findings. Exceptions carry owner, reason, and review date.
Automatic blocking is introduced only after the team has validated rule quality. Quick per-change checks run in merge requests; longer analyses may gate releases of critical components. Scanner failures must never silently count as success.
By weeks seven and eight the team prepares reusable templates, conducts short incident rehearsals, and adds threat discussions to changes affecting user rights or external integrations. DORA metrics for release frequency and change failure rate remain visible alongside security indicators.
By the end of month three the pilot is evaluated on time-to-first-triage, age of open critical defects, false-positive rate, added CI time, and number of expired exceptions. Expansion occurs only when the full cycle works reliably on the first service.
Related articles
Russian State Duma Approves Outsourcing of Banking Secrecy and Client Data Without Consent
The State Duma has passed legislation in its second and third readings permitting Russian banks to transfer client data processing, including banking secrecy and personal information, to external IT contractors and cloud providers. No separate client consent will be required for such transfers. Only accredited Russian IT companies and banks holding a universal license that meet strict domestic control criteria may act as processors, with all servers required to remain inside Russia. Banks must notify the Central Bank of Russia in advance, and contractors must undergo audits by organizations licensed by FSTEC or FSB Russia. Special approval procedures involving the Central Bank, FSB, and Rosfinmonitoring apply to banks under foreign control. The law preserves banking secrecy while expanding the circle of authorized handlers under defined security obligations.
Russia's MinTsifry Drafts Security Requirements for Trusted Domestic Software
The Russian Ministry of Digital Development has published a draft set of requirements for trusted Russian software that go beyond simple domestic origin. The proposals focus on resilience against external interference, absence of known unpatched vulnerabilities, and full development and build processes conducted inside Russia under controlled conditions. Additional rules cover up-to-date component inventories, in-country technical support, and timely disclosure of software updates. Special compatibility mandates are included for Russian browsers and electronic signature tools across multiple product classes such as operating systems, databases, office suites, and communication applications. Compliance verification would be voluntary through expert review, with results recorded in the official Russian software registry and internal-use software lists.
Rostelecom Calls for 'Doomsday' Data Centers to Counter Drone Attacks and Infrastructure Risks
Rostelecom executive Valery Ermakov has urged Russian companies to build geographically distributed backup data centers, dubbed 'doomsday' facilities, to ensure service recovery after site losses. The recommendation follows drone strikes that disabled three Yandex data centers in Sasovo, Kaluga, and Vladimir, disrupting both internal services and Yandex Cloud clients. Ermakov explained that previous centralized infrastructure, built for economic efficiency, is no longer viable under changed threat models that now include physical attacks previously considered unthinkable. He advocated a micro-cellular architecture with services spread across many sites connected by high-speed links, while warning that Russian backbone networks are overloaded and much fiber optic infrastructure dates back 20-30 years. Rostelecom positioned its TEA NEXT line running from Kaliningrad to Mongolia as a source of additional capacity to address potential backbone shortages. Yandex responded to the incidents by accelerating client data migration to partner cloud providers.
Russian Firms Accelerate Cybersecurity Strategy Adoption as Risk Reduction Emerges as Top Priority
A recent AM Live broadcast survey reveals that Russian small, medium, and large companies are increasingly developing information security strategies, with the share of organizations actively working on them rising from 9% to 28% year-over-year. The primary goal cited for 2027 is risk reduction and financial loss mitigation, selected by 78% of respondents compared to 55% previously. Key barriers have shifted, with insufficient source data now affecting 64% of companies and lack of top-management buy-in rising to 43%. Experts including Yaroslav Napalkov from MTS Bank and Nikolay Kazantsev from Securitm emphasized the need for risk-oriented approaches, three-year planning horizons with annual reviews, and early engagement with CEOs and stakeholders. Only 16% of firms have fully operationalized their strategies with metrics and cyber exercises, while personnel shortages remain the leading constraint at 59%.