A product company building software for the education sector had reached the point where security could no longer be an afterthought. Their customers were starting to ask harder questions, and their own engineers had an uneasy sense that vulnerabilities were slipping through, not because anyone was careless, but because security checks happened, if at all, right at the end. A late security pass before release is the worst of both worlds: it finds problems when they are most expensive to fix, and it slows the release everyone is waiting on.
What they wanted was not a gate that engineers would resent and route around. They wanted security to be part of how they already work, close to the code, where catching something is cheap and fixing it is routine.
The challenges we had to solve
- Security review sat at the very end of the process, so it found issues late, irritated everyone, and missed plenty in the rush to ship.
- Nobody had a clear view of the open-source dependencies the product pulled in, or whether any carried known, already-fixed vulnerabilities.
- Credentials had a habit of ending up in code, where a single careless commit can quietly become a real exposure.
- Design decisions were made with no structured thought about what could go wrong, so the same classes of mistake recurred.
How we approached it
We moved the checks to where the work happens. Dependency scanning and secrets detection went into the pipeline so that a known-vulnerable library or a committed credential is caught before it merges, not discovered weeks later. We added lightweight code analysis on the same path, tuned to keep the noise down, because a tool that cries wolf gets switched off. The aim was fast, quiet feedback that fits the rhythm engineers already have, rather than a heavy gate at the end.
Alongside the tooling, we brought in a habit of thinking about what could go wrong at design time, kept deliberately simple so it actually gets done, and gave the team secure defaults and templates so the easy way to build something is also a reasonably safe way. We were careful to size all of this to a product team that still has to ship; the point was to fold security into their work, not to stand a separate process beside it. The security of what they build is theirs to own, and our job was to make owning it part of the day rather than an event.
Where it stands
Security now mostly happens where the code is written, which means problems are found early and fixed cheaply, and the late scramble before release has largely gone. Vulnerable dependencies surface as they appear, secrets get caught before they spread, and the team designs with a clearer sense of what they are protecting against. It became part of how they ship rather than a tax on shipping.