Threat modeling will lead you to categories of issues that other tools will not find.
Some of these issues will be errors of omission, such as a failure to authenticate a connection. That is not something that a code analysis tool will find.
Other issues will be unique to your design. To the extent that you have a set of smart developers building something new, you might have new ways threats can manifest. Models of what goes wrong, by abstracting away details, will help you see analogies and similarities to problems that have been discovered in other systems. A corollary of this is that threat modeling should not focus on issues that your other safety and security engineering is likely to fi nd (except insofar as finding them early lets you avoid re-engineering).
So if, for example, you are building a product with a database, threat modeling might touch quickly on SQL injection attacks, and the variety of trust boundaries that might be injectable. However, you may know that you will encounter those. Your threat modeling should focus on issues that other techniques cannot find.
Spoofing: Someone might pretend to be another customer, so you will need a way to authenticate users. Someone might also pretend to be your website,
so you should ensure that you have an SSL certificate and that you use a single domain for all your pages (to help that subset of customers who read URLs to see if they are in the right place).
Someone might also place a deep link to one of your pages, such as logout.html or placeorder.aspx. You should be checking the Referrer field before taking action. That is not a complete solution to what are called CSRF (Cross Site Request Forgery) attacks, but it is a start.