Choose a targeted scan when you need a prompt answer about a named workflow, change, exposure, or security claim. Choose a broader assessment when the decision depends on many application components or a defined set of security requirements. The distinction is the declared boundary and evidence completed, not how long a tool ran or how many alerts it produced. A targeted scan can finish cleanly while most of a repository remains unreviewed. A broader assessment can still be partial if required files, controls, tests, or deployment facts are missing.
First decide what you need to be able to say at the end. “Is the new export route protecting each customer's data?” is narrow. “Have we assessed the application's authentication, access control, data handling, configuration, and exposed APIs for this release?” is broader. Neither can honestly become “the product has no vulnerabilities.” OWASP SAMM's application risk profile helps prioritize applications using business impact and exposure; it does not turn a repository count into an assurance level.
Illustrative choice before a customer launch
Illustrative case, not a customer engagement: CedarDesk has a one-million-line monorepo holding its customer portal, export API, notification worker, admin service, shared permission library, deployment configuration, and generated clients. A new report-download feature ships in two weeks. The CTO has two concerns: a specific cross-customer report-access risk introduced by the feature, and an enterprise customer's request for an account of the application's security review.
One assessment label cannot satisfy both decisions automatically. The team can run a bounded review of the download path now and plan a broader, defined assessment for the customer assurance question. A scanner that indexes the whole monorepo while deeply examining only the download path has performed a targeted review with a broad inventory. Conversely, a broader plan is not complete because the dashboard says “100% jobs finished” if part of the source or requirement set was skipped.
Use the same comparison criteria for both options:
| Decision criterion | Targeted review of report download | Broader assessment of CedarDesk release |
|---|---|---|
| Question | Can an ordinary customer obtain another customer's report? | What controls across the declared application and selected standard were examined? |
| Boundary | Entry route, shared permission check, worker, storage access, deployed configuration | Defined services, shared controls, eligible source, external dependencies and operational evidence |
| Method | Source tracing, counterevidence review, specific authorized validation if needed | Planned source review plus methods required by scope, possibly configuration and controlled runtime checks |
| Coverage record | Exact components and ranges examined; other code explicitly outside scope | Complete eligible inventory and an outcome or explicit gap for every planned obligation |
| Useful output | Supported, rejected, or unresolved claim and next owner | Findings, control outcomes, coverage limits, residual questions and follow-up plan |
| Decision time | Timely for one launch risk | Longer, budgeted against a defined assurance need |
“Full” needs a noun after it. Full what: eligible repository source, an OWASP ASVS level for a defined web app, the public API surface, or a release's change set? The OWASP Application Security Verification Standard supplies versioned requirements and levels for application control verification. Choosing a level selects a requirement baseline. Applicability, scope and verification methods still need to be turned into a test plan; the level choice itself establishes neither the plan nor compliance. A source-only review cannot settle every requirement that depends on runtime configuration, organizational process, or observed behavior. The OWASP Code Review Guide is a method resource, not a certificate.
Make the target genuinely useful
For CedarDesk's launch question, the CTO asks the AppSec lead to write a one-page scope before spending review time:
Decision: approve, hold, or qualify the new report-download release. Actor: ordinary customer of account A. Proposed harm: retrieve account B's report. Path in scope: request entry, identity derivation, report ownership check, worker message, storage lookup, and any link or token returned. Version set: exact source commits, image digests, shared-library version, and active storage policy. Required output: source-supported conclusion, contrary evidence, missing facts, and owner for the next check. Outside scope: unrelated admin and notification functions, except where a shared control affects this path.
The review starts with those inputs. If it discovers that the report request enters through a second endpoint or the worker uses a different authorization path, the team updates the scope and reason. It does not quietly ignore the route because the initial plan missed it. If the storage policy is unavailable, the report says the final effect is unresolved. That is a useful launch input: the CTO can obtain the policy, postpone the decision, or authorize a controlled validation. It is not a clean pass.
The same targeted principle works after a fix. Pin the old finding and new revision, retrace the original path and affected alternate paths, and ask for positive evidence that the unsafe behavior is prevented. A merged pull request or absent alert is not enough if the path moved. This preserves a narrow but defensible answer rather than forcing a costly re-review of unrelated services.
Define a broader assessment as a contract
For the enterprise customer's question, the AppSec lead and CTO must agree on the object of assessment: which deployed application, environment, components, versions, security requirements and methods. The plan should list eligible source classes, such as application code, IaC, CI configuration, migrations and relevant generated code, and state exclusions with reasons. It should name dependencies and external services whose controls are relevant. It should also distinguish static source review from configuration inspection and controlled runtime assessment.
Then give every planned component or requirement an outcome: reviewed with evidence, blocked by missing context, partially reviewed, excluded by the agreed scope, or not yet started. If ASVS is used, pin its version and applicable level, and record each requirement's applicability and evidence for the named component. Do not use a single “ASVS passed” flag for a monorepo containing services with different responsibilities. NIST's SSDF frames secure development as repeatable practices across the lifecycle; a single broad scan is one source of evidence within that program.
Before declaring the source inventory complete, verify the retrieval process. A remote provider can cap a recursive listing; the GitHub Trees API exposes a truncated flag and recommends subtree traversal when it is true. Similar limits, inaccessible submodules, unsupported encodings, and resource ceilings need explicit statuses. Count source discovered, acquired, indexed, and actually examined separately. Indexing a million lines to enable search does not mean a reviewer reasoned about a million lines.
Compare two statements of work, then compare what was delivered
CedarDesk receives two fictional proposals. Both use the phrase “full scan,” so the CTO rewrites their acceptance clauses before selecting the work.
| Contract field | A: launch decision | B: broader release assessment |
|---|---|---|
| Object | Report download in release R8 | Portal, export API, worker, admin and shared controls in R8; notification delivery explicitly excluded initially. |
| Planned obligations | Admission, job/object binding, worker read, artifact publication, download entitlement and active deployment mapping | Versioned requirement/component ledger across the declared services; source, configuration and authorized runtime evidence where required. |
| Completion | A reasoned outcome for each of the six obligations, with evidence or a disclosed blocker | Every planned obligation has an outcome; unmet evidence requirements remain gaps, not passed cells. |
| Delivery | Release memo plus reproducible trace and scope receipt | Findings, requirement outcomes, complete source inventory/dispositions, methods and continuation plan. |
| Commercial change trigger | Another producer or delivery route materially changes the six obligations | A new service, changed requirement set or missing authorized method changes the agreed plan. |
These are editorial examples of workable acceptance language, not legal contract advice. A vendor's hour allocation is not an assurance promise by itself; the buyer needs to know what evidence the hours are meant to produce.
Now suppose A completes all six source/configuration obligations in the agreed synthetic case, with no supported cross-account download issue. It records a stored-job control and matching worker/storage bindings. B has inventoried the same monorepo and deeply reviewed authentication plus one admin path, but its worker authorization and operational evidence are unfinished. A is complete for its declared launch question. B is partial for its broader plan. Repository-wide indexing cannot reverse those descriptions.
The CTO can use A to support the bounded launch decision and can show the enterprise customer B's real progress with its gaps. The CTO cannot claim that A completes B merely because A finished first, or that B provides better evidence about download simply because it covers more folders in an index.
Decide which evidence transfers to the broader work
The six-obligation trace from A is useful in B if B records its source, configuration and deployment identities and checks that they still govern R8. It can satisfy overlapping planned obligations after that reconciliation. It is not six extra security findings or a second independent review. If the worker changes to R9 before B finishes, its worker and delivery conclusions need revalidation; the inventory and unchanged route observations may still be reusable.
The customer later asks about notification attachments, previously excluded from B. The lead adds the notification service, its recipient rule and delivery configuration to a new plan version. The denominator increases because the assurance question grew. Existing work has not been undone, and the old plan must not be edited to imply notification was always reviewed.
CedarDesk's decision memo becomes: “Accept A as the completed bounded release review for R8 report download. Continue B for the declared broader assurance need. Include A's evidence only where version and method match. Add notification delivery as a visible scope change requested by the customer.” That is a procurement decision a CTO can defend without buying an undefined promise to inspect every line.
Compare the remaining uncertainty before buying more work
After A finishes, CedarDesk should ask which unanswered decisions B will resolve. Authentication configuration, privileged administration and notification delivery may justify broader work because the customer relies on those paths. Repeating the completed download trace at the same version without a new method or changed evidence may add little. The procurement choice should make that expected additional evidence explicit.
A broader engagement can also be staged. Fund the highest-consequence unresolved obligations first, retain the complete plan, and report each completed slice against its own boundary. Staging the work does not reduce the eventual target; it makes progress and remaining uncertainty visible. If the customer needs the whole agreed scope before launch, that requirement remains a delivery constraint.
Use the completion record to distinguish a disappointing result from incomplete work. A thorough assessment may find serious failures and still meet its assessment contract. The remediation program is then the next task. Purchasing a larger scan is not a substitute for acting on the supported issues already found.
Communicate the result precisely
If the targeted review finds no supported issue, say which path, revisions, controls and methods were examined and list the remaining unknowns. Say “no issue was confirmed in this defined path during this review,” not “the monorepo is secure.” If a candidate remains unresolved, name the missing artifact and the next owner. If required assessment work is unfinished, call the assessment partial and explain the consequential gaps. A completed assessment can conclude that a control fails; that is a completed adverse result, not missing work. Declared exclusions limit the assessment boundary and must remain visible, but do not automatically make an otherwise completed agreed scope partial.
For CedarDesk, the next action is to attach A's bounded completion receipt to the R8 launch decision, then continue B against its versioned obligation ledger and added notification scope. Use the unfamiliar-codebase workflow to make the first review safe and the million-line evidence workflow to keep both assessments' scope visible.