For a first security assessment, choose a bounded, named slice of a pinned repository revision that contains a meaningful trust boundary, its callers, the controls that are supposed to protect it, and the code or configuration needed to judge whether it runs. Record what you leave for a later pass. A scan of “the whole repository” is a poor scope statement if the tool reads only supported languages, skips large files, or cannot see deployed configuration. The answer changes when your immediate decision is narrower: a release blocker may call for a focused change review, while a baseline program needs an inventory and a schedule to cover the remaining components.
The first assessment should produce an actionable picture of one risk area and an honest list of unknowns. NIST's Secure Software Development Framework treats software security as practices across development, not a one-time scan result. OWASP's ASVS assessment guidance asks verifiers to state what was included, which requirements were checked, the method and the rationale for exclusions. Those are useful habits even when no formal ASVS assessment is being performed.
Choose the decision before the tool setting
Ask the sponsor which decision the first pass should support: “Can we ship this payment change?”, “Where should AppSec spend a week?”, or “What do we know about tenant separation?” The answer determines the slice, evidence and review depth. An AppSec lead owns the scope record; the service owner confirms entry points, deployment and controls.
Use these inputs before selecting paths in a scanner:
- An immutable commit or release artifact and the repository or repositories that produced it.
- A component map: public routes, background jobs, shared libraries, data stores, identities and deployment configuration.
- The business action and assets worth protecting: for example, “an ordinary account user must not read another account's invoices.”
- The languages and frameworks actually present, plus tool support and required configuration. A tool's parser list says what it can attempt; it is not proof of detection quality in this application.
- A time and review budget, including who can investigate ambiguous results and who can answer deployment questions.
If the repository inventory is incomplete, say so at the start. A first tree response, a truncated archive or a set of familiar top-level folders is not the whole source population. Make enumeration and source availability explicit work items before promising repository-wide coverage.
Worked decision: select a boundary, not a folder name
Illustrative case, with invented names and counts: Harbor Billing has one monorepo at commit B42D9. It contains an invoice API, a background PDF worker, a shared authorization library, a web frontend, migration files and generated client code. The AppSec lead has two reviewer days. The immediate question is whether one customer account can obtain another customer's invoice through download or export. A rule-only sweep of every file might produce leads, but it cannot answer that question without inspecting the route, shared control and delivery path together.
The lead proposes this first-pass scope:
| Candidate | Reason to include now | Decision |
|---|---|---|
| Invoice download and export entry points | User-controlled invoice IDs cross the customer boundary. | Review both routes and their direct callers. |
| Shared authorization library and account context | May enforce ownership outside the route. | Review relevant functions and actual call sites. |
| PDF worker and object delivery configuration | A route may hand off a job or signed download. | Trace only paths reached from download/export; inspect relevant deployment settings. |
| Invoice storage query and data model | Determines whether the account key constrains reads. | Include the query, ownership fields and permissions evidence. |
| Web frontend | Helps find user flows but cannot establish server authorization. | Inventory; inspect only where it changes request formation. |
| Generated client, unrelated marketing pages | No current evidence they enforce this boundary. | Record exclusion and revisit if a call path leads there. |
The selected slice is not “all invoice files.” It follows a user action across components. Folder names are hints; the actual call chain decides which files matter. OWASP's Code Review Guide, version 2 describes automated analysis as a complement to human review and identifies application logic and language or framework scope as scanner limitations. The guide is dated 2017; the scope decision here still needs current tool and application evidence.
The lead chooses two claims: (1) an ordinary user cannot download another account's invoice, and (2) an export job cannot bypass that rule. The method is source review at the pinned revision plus relevant deployment configuration, with a controlled runtime check separately planned if needed. This does not certify the service or demonstrate a live attack.
Check that the selected boundary is reviewable
Before Harbor spends its two reviewer days, the lead asks the service owner to assemble a compact boundary packet. It contains the invoice download and export entry points, the selected revision, the ownership rule, the shared authorization implementation and the identity of the deployed worker. The packet is an input to review, not evidence that the paths are safe. Its immediate purpose is to expose missing access before the reviewer discovers a decisive dependency halfway through the allotted time.
Ask for enough context to challenge the proposed scope. A route list supplied by one API owner may omit scheduled jobs or support tooling owned by another team. Harbor therefore asks the worker and storage owners whether any other path can produce or deliver the same invoice artifact. Their answers help locate review targets; they are not a substitute for inspecting the relevant calls. If an owner cannot provide a complete inventory, preserve that uncertainty in the planned scope rather than promoting the list to an exhaustive map.
A useful boundary card names the initiating actor, the object whose ownership matters, each service handoff, the final output and the control expected at each transition. For a direct download, the output is the PDF delivered to the requester. For export, intermediate processing and the final archive recipient may need separate questions. Sharing the word “invoice” does not make those flows interchangeable. A narrowed scope can choose one of them, provided the report does not silently extend its conclusion to the other.
Keep source acquisition separate from executing the application. Reading the shared authorization implementation may be necessary; installing its dependencies or running its hooks is a different operation with different consequences. Where generated code is decisive but unavailable, ask for a trusted, identified build artifact or state that gap. Do not silently build an unfamiliar repository just because the first chosen tool expects compilation. The scope record should identify both the permitted material and the permitted method.
Define a stopping condition that produces a useful result
For Harbor's direct-download question, completion means the reviewer can explain the account-to-invoice decision through delivery using the selected method, record the controls and limits, and name any supported finding. It does not mean finding at least one defect, reading every file with “invoice” in its name, or spending every minute of the budget. A well-supported rejection of the proposed cross-account path can be a complete result for that bounded question.
If a decisive external check remains unavailable when time runs out, finish with a precise partial result: the verified local edges, the missing component and the decision that cannot yet be supported. Preserve useful source concerns and any separately justified repair. This lets the sponsor choose a small follow-up that closes the actual gap. Repeating the entire local scan would consume the next budget without necessarily obtaining the missing document-service policy.
Make the time budget explicit, then spend it again when the path changes
For Harbor's two reviewer days, assume 16 working hours solely for illustration. The initial allocation is 2 hours for inventory/policy, 4 for direct download, 4 for export/worker, 2 for deployment controls, and 4 for adjudication and reporting. This is a scope budget, not a prediction of how quickly a real reviewer should work.
At hour 5, the download trace reaches a shared document service in another repository. The handler's apparent missing owner check may be enforced there. Reading more local invoice routes will not answer that question. The lead must change the scope, obtain the dependency, or leave the claim unresolved.
A concrete revised allocation is:
| Work | Initial hours | Revised hours | Consequence |
|---|---|---|---|
| Inventory and policy | 2 | 2 | Retained |
| Direct download | 4 | 4 | Includes established local trace |
| Export/worker | 4 | 2 | Entry/handoff only; final delivery remains partial |
| Shared document service | 0 | 3 | Read the deciding authorization and file selection |
| Deployment controls | 2 | 2 | Still required to map the boundary |
| Adjudication/report | 4 | 3 | Retained, with narrower outcomes |
| Total | 16 | 16 | No hidden extension of the promise |
The extra three hours are paid for by two export hours and one reporting hour. Calling the new service “just context” would conceal the cost and make the original completion promise false.
Resolve the fork with the sponsor
If the document-service owner provides the relevant source and policy within the review window, continue the direct-download claim and publish export as partial. If access is unavailable, the next output is not “download safe”; it is “local path traced, decisive downstream authorization unavailable.” The sponsor may fund an additional pass or keep the release feature disabled while the dependency is obtained.
If the service owner says the document service is out of scope, that limits the assessment, not the application's attack path. Where source access is unavailable, a current interface contract, policy evidence and a controlled check may answer a narrower question; name that different method rather than calling the external source reviewed. A boundary cannot be judged end to end while the component that decides it is excluded. The report can still be useful: it identifies exactly which question the access or scope restriction prevented the reviewer from answering.
The final synthetic scope note reads:
Completed: direct-download source trace including the newly supplied document-service owner check; selected deployment mapping reviewed. Partial: export entry and worker handoff read, final delivery not assessed. Deferred: unrelated routes, generated clients and frontend authorization presentation. Next pass: export owner supplies the delivery path and job delegation policy; AppSec reserves a separate review block.
This is stronger than a list of folders because it says what the reader may decide. The direct route can receive a bounded conclusion; export cannot inherit it merely because both use invoices.
OWASP's ASVS assessment guidance supports declaring scope, method and exclusions. The scheduling arithmetic above is illustrative. Do not copy its hour allocations into an estimate without inspecting your own dependencies, access delays and evidence quality.
When the planned slice fails
If a provider response is truncated or repository access changes mid-assessment, do not replace the unknown denominator with the files you happened to receive. Mark inventory incomplete and either recover it or narrow the stated unit to the files actually enumerated. If the call path reaches an unselected service, pause the verdict and expand scope or state the dependency as unknown. If the selected framework is not reliably parsed, switch to a declared manual or generic text review for the bounded claim; do not silently report the usual automated depth. If deployment configuration differs from source assumptions, rebind the claim to the actual artifact before making a production statement.
Start your next assessment with the actor-action-asset sentence and the decision record above. Then use the scan-coverage report template to tell stakeholders what actually happened. If the claim needs observed behavior from a running system, use the source-versus-runtime decision guide to request only the necessary check.