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.
