2Atomic / Services / Design and architecture review

// engagement · stage 1 of 6 · before it is built

The cheapest bug to fix is the one still in a document.

We review the architecture before you build it: trust boundaries, the attacker positions, and the boot, update and key decisions you will not be able to take back. No product subscription required.

Scope a design review → See the whole cycle
Before the build, not after the ship
Decisions ranked by what they cost later
A test plan the later stages execute
Standalone, no platform license

Why this stage exists

Every other engagement we sell finds bugs in something already built. This one changes what gets built.

A review after the fact can tell you that your update path trusts its own payload. It cannot give you back the eighteen months in which that was a two-line change. The decisions that dominate a product's security are nearly all taken before anyone writes the code that implements them: where the key lives, who verifies what at boot, whether the thing that parses attacker bytes also holds the privilege, and whether any of it can be fixed in the field. We review those decisions while they are still decisions.

Design decisions, the attack each one admits, and what changing it costs once the product has shipped A document page listing architecture decisions taken at design time. Each row names the decision, the attack it admits if taken the wrong way, and what reversing it costs after the product ships, from a free document edit through a software update to a silicon respin or a field recall. DESIGN REVIEW What each decision costs after it ships DECISION WHAT IT ADMITS COST TO REVERSE Device key in external flash key recovery with a clip NEW SILICON One signing key, no rotation one leak ends the product line FIELD RECALL Recovery image not verified persistence across a reset BOOT REWRITE Parser runs before auth unauthenticated memory bugs REFACTOR One daemon, every privilege one bug reaches everything REFACTOR Debug port left enabled a shell on a bench AN UPDATE At this stage every row above costs a document edit. The column on the right is what the same change costs once the first unit ships, and it is the only argument that reliably moves a schedule.
Sample Design decisions, what each one admits, and what reversing it costs after the product ships The shape of the hand-back, redacted. Yours carries your own architecture.

What we need, and it is not a product

Documents are enough. If you have code, we will read it; if you do not, the review still runs.

Architecture
Diagrams, or a whiteboard session
Interfaces
What is exposed, and to whom
The boot plan
Who verifies what, in what order
The update plan
Signing, rollback, recovery
Key handling
Where each secret lives and dies
The constraints
Silicon, cost, schedule, the parts already chosen

Tell us the constraints as well as the design. A part you have already committed to changes what we can usefully recommend.

What we do

  • Draw the trust boundaries, and then say which of them your design actually enforces. The gap between the diagram everyone has and the boundaries the hardware and the code will really hold is where this engagement earns its fee.
  • Name the attacker positions. On the network, on the bus, on the bench with the device in hand, inside a compromised supplier, or holding a stolen signing key. A threat model with one attacker in it is a wish.
  • Walk the boot and the update path end to end, including the paths nobody draws: recovery, factory mode, field service, and the first boot of a unit that has never been provisioned.
  • Rank every finding by what it costs to change later, from a document edit today to new silicon after launch. This is the ordering that gets things fixed, and it is not the same ordering as severity.
  • Write the verification plan the later stages run. Each design assumption becomes a test somebody can execute: this is the bridge from a review to the code review, the simulation, and the evidence you will need at ship.

What you get back

Trust boundary map
Claimed against enforced
Threat model
Per attacker position
The decision list
Ranked by cost to reverse
Concrete changes
Specific, and inside your constraints
The verification plan
What the later stages must test
What we could not assess
Named, not omitted

Plus the session itself. Most of the value lands in the room with your architects arguing back, and the document is the written record of what was decided there.

What comes next

This is the first of six stages, and the plan this review writes is what the next ones execute.

Available

Where we come in

The whole cycle, stage by stage: what each one answers, what you buy, and what it cannot cover. Start here if you are not sure which stage you are in.

The six stages →
Available

Source code analysis

Stage 2, while you implement: the detector over every build you ship, with the file, line and variable named.

Source analysis →