I've never seen that practice used. One of the costs of importing code is the need to review it. If you don't do that yourselves why would you bother reviewing it at all? It's an awfully expensive way to get a second opinion that's unlikely to be much higher quality than the suppliers one.
What I have done is tripwire the reviews. We keep fairly detailed notes and our rule is that after three rewrite issues we stop reviewing and send the whole steaming pile back where it came from. We've also done it once when we got to about 50 minor points, because we felt that they needed to go through and systematically fix a few patterns we didn't like (poor use of resources, essentially).
We also demand both unit and integration tests be supplied, and we generally start our reviews there. If they're not testing against our requirements, or the unit tests are not broad enough, we send it back.
All of which increases the cost of using third party code, and creates tension with management who want cheap code. It can make it look as though we're sabotaging the external suppliers. So we deal with that by demonstrating that we use a lot of external code anyway (we use lots of FOSS + external libraries)l and by black-boxing the occasional third party developer - we write the integration tests and accept whatever passes them. That is not quite as cheap but it works when you've got a sharp subsystem boundary.