And let's not forget about the usual non-IT applications of "third party vulnerability law": e.g. child - school - knowledge, citizen - politician - government, or faith - church - god.

Hmm... complicated feelings about this. Like, I generally agree...but...

A thing I like to do when I look at a proposal like this is to imagine arguing for the alternative.

I'd sound ridiculous saying that we should increase the number of outside artifacts that we blindly trust. Arguing that more dependency = more good is never going to be how the opposite side couches stuff.

It's like saying "we should be more efficient". No one is going to argue that we should be less efficient, so the basic statement will just provoke a nod of agreement, and no further action.

To cook with gas on this one, it isn't sufficient to say that we must remove TTP whenever possible, you must be ready and able to combat the arguments for bringing them in. No one ever takes the "pure" opposition tack to this principle. They aren't like "We need to bring in extra software for the fuck of it." There is always a reason that our software must match with X software.

"We can't possibly reach our deadline if we have to solve the payment problem, let's just have our system accept Paypal." is the kind of thing you have to fight with. Evoking greater security is all well and good, but I've got a few decades in the field, and if I'm betting on a horse race between "Our app will be more secure", vs "Our app will be behind schedule", then I know where to place my money. If the app fails to launch, people might get sacked, bonuses might not be paid. If it launches and someone exploits the security hole, then those people are now more crucial than ever in terms of fixing it.

TTP each come with a reason that you should trust them. A generalized rebuttal isn't sufficient. You need a specific response for each of them.

Moreoever...security is a sword with no handle. Like, it doesn't seem that way at first. You speak up in the meeting in the name of security, and your argument carries the day. No one can be against SECURITY. But, if you keep doing this...you find that you aren't in the meetings anymore.

SECURITY, DIVERSITY, other sacred values that no one is allowed to argue against...these are beautiful swords to hang on the wall. But in order to operate no one must wield them. Imagine someone saying that all strings must be stored in pig latin because of SECURITY. Everything grinds to a halt. No one can agree with such an idiotic proposal, but to argue against it is to let the terrorists win. Seem farfetched? My company uses a program to obfuscate the javascript library that we provide to our users. It changes variable names, removes formatting, etc. This is exactly as useful as the pig latin idea, and has cost us millions.

I've wandered afield. I guess I'll sum up by saying that while I share the link's general thesis (Things are more secure the less stuff built by outsiders you let inside), I think that using this link to argue with would be counterproductive. I believe you must consider each TPP on a case by case basis, finding their flaws or strengths before you make your decisions. I mostly agree that your default value should be set to "reject", but the exercise of determining what the reason should be is rarely wasted.