Threat modeling is in the "best practices" Neverland between the necessary pillars of getting code to production (DevSecOps, the sneaky rebranding of the Dev-Op

Threat modeling is in the "best practices" Neverland between the necessary pillars of getting code to production (DevSecOps, the sneaky rebranding of the Dev-Ops conversation to include someone from Security) and satisfying auditors (re various compliance regimes, that are broken down to specific evidentiary controls, many of which are to attest to specific threat model principles like non-repudiation). Threat modeling can help indirectly with both getting code to production securely, and satisfying auditors, but it's neither necessary nor sufficient for either, so rarely makes sense for a company to practice themselves. Instead there may be an aspect of threat modeling carried out by a third party pentester, but mostly what that will do is raise the direct cost of the pentest and maybe lead to more expensive remediation costs as well. One can look at fuzzing- architectural as well as endpoint- as an actual automatable, codeable DevSecOpsy activity that is kind of distilled, operationalized threat modeling. Eg automatically build a fuzz plan from Terraform as well as as from OpenAPI schemas. It needs a clever name.