> According to the model, the likelihood of a security defect being identified during code review declines with the increase in the number of directories/files involved in that change.

I think most of us who understand code reviews know about this problem and push back against it.

> Surprisingly, the likelihood of missing a vulnerability during code review increased with a developer’s reviewing experience.

Hold up. I need more information about 'experience'

> reviewer’s coding experience and reviewer’s reviewing experience,

still no criteria...

> Another threat is the measure we take to calculate the developer’s experience. We can interpret the term “experience”in many ways. And in many ways, measuring of experience will be complex. For example, we cannot calculate the amount of contribution of a developer to other projects. Although a different experience measure may produce different results,we believe our interpretation of experience is reasonable as that reflects the amount of familiarity with current project.

Wrong "experience" and still no criteria. If I may proceed from a notion that they mean the same class of experience even though they didn't define either of them until almost the conclusions, experience is here measured as time on Google projects.

New people are trying to establish themselves. Finding a bug is 'counting coup' and raises their status. They also bring in outside notions of good code reviews that may be more diverse or rich than those inside the group.

An 'experienced' reviewer may be suffering from any or all of the following:

* under-training (outside experience/echo chamber)

* over-training (confirmation bias)

* over-extension (too many reviews, competing priorities)

* lack of familiarity

* lack of motivation

* burnout

* hubris