// the cycle · six stages, in order
Bring in engineers at the stage you are actually at.
One security cycle, six stages, from a design that does not exist yet to a product in the field. Each stage says what it answers and what you buy there, so you can start at the one you are in.
The six stages, and what you buy at each
In order, with the question each stage answers and the limit you are buying into. Stage 4 is a loop rather than a step.
Concept and design review
Should we build it this way? The trust boundaries, the attacker positions, and the boot, update and key decisions, reviewed while changing them is still a document edit. It cannot find implementation bugs, because there is no implementation yet.
Design review →Implementation
Did we just write a bug? The detector runs over the build rather than over a release candidate, so a finding arrives while the author still remembers the function. It cannot see what you did not build: the vendor blob, the binary-only driver, the component you integrated.
Source code analysis →Firmware and secure-boot review
What is actually wrong with what we built? The boot chain, attestation, the update path, and the trust decisions your product makes before any of your code runs, on the shipped image rather than the source tree. It cannot promise that a clean result means safe: you get what was covered, at what depth, and what was not.
Firmware review →Adversary simulation
The chain proven end to end rather than the bug listed: what an attacker reaches, in what order, against the product you actually ship. Buy this instead of a review where the chain is the question. It cannot prove a path exists where the hardware seals the step we would need.
Adversary simulation →Remediate, and re-verify
Did the fix close it, and did it open anything? A fix is a change, and the test that found the bug is the only thing that can say the change worked. We re-run against the new drop and hand back the diff. It cannot be bought as a standing promise to answer; it is scoped per drop, inside the review engagement.
Part of the firmware review →Ship, with evidence
What can we put in front of a regulator or a customer's security questionnaire? A dated record of what was verified and what was not, per artifact. It cannot confer compliance: the technical file, the declaration and the CE mark stay yours.
Firmware and supply-chain evidence →Threat research
Is anyone coming for this? Who would, how they would come, and whether the path they would use reaches what you ship. Pointed at an adversary rather than at an incident that already happened. It cannot tell you nobody is interested; absence of a path we found is not absence of a path.
Threat research →Incident response and forensics
Is anyone already in? Scope, contain, reverse what got in, and hand back a timeline and indicators rather than a black box. Including the hard shape: an agent that acted in your name. It cannot tell you the adversary is gone; no engagement can say that and mean it.
Incident response →Stage 6 then feeds stage 1 of your next product, which is where the work starts paying back.
Agent Platform and Agent Threat Protection
A different axis from the six stages above: not securing a product you sell, but automating work you do and protecting the AI that does it. Both are in build, and the pages say which parts are and are not working.
Agent Platform
Which of your processes can an agent do, and how would you know it got it wrong? One process at a time, with the check written down rather than living in somebody's head, and a person reviewing the output. It cannot replace the judgment: the legal call, the clinical call, and the business rules stay with the people accountable for them.
Agent Platform →Agent Threat Protection
What can it reach, what can it spend, what happens when it goes wrong, and can it leak your information? An agent gets its own identity, its own limit and its own off switch rather than borrowing a person's. It cannot inspect a photograph, and it does not cover somebody signed into their own personal AI account.
Agent Threat Protection →If you are not at stage 1
Almost nobody is. Here is the honest entry point for where people actually are.
Send one image. What is in it, and what we could not open, before anyone commits to a plan. A design review of a frozen architecture is archaeology; a review of the artifact is actionable this quarter.
The question is what you can evidence about parts you did not build. That is identification from the shipped bytes, not a questionnaire, and it answers the auditor's row directly.
This is the one time the cheap fix is available, and the window closes at tape-out rather than at launch. The review also writes the test plan the later stages run.
Incident response, today, and the cycle question can wait until the incident is bounded. Scoping an incident badly in the first hour costs more than everything above.
How an engagement runs
The same four every time. The one that surprises people is the second.
A finding we cannot reproduce is labeled unconfirmed. A part we could not reach is named. Neither gets folded into a clean result.
Scoping
What we need to quote, and the shape this work comes in.
One release, one product, one artifact, one incident. Quoted up front, with the limits written into the scope rather than discovered during it.
To quote anything we need three things: what the artifact is, what you are afraid of, and when the answer has to exist. No procurement needed to start, and we will tell you if what you are asking for is not worth buying.