A more technical founder asked me this a while back, and it's a fair question to actually take seriously: "I've got automated tests and strict type-checking set up in my pipeline, doesn't that already cover security?" Both practices are genuinely good engineering discipline. Neither one is built to answer the question security testing answers.
What type-checking actually verifies
Type-checking confirms that the shapes of data flowing through your code match what your code expects: a function expecting a number doesn't accidentally get handed a string, an object has the fields your code assumes it has. That's real, valuable protection against a whole category of bugs. It says nothing about whether a logged-in user can reach another user's data by changing an ID, since that code is often perfectly type-correct while still missing the actual ownership check.
What automated tests actually verify
Tests confirm that the specific scenarios you wrote tests for behave the way you expect. If nobody wrote a test for "what happens when a logged-in user tries to access someone else's record," the test suite passing tells you nothing about that scenario, because it was never asked. Tests are only as good as the questions someone thought to ask them, and most security gaps are exactly the question nobody thought to ask.
Why this distinction matters practically
A pipeline can be green across the board, every type check passing, every test passing, and still ship with a wide-open database or a missing authorization check, because neither tool was ever pointed at that specific question. A clean pipeline is a real, positive signal about code quality. It isn't the same signal as "this has been checked for who can access what."
What I'd actually suggest
Keep the tests and the type-checking, they're genuinely worth having and catch real problems in their own lane. Treat a security check as a separate, additional pass, specifically aimed at the questions those other tools were never designed to ask: who can reach this, and should they be able to. Good engineering discipline and security testing solve adjacent problems, not the same one.