How We Embed Security into Every Line of Code

Threat modelling before the first line of code

Before implementation we work through four questions with the people who understand the domain: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job. It does not require a formal methodology to be useful. A whiteboard, a data-flow sketch and an hour with the engineers and somebody from the business will surface most of what matters.

What it produces that a late penetration test cannot is a record of the risks that were considered and consciously accepted. The dangerous vulnerabilities are rarely the ones somebody weighed and accepted; they are the ones nobody thought about at all.

What runs automatically, and where

Automation is for the classes of problem a machine finds reliably and a human finds tedious. Each check runs at the point where it is cheapest to act on.

Static analysis, on every pull request

SAST reads source code for injection paths, unsafe deserialisation, path traversal and similar recognisable patterns. Its weakness is false positives, and the failure mode is social rather than technical: a tool that cries wolf gets ignored, then disabled. Tuning the ruleset until findings are believable matters more than enabling every rule available.

Dependency and supply-chain scanning

Most code in a modern application was written by somebody else. SCA tooling compares the dependency tree against known-vulnerability databases, and generating a software bill of materials means that when the next widely-exploited library issue lands, answering "are we affected?" takes minutes rather than a week of grepping. Transitive dependencies are where this earns its keep — the risky package is usually one nobody chose directly.

Secret scanning

Credentials committed to a repository are among the most reliably exploited weaknesses in real breaches, because they need no exploitation at all. Scanning runs pre-commit and in CI, and the important half of the response is the part people skip: a secret that reached version control must be rotated, not merely deleted. Git history keeps it, and so does every clone taken before the deletion.

Dynamic testing against a running build

DAST exercises the deployed application and catches what source analysis cannot see — misconfigured headers, authentication and session handling, and the behaviour of the stack as assembled rather than as written.

Secrets belong in a manager, not in a file

Configuration separates from code, secrets are injected at runtime from a managed store, and no credential is written into a client bundle — anything shipped to a browser is public by definition, regardless of how it is obfuscated. Where a third-party API must be called with a key, the call belongs behind a server-side endpoint that holds the key and enforces its own rate limiting, so the credential is never distributed to users at all.

This is the discipline that most often slips, and it slips on real projects under real deadlines rather than in principle. Treating secret hygiene as something to be audited and corrected periodically, rather than assumed, is the honest position.

What automation will not find

No scanner finds broken access control, which is consistently among the most prevalent classes of web application weakness and is almost entirely a logic problem. Whether a user should be able to read a given record is a question about the domain, not about the code, and a tool has no way to know the intended answer. The same applies to business-logic flaws: a workflow that lets a discount be applied twice is functioning exactly as written.

These are found by people who understand the system, in code review and design discussion. Automation exists to clear the mechanical findings out of the way so that review attention is available for the problems that need judgement.