Debian freezes the package versions on release of each Debian version and then cherry picks critical fixes for the rest of the Debian version's lifecycle. So even if they never review the code (and I don't expect them to), they're less likely to release malware before it's discovered by others.
You get a lower risk of them pulling in a bleeding edge vulnerability, but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue (or introduce more issues based on how they diverge from upstream).
There's no silver bullets here.
That model is getting increasingly difficult and labor intensive, unfortunately. More and more upstream are abandoning the old school security advisories. Not many are isolating CVEs or security fixes into distinct patches, the fixes come with a version bump and often accompany new features or other bug fixes.
There's also plenty projects that silently fix security bugs without issuing a CVE or even labelling them. So now the maintainer of that packages has to monitor the commit logs, figure out if a particular bug fix has security implications and then backport it to the older version which is becoming harder and harder over time.
Unless you have a massive team or a big enough army of volunteers, the LTS model is becoming less and less viable over time, you are often safer on rolling release or close to it (something like Fedora's pace is good).