[debarshri]

Theres a third one, when it comes to compliance and security tools, you don't want to build it even if you can because.

1. It is a liability

2. There is trust deficit during audit and other events. If audits are internal only sure you can build it but when it is 3rd party audited, auditors often know the product and familiar with the features.

[chii]

> auditors often know the product and familiar with the features.

or what if you chose a dependency for which this auditor is unfamiliar with, and so it takes even longer (where as if you NIH, you'd have the full source and thus can give the auditors the materials to audit).

[zelphirkalt]

I am not sure most auditors work on that level of detail. If it is a library they don't consider audited yet, they might just call it a day and make a statement about your code excluding the dependencies they are not familiar with. Otherwise you would have to pay for all third party dependency audits, which no one else paid for yet or the auditor is not aware of someone else having audited already.

[debarshri]

You are right. Thats not the level they often go to.

[debarshri]

I have also seen this narrative. If things go south in the org. btw we were using product A for doing our workflows, that replaced if with product B for the same, now everything is going to better.