The first Pentrova scan sets the tone for the rollout. Pick a target that is small enough to finish quickly, representative enough to be credible, and owned by someone who will read the findings. This guide walks through the three decisions every team makes on day one — environment, application, scope — and what a strong first report should look like.
Decision one: pick the environment#
Start in staging, not production. Staging gives you every agent, including the ones that run destructive probes in safe mode, with zero risk of touching live data. Because Pentrova’s exploitation is read-dominant and runs under sandbox guardrails, staging lets you see the full catalog exercise the target without holding anything back.
If staging drifts from production, run a scoped production scan in safe mode later. But the first scan should be the full catalog against staging so you see what the platform can surface.
Decision two: pick the application#
Pick an application with clearly scoped responsibilities: one auth surface, one data domain, one ownership boundary. A well-scoped target produces an evidence bundle that maps cleanly to a ticket, an owner, and a fix PR.
Avoid monoliths and shared-service gateways for the first run. They produce findings that need too much context to resolve, which is the wrong shape for demonstrating value early. The goal of the first scan is a tight loop from finding to fix, and a focused application gives you that.
Decision three: pick the scope#
Start with the authenticated API. That is where the interesting bugs hide on most modern SaaS targets, it is the surface Pentrova is strongest at, and it is where the evidence is most useful to engineering. Two practical setup steps make the first run pay off:
- Configure at least two roles (admin and member) so the Authorization Matrix can run cross-role replay and surface BOLA.
- Supply an OpenAPI spec if you have one, so API Pentesting can walk the full endpoint catalog rather than discovering it from traffic alone.
What a good first report looks like#
A good first report is short. Three to five findings, each with a replayable PoC bundle, each mapped to a component and an owner. The goal on day one is not to surface every bug in the target — it is to surface enough evidence for the team to trust the platform.
That trust is what makes the rollout to the rest of the portfolio start from a baseline of deterministic proof rather than probability scores. Once the first team has replayed a bundle against a fix branch and watched the exploit fail, expanding coverage becomes an easy decision.
Key takeaways#
- Run the first scan against staging with the full catalog; defer production to a later, scoped run.
- Choose a tightly-scoped application — one auth surface, one data domain — not a monolith.
- Start with the authenticated API, configure two roles, and supply an OpenAPI spec.
- Aim for a short first report: a few replayable findings mapped to owners, not exhaustive coverage.
FAQ#
Should my first scan run against production? No. Start in staging so the full catalog runs without any risk to live data. Once you trust the output, add scoped, conservative production runs.
How many roles should I configure for the first run? At least two — admin and member — so cross-role replay can surface broken object-level authorization. Multi-tenant apps should add a second tenant.
What if I don’t have an OpenAPI spec? Pentrova can discover endpoints from traffic, but a spec lets API Pentesting walk the full catalog and improves coverage. Generating one for the target API is worth the effort before the first run.
Ready to scope your first run? Start free or read the getting-started docs.