PRC model aims to reshape software security compliance

Application security researchers and practitioners have introduced a Product Risk and Compliance model for software vendors as an alternative to traditional governance, risk and compliance practices.

Known as PRC, the model is framed as an engineering-led approach to software security and compliance that focuses on product development rather than broader corporate controls. Its backers say it is designed to reflect how modern software teams build and ship code, particularly in continuous integration and continuous delivery environments.

The work draws on more than 25 interviews with application security programme managers, academic research teams, and members of the OWASP SAMM benchmark community. It was led by Dr. Dag Flachet, Co-Founder of Codific and an OWASP contributor. His research argues that the gap between formal policy and day-to-day software practice is driven by organisational behaviour as much as by technical design.

Supporters argue that older GRC systems were built for static assets such as end-user devices, office estates, and broad legal policies, rather than software products that change constantly through updates, code revisions, and new dependencies. They contend that this mismatch creates friction when compliance teams rely on manual records and spreadsheets while engineering teams work through automated development pipelines.

According to the research, that tension can lead developers to work around security processes if they see them as administrative burdens rather than part of the software development lifecycle. PRC is intended to shift responsibility for product risk to engineering and application security teams, embedding security controls into development work instead of handling them mainly through audit exercises.

Three pillars

The framework rests on three main elements: product risk assessment through threat modelling, supply chain risk management, and process risk management through maturity models. In practice, this means focusing on system architecture and trust boundaries before code is written, maintaining visibility over open source components and third-party services, and using structured benchmarks to measure how security practices are adopted over time.

Threat modelling is presented as a core part of the approach because it addresses design weaknesses that code scanners may miss. The supply chain strand distinguishes between open source dependencies and commercial third-party integrations, while also using software bills of materials to identify affected components when vulnerabilities emerge.

For process management, the framework points to OWASP SAMM and DSOMM as reference models. Rather than treating compliance as a pass-or-fail exercise, it uses those models to track maturity and guide security work within development teams.

Regulatory pressure

The model's emergence also reflects the impact of the EU Cyber Resilience Act on software suppliers. The legislation introduces reporting deadlines for actively exploited vulnerabilities and requires manufacturers to maintain technical documentation covering risk assessments and related security work across a product's lifecycle.

That regulatory shift has increased pressure on software vendors to show that security is built into product design and maintenance, rather than added later through policy documents. Supporters of PRC argue that engineering-led records, including living threat models and dependency data, are more useful for meeting those obligations than conventional GRC documentation designed for general corporate oversight.

The debate comes as software vendors face closer scrutiny over open source exposure, application architecture, and disclosure timelines. It also reflects a broader shift in application security towards evidence generated directly from development processes rather than controls documented separately from the codebase.

Dr. Flachet said the current model no longer reflects how software is produced or secured. "Software products are the lifeblood of modern business, yet we continue to manage their security as if they were corporate laptops on an IT checklist," said Dr. Dag Flachet, Co-Founder of Codific.

He said the problem is rooted in culture as well as tooling. "This is a behavioral failure as much as a technical one. PRC is a movement to bridge the gap between the boardroom and the engineering floor. The industry is moving away from reactive firefighting toward a proactive, maturity-driven culture where compliance is the friction-free byproduct of building resilient architecture," Flachet said.