Learn

Start here

Six tutorials, in the order you will hit them: install the thing, run a scan, understand what came back, then keep it running. Underneath, the reference for what each finding means. The docs are the full account of everything both of them skip.

Tutorials

Each one is a numbered path with the commands and the screens, and every step says what you should see before the next one makes sense. Do them in order the first time.

  1. 01 Run your first scan From an empty account to hosts landing in your asset graph. The one thing worth knowing before you start: Crossfyre does not scan from our infrastructure. You enrol a machine you control, and scans leave from your address. About 15 minutes, most of it waiting
  2. 02 Scan a web application end to end Four workflows against one application, in an order that matters. Each stage writes into the same asset graph, so the vulnerability scan tests endpoints that were actually found rather than paths it guessed at. About 30 minutes for a small application
  3. 03 Read your findings A scanner hands you a queue, and the work is deciding which few are worth an afternoon. Two numbers do most of that sorting, and they are answering different questions. 10 minutes
  4. 04 Scan behind a login Most of an application is behind a login, and an unauthenticated scan never sees any of it. This is the single change that most increases what a scan finds. 15 minutes, once per application
  5. 05 Test for broken access control The worst bugs in an API are usually one user reaching another user's data. A scanner logged in as one identity cannot see them, because the response is a perfectly healthy 200. 20 minutes
  6. 06 Keep a target monitored A scan is a photograph of a target on one afternoon. Most of what you want to know is what changed since, and that is a different thing to read. 10 minutes to set up, then nothing

Why these three and not everything

They are the exposures a stranger can confirm from the outside, without an account and without touching anything. That makes them the ones worth checking on a schedule, because anyone else can check them too, and the ones most likely to be introduced by a routine deploy rather than by an attack.