A Secure SDLC is relatively straightforward to manage when an organization has a handful of products. A security team can work closely with developers, help with threat modelling, review findings, and make sure vulnerabilities are addressed. The challenge appears when five products become 20, 50, or 100. A central security team cannot grow at the same rate as the product organization, while simply handing security responsibility to product teams does not work either, especially when those teams have different levels of security maturity.
Product teams need capability, not just security support
Bridging product and security teams
The question is how to balance product-team ownership with the expertise, standards, and visibility provided by central security.
Why SSDLC stops scaling
Many organizations start with tooling: SAST, DAST, and SCA scanners and security checks integrated into development pipelines. But tools do not create a security process on their own. Findings still need to be interpreted and prioritized, responsibilities assigned, remediation tracked, and fixes verified.
The volume can itself become difficult to manage. Across multiple products, vulnerability data can run into thousands of findings, making manual analysis and reporting increasingly impractical. Some of this work can be automated: for example, we have used local AI agents connected through MCP to analyze findings and generate summaries within hours, allowing results to be reviewed daily rather than weekly. Because the data is sensitive, this processing is kept local rather than sent to online models. But automation only addresses part of the problem.
Teams may also lack the skills to perform more complex activities such as threat modelling or build detailed data-flow diagrams, and it is not always obvious which security practices should be introduced at which stages of the existing SDLC.
The solution is not to remove central security from the process, but to change its role: from directly performing much of the security work to building, supporting, and governing security capability across product teams.
Product teams need capability, not just security support
For product teams to take more ownership of security, central security needs to help them build the practices and skills to handle more of the work themselves. This is a gradual process rather than a simple transfer of responsibility.
In our experience, it works best in stages. We typically start with five to ten priority projects. The security team assesses their maturity and performs a gap analysis: what is already in place, what is missing, and which practices and security artifacts need to be introduced.
Then comes training and hands-on support through the first several iterations. As teams become more mature, direct support decreases, established processes remain in place, and central security can move on to the next group of projects.
As teams become more self-sufficient, the support each product needs drops – so central security can keep pace by adding a new experts per batch of products rather than scaling with the whole portfolio. The goal is not to keep the central security team static, but to avoid a model where every increase in the number of products requires a proportional increase in security headcount. Direct support can then be concentrated on the teams and activities that need it most.
Bridging product and security teams
Security champions help maintain security capability within product teams as direct support from central security decreases. They are not members of the central security function, but people within individual product teams who take on security as an additional area of responsibility. They already know the product and its context and develop deeper knowledge of security practices, acting as local security advocates within their teams.
In practice, they help colleagues follow security requirements, support the introduction of new practices, and connect the team with central security when deeper expertise is needed. Champions also communicate with each other, exchanging experience and creating a support network across product teams.
The role can grow together with the team’s security maturity. At first, a champion may mainly help the team introduce and follow basic practices. Later, they can become more involved in reporting, process compliance, and more complex security metrics.
Every security risk needs a clear owner
A security risk does not always belong neatly to one product team. In matrix organizations, the same risk may affect several products or teams, making it difficult to determine who has both responsibility for the risk and the authority to address it.
Assigning an owner therefore means more than putting a name in a risk register. Someone needs to be able to drive the response plan, coordinate the teams involved, and escalate the issue when necessary.
A distributed security model also needs a common way to record, report, track, and escalate risks across products rather than leaving each team to manage them in isolation. The practical rule is simple: ownership should follow the ability to act. For risks that cross team or product boundaries, responsibility needs to sit with someone who has the authority to drive the response and escalate it when necessary.
Measuring whether the model works
The number of vulnerabilities found is an obvious metric, but on its own it says little about whether SSDLC is actually becoming more effective. More findings may reflect broader test coverage or better detection rather than a deterioration in security, while fewer findings do not necessarily mean that security has improved.
Dmytro Tereshchenko explores this question in more detail here.
A broader view should include the coverage of security processes and artifacts across products, the ability of teams to handle security activities independently, remediation time, and the reduction or avoidance of identified risks. Metrics can also be complemented by independent validation. An internal penetration testing team, where one exists, can help check whether established security practices are actually being followed and whether they are producing the expected results.
At scale, visibility across products matters just as much as individual metrics. Security leadership needs to see where the gaps remain, how teams are progressing, and whether the information needed to manage security risks reaches the right stakeholders in time.
Ultimately, a scalable SSDLC model is one in which security becomes part of how product teams work, rather than a separate activity performed for them, while central security retains the visibility and oversight needed across the organization.
