Skip to content

Supply Chain & Resilience

Secure by design

What this is

Secure by design is the practice of building security into a system's architecture and development lifecycle rather than testing for it afterwards. It covers threat modelling at design time, secure defaults, dependency and software bill of materials management, and the pipeline controls that stop known-vulnerable code reaching production.

The problem

Everything found at penetration test was a decision made months earlier.

A penetration test at the end of a build finds real problems and finds them at the most expensive possible moment. The authorisation model that allows horizontal access, the service account with more permission than it needs, the tenancy boundary that leaks - each was a design decision made months before, cheap to change then and structural to change now.

The same is true of dependencies. A known-vulnerable library in production is rarely a patching failure; it is usually the absence of any mechanism that would have flagged it when it was introduced, plus the absence of an inventory that would answer 'are we affected?' in minutes rather than days.

Secure by design moves those decisions earlier and makes them cheap. A short threat modelling session at design time costs an hour and routinely removes findings that would have cost weeks. It is not a new discipline; it is doing an existing one at the point where changing your mind is still free.

Who this is for

  • Engineering teams whose penetration tests keep finding architectural issues rather than bugs.
  • Organisations selling to buyers who now ask for SBOMs and vulnerability disclosure processes.
  • Companies with a large dependency surface and no way to answer whether they are affected by a new CVE.
  • Suppliers to government, where secure-by-design expectations increasingly appear in contracts.
  • Teams whose security review is a gate at the end that everyone tries to avoid.

Delivery

How the engagement actually runs

Sprints inside your engineering cycle, with findings arriving continuously rather than a report arriving at the end. Durations are elapsed time for a typical scope, and get re-scoped against your estate before anything is committed.

  1. 011-2 weeks

    Assess the lifecycle

    Where security decisions currently get made, where findings currently come from, and what the last two penetration tests reveal about the pattern.

  2. 022 weeks

    Introduce threat modelling

    Run sessions with real upcoming work rather than training on an example, so teams learn on something they care about.

  3. 032 weeks

    Wire the pipeline

    Scanning, secret detection and SBOM generation in CI, with thresholds agreed so the gates are enforceable rather than routinely overridden.

  4. 042 weeks

    Embed and hand over

    Patterns documented, review checkpoint agreed, and the practice owned by engineering rather than by security.

Deliverables

What you actually receive

Artefacts your team owns and can maintain after the engagement, not a report that ages the moment it lands.

Deliverables for Secure by design, with what each one contains and when it lands
DeliverableWhat it containsWhen
Threat modelling practiceA lightweight, repeatable session your teams run at design time - trust boundaries, what an attacker wants, what stops them - sized in hours, not days.Week 2-3
Secure defaults and patternsReference patterns for authentication, authorisation, tenancy isolation, secrets and logging, so the secure path is also the easy path.Week 4
SBOM generation and consumptionBills of materials produced in the pipeline and, more importantly, ingested somewhere queryable - a generated SBOM nobody can search answers nothing.Week 5
Pipeline security gatesDependency scanning, secret detection and policy checks in CI with agreed thresholds, tuned so the signal is actionable rather than ignored.Week 5-6
Vulnerability disclosure processA published route for researchers to report issues, and an internal process to triage and respond - increasingly a procurement question.Week 6
Design review checkpointA proportionate review gate for changes that warrant one, inside the existing process rather than beside it.Week 6

Frameworks this touches

FAQ

Questions people actually ask

What is an SBOM and why does it matter?

A software bill of materials is a machine-readable inventory of every component in a piece of software, including transitive dependencies, usually in SPDX or CycloneDX format. Its value is in the question it answers quickly: when a vulnerability is disclosed in a widely used library, an organisation with queryable SBOMs knows within minutes which of its systems are affected, while an organisation without them spends days finding out.

Is generating an SBOM enough?

No, and this is the most common failure. Generating SBOMs in the pipeline and storing them as build artefacts nobody can search produces compliance without capability. The value comes from ingesting them into something queryable and connecting that to vulnerability feeds, so a newly disclosed CVE produces a list of affected systems automatically rather than a manual investigation.

How do we do threat modelling without slowing delivery down?

Keep it short, keep it visual, and trigger it by change rather than by schedule. A one-hour session on a whiteboard covering what is being built, where the trust boundaries are, what an attacker would want and what stops them catches most architectural issues. Formal methodologies with extensive documentation are thorough and are also why most threat modelling programmes quietly stop after four months.

Should pipeline security gates block builds?

Selectively. Blocking on critical vulnerabilities in production dependencies and on detected secrets is defensible and usually accepted. Blocking on everything produces a gate that teams route around or disable, which is worse than no gate. The workable pattern is blocking on a narrow, high-confidence set, reporting on the rest, and tightening the threshold over time as the noise is tuned out.

More in Supply Chain & Resilience

Start

Three ways in, depending on how close the deadline is.

Or just email a human: hello@cloudgap.ai

We reply within24 hours