Your team lead has booked an hour called threat modelling for the new file upload feature. There is a diagram on the screen, boxes and arrows, and a security engineer you have never met is asking the room what could go wrong. Other people are mentioning things you half recognise. You sit there with your camera on, trying to look thoughtful, and say nothing for fifty minutes.

You are not alone in that. Most developers are never taught this, and the first session can feel like everyone else got a manual you did not. The good news is that the core of it is simple, and you can learn it quickly.

Start with four questions, because almost every approach comes back to them. What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job? That is the whole shape of it. Everything else is a way of answering those questions more thoroughly.

Then learn to read the diagram, because it is where the answers hide. Follow the data. Where does it come from, where does it go, and who can touch it on the way? Pay special attention to the places where data crosses from one level of trust to another, such as from a user's browser to your server, or from your service to someone else's. Those lines are where most of the interesting problems live.

Next, borrow a checklist so you are not relying on inspiration. One of the most widely used is called STRIDE. It asks whether someone could pretend to be someone else, change data they should not, deny they did something, see information they should not, stop the system working, or gain more power than they should have. Walk each arrow on the diagram through those six ideas and you will have something to say.

Bring what you already know. You probably know the upload feature better than the security engineer does. Questions like what happens if the file is huge, what if the name is strange, what if someone uploads the same file a thousand times, are exactly the contributions the session needs. You do not need the correct vocabulary to ask a good question.

Then practise on your own work. Before your next feature, spend twenty minutes drawing a rough diagram and going through the four questions on your own. Show it to someone who has done more of this and ask what you missed. The gaps they find are your reading list.

And next time the session comes round, aim to say one thing. A question is enough. That is how everyone who now seems fluent started.

– Asael Shinder