Linux kernel doesn't do too badly with this intractable problem
The article is talking about two problems. (1) commits fixing security issues, which are intended to be silent at the time, are detectable from comparing Git versus mailing list traffic. (2) the lack of oversight by the wider public allows trusted (but perhaps not trustworthy) insiders to apply commits.
(1) It's hard to know how the first problem should be addressed; short of moving discussion of other commits off LKML, which seems undesirable.
(2) The second problem is simply a fact of life in any software development process -- "Reflections on Trusting Trust" territory.
The Linux kernel have done their best -- encouraging regular committers to use (freely supplied) Yubikeys to sign commits based upon a physical keypress. This goes a long way to inhibit a hacking of the computers used by major Linux kernel contributors resulting in a commit which was not authorised by the contributor. The identity of regular committers is known, and for most has been verified by the sighting of government-issued identity documents at GPG keysigning events at Linux conferences.
As for an untrustworthy committer, we need to be careful in our claims. There *is* oversight: (1) retrospectively; and if the issues are complex, then (2) at the time by other selected Linux developers in a non-public forum. There is not public oversight prior to the commit, and it is difficult to know how that could be done -- do we ask those willing to exploit the bug for evil to exclude themselves?. The claim reported by the article of "code commits made without review" doesn't fairly reflect the complex situation. We can be confident that an untrustworthy committer will be detected after the fact, simply because of the great public interest taken in these "silent" commits.
For the Meltdown/Spectre bugs the kernel developers did a good job of documenting the issue and the fixes. It's easy to retrospectively trace from those requirements to the historical commits. It's likely that this supply of very good documentation will be the practice for future complex security issues. It's the process for "simple" security fixes which needs focus to improve retrospective traceability from CVE to commit (this could be as simple as retrospectively tagging a commit with the CVE it fixes).
Finally, I'd note that the Linux kernel's processes are not inherently inferior to software processes which happen in private industry. There would be few industry development processes which could validate the integrity of the source repository back to SAK keypresses. There are no industry development processes which so many backups of the source code under the close control of so many people, allowing blatant subversions to be detected within hours. The Linux kernel addressing major bugs by using a small tight teams of people with need-to-know is no different to commercial practice.