Where the audit actually starts

People like to begin an application security audit with a tool that makes a noise. Noise is comforting. It looks like progress on a shared screen. It is also how you spend two days confirming that a marketing site still has an old jQuery, while the broker upload on hostname-two goes unmentioned.

We start with a ledger. Not a CMDB novel — a grid you can hold in a sitting. Each row is a surface: a page family, an API prefix, a job, a webhook, a mobile endpoint, an admin corner, a file import. Each row has an owner guess, an auth guess, and a “last seen” date that is allowed to be embarrassing.

The sitemap the marketing team maintains is a rumour about the public pages. DNS is a rumour about names that still resolve. The product roadmap is a rumour about what will exist next quarter. None of those documents is the application. The application is the set of things that still answer.

In the Studio we spend the first week making this grid ugly on purpose. Learners add the forgotten password-reset mailer, then the “legacy” SOAP path a partner still hits, then the CSV drop that finance insisted on in 2019. If a later finding cannot be placed on that grid, we treat it as a scoping failure, not a trophy.

Scanners still have a job. They run after you can point to the rows they are allowed to touch. Until then, they are a very expensive way of not looking at the callback.

If you want the template we use, it ships with Ground Brief and with the Cockpit Seat. It is a spreadsheet. We have not made it an app. That is not an accident.