With a fixed scan or analyst budget, prioritize security questions and complete paths, not the first N files or the largest folders. First reserve enough time to inventory the repository, verify promising claims and report unfinished scope. Then rank deployable paths by exposed action, data value, trust-boundary change, recent modification, shared-control reach and known weak evidence. Review the smallest complete slice that can answer the top question, including its callers and protective controls.
The order changes for a release gate, an incident or a known open finding. A changed authentication library can outrank an unchanged public page; a public route can outrank a large internal test folder. A budget-limited pass should end with a targeted assessment and an explicit queue of deferred work. It cannot honestly become “the monorepo passed.” OWASP's secure code review guidance recommends identifying critical assets and high-risk functions before both baseline and change-focused reviews.
Define the budget in work, not vague credits
Write down the actual constraint: analyst hours, tool spend, model tokens, deadline, retrieval limits or CI wait time. These limits affect different stages. Cheap tree enumeration can still fail on a truncated provider response. A deep investigation can consume most of a model budget while reading only a few files. Verification of one candidate can require an additional service and deployment owner. Do not spend the entire allocation on discovery and leave no time to judge what it found. If the limit is money or tokens, reserve the remaining cost of the next bounded call before starting it and record actual usage separately from the estimate. Six analyst hours and a model-token ceiling are different constraints; one cannot stand in for the other.
A practical reservation for a first targeted pass is an editorial planning choice, not a universal formula: allocate a portion to inventory and path mapping, a larger portion to the top paths, and a protected portion to counterevidence, independent review and a scope receipt. Reassign unused capacity only within the declared objective. If the budget is exhausted before a required path is checked, the outcome is partial. A new budget should create a named continuation with its own snapshot and scope, rather than relabel old work as complete.
The input to the plan is a pinned revision and a component inventory. The output is an ordered list of questions such as “Can a member read another account's report?” The unit of work is a path from entry to protected action and output, not a file count. OWASP's attack surface analysis guidance centers exposed functions and their guarding controls, which makes a better first filter than lines of code.
Use a small, explainable ordering rule
Give each candidate path a short evidence note under six headings:
- Harm: Which customer data, money movement, privilege or service availability could be affected?
- Entry: Who could reach the action, and what do we know about the deployed route?
- Boundary: Does the path cross user, tenant, service or trust zones?
- Change: Was this path or a shared control recently modified, or is it tied to an incident or open finding?
- Reuse: How many important paths rely on the same middleware, library or data accessor?
- Unknowns and effort: Which missing facts might change the order, and how much work is needed to answer the question?
Rank into review now, review next and record/defer. A simple tier with written reasons is easier to challenge than a precise-looking score whose inputs are guesses. Exposure and impact are not proof of a vulnerability; they justify where to spend review time. If a route is believed internal but deployment evidence is missing, keep it high enough to resolve that fact. Do not set exposure to zero from a folder name.
Illustrative case: six hours for a billing release
Illustrative case. HarborDesk, a fictional B2B SaaS product, has one monorepo with a public API, a billing export worker, an admin console, a shared authorization package, a marketing app, generated clients and tests. The AppSec lead has six review hours before a billing release. The numbers and outcomes below are invented planning inputs; no real scan or exploit took place.
The lead reserves one hour for inventory and deployment mapping, three hours for the highest-ranked path, one hour for independent counterevidence and owner questions, and one hour for the receipt and next queue. The highest question is: Can a user from tenant A export tenant B's invoice through the new retry route? The selected slice includes the retry entry, session check, object lookup, queue producer, worker and download. The shared authorization package matters because both the ordinary and retry routes call it.
| Candidate | Evidence before deep review | Decision and reason |
|---|---|---|
| Billing retry → export → download | New route, customer financial data, tenant boundary, shared worker | Review now. It is the release decision and the path can be bounded. |
| Shared authorization package consumers | Changed policy helper used by billing and admin | Review now for selected callers; review next for remaining consumers. Large potential radius, but not all callers fit this pass. |
| Admin console bulk action | High privilege; handler unchanged but consumes the changed helper; deployment access uncertain | Review next. Ask platform to confirm exposure now; raise order if it is externally reachable. |
| Marketing app | Public but no account-owned data in the known path | Record/defer. Reconsider if inventory reveals a payment or authentication integration. |
| Generated API client | Produced from schema; not independently deployed as a server | Inventory; inspect schema and security-relevant template. Do not assume all generated behavior is harmless. |
At hour three, the best use of the next hour changes
The first hour establishes the inventory. Two hours of the planned three-hour deep dive then follow the retry message into the worker. The producer accepts a replacement invoice, but the worker ignores it: the worker reloads the authorized job and selects the invoice recorded there. The scoped accessor also compares the invoice's owner to the job's account. For that pinned source path, the dramatic replacement-ID lead is defeated. Platform supplies a matching worker artifact record in the fictional case.
At the same checkpoint, platform answers the admin question. The bulk-action route is externally reachable by authenticated administrators, and this release changes the account-selection helper it uses. “Externally reachable” does not make it vulnerable. It does make a previously uncertain, high-authority consumer worth the remaining deep-review hour.
The revised allocation must still total six hours:
| Time | Work | What it buys |
|---|---|---|
| Hour 1, spent | Inventory and deployment map | Bounded callers and named external evidence. |
| Hours 2–3, spent | Retry path through worker and scoped accessor | Counterevidence defeats the proposed replacement-ID mechanism. |
| Hour 4, reassigned | Changed helper at admin bulk-action caller | Trace selected account through authorization and mutation; broader admin review stays out of scope. |
| Hour 5, protected | Challenge both conclusions and resolve owner questions | Check that worker defense governs the matched artifact; check admin contrary evidence. |
| Hour 6, protected | Decision receipt and continuation | Preserve what was concluded and exactly what remains. |
The lead does not add an extra admin hour while retaining the original three-hour deep dive; that would silently turn six hours into seven. Nor does the team spend the reserved counterevidence hour searching more files.
In hour four, the fictional admin source shows the caller omits the requested account when invoking the changed helper. The resulting fallback selects a different membership, and a later action uses it. The product owner has not supplied the intended delegation rule. Hour five confirms the sequence but cannot supply that business rule. The result is an account-selection concern requiring a product decision, not a verified cross-tenant vulnerability.
The release note becomes: “Retry replacement-ID claim rejected for matched worker path. Changed admin account selection remains unresolved; owner must specify allowed delegation and the release owner must decide whether to hold that change. Other admin functions were not reviewed.” The second question earned attention because evidence changed its relevance; neither the alert severity nor the folder size decided it.
Keep coverage states separate
The receipt should report at least four different things: files discovered, eligible files acquired, source actually examined for a question, and controls or obligations reviewed. A file in an index is searchable; it is not necessarily examined. A selected requirement from OWASP ASVS can help define the control question, but “reviewed for this billing path” is not an application-wide ASVS pass.
Use a row for every planned question:
| Question | Planned scope | Evidence at stop | State | Continuation |
|---|---|---|---|---|
| Cross-tenant billing retry | Replacement-ID path through worker/accessor | Stored job selects invoice; matching worker artifact supplied | Claim rejected for this mechanism | Separate delivery/freshness questions remain outside this conclusion. |
| Shared auth package on admin action | Changed account selection at bulk action | Wrong selection sequence examined; intended delegation rule missing | Reviewed, inconclusive | Product owner supplies rule; assess caller correction before release. |
| Marketing app account access | Inventory only | No account route identified in current inventory | Excluded by this release scope | Revisit on app release or new evidence. |
State the work: two bounded source questions were examined, one proposed mechanism was rejected, and one behavior remains unresolved. The marketing entry was a declared deferral, not a failed review. No percentage of these three rows measures security. If enumeration is incomplete, say so separately. A tool may also skip paths because of configuration. GitHub's code scanning workflow reference explains that analysis path filters differ from path filters that merely trigger a workflow. Confirm both before treating an unreported file as reviewed.
Carry a bounded continuation forward
At the stop point, save the next question with the evidence already obtained and the specific fact still missing. HarborDesk's continuation should begin with the admin delegation rule and changed caller, not repeat the inventory hour. Reuse earlier observations only after checking their revision binding; a new release may change the helper or route.
Give the continuation its own limit and completion condition. “Resolve account selection for the bulk action” can finish with a supported rule, a concrete defect or an explicit remaining blocker. “Continue scanning the monorepo” has no comparable stopping point and makes it difficult to know whether additional spend improved the release decision.
Reorder when evidence changes
The queue is a hypothesis about where attention will pay off. Reorder when a platform owner confirms external reachability, a new incident points to another path, a shared library has more consumers than expected, or a claimed control is contradicted. Keep the original and revised reason in the receipt. This avoids a retrospective story that the chosen slice was always the only relevant one.
Do not let a severe scanner alert consume the whole budget without verifying the path, nor bury a low-scored finding whose business effect is large. Distinguish technical severity, practical exploitation prerequisites, evidence confidence, remediation effort and stakeholder priority. NIST's Secure Software Development Framework frames secure development as risk-managed practices across the lifecycle; a single tool result is only one input to that process.
The useful endpoint of a small-budget review is a decision with limits: “We checked this path at this revision, observed these controls, left these questions open and will examine this next.” The leadership reader gets a short release consequence; the developer gets the exact code and object rule to inspect; the security engineer retains the technical evidence and counterevidence. If source is untrusted, review it as data—do not execute repository code or install dependencies merely to make the review appear complete.
Next step: List five candidate security questions for your next review window and rank them with the six headings above. Use the monorepo scoping guide to define a complete path, then the shared middleware guide when one changed package affects several candidates.