How do you build security into delivery?

Direct answer

What a strong answer covers

How it works

Security is built into delivery by making the secure path the easy path. Threat modelling happens at design for anything that touches new data or boundaries. Frameworks and internal libraries provide secure defaults for authentication, authorisation, output encoding, and data access, so developers do not implement them by hand. The pipeline runs static analysis, dependency and container scanning, secret detection, and infrastructure policy checks, tuned so findings are actionable. High-risk changes get a security review; the rest rely on the guardrails. Artifacts are signed, production is monitored for attacks, and findings from all of it feed back into the libraries and training so the same class of bug stops recurring.

Example

A team’s pipeline runs Semgrep with a curated ruleset, dependency scanning with a 7-day SLA on high findings, gitleaks on every commit, and a policy that blocks public storage buckets. A pull request that adds a new external integration is labelled high-risk and gets a threat model and a security reviewer. When two teams independently introduced SSRF bugs, the platform team shipped a safe URL fetcher library and a rule that flags raw fetches to user-supplied URLs.

Common mistakes

• Running a penetration test at the end and calling it secure development.
• Turning on every scanner rule so developers ignore thousands of findings.
• Fixing the same vulnerability class repeatedly instead of removing it at the library level.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.