Choose the first assessment by application consequence and reviewable boundary, not repository size, commit count, or whichever scanner connects most easily. Start with an inventory of deployed applications and the repositories, shared libraries, configuration, and infrastructure that govern them. Ask what an attacker could reach, what data or action would matter, and what recent change or uncertainty makes a review useful now. Pick a small scope that includes the relevant controls and effects. Record why other candidates wait.
The order changes when there is an active incident, a known exploited dependency in a deployed service, or a major release moving a trust boundary. Those need an urgent decision. For ordinary planning, OWASP SAMM's Application Risk Profile recommends a simple, predefined set of business-impact questions and an application inventory. Its examples include internet exposure and the data processed. The profile is for comparing applications; a repository is only one source container for that application.
Start with applications, then map code
A single web application may depend on an API repository, an authorization package, deployment manifests, and a background worker. Conversely, a monorepo may hold services with different owners and consequences. “Scan repo A” is therefore too vague to be a security scope. Name the service or workflow, the trust boundary, and the revision first; then identify all material sources needed to answer the chosen question.
Build a small inventory from deployment records, service catalogues, code ownership files, architecture diagrams, and owner interviews. These sources can disagree. Mark unknowns rather than substituting a directory name for proof of deployment. For each application, capture:
| Question | Why it affects the first choice |
|---|---|
| Who can invoke it: public visitor, customer user, partner, or internal job? | Shows the likely attacker or mistaken actor, without assuming internet access from a route name. |
| What customer data, money movement, credentials, or availability does it control? | Describes the possible business consequence. |
| Which other services trust its outputs or share its authority? | A small shared library or job may govern several critical flows. |
| What changed recently or is about to launch? | A migration, new integration, or ownership change can alter an old risk profile. |
| Who can provide deployment and control facts? | Assessment quality depends on being able to resolve unknowns. |
Do not turn these questions into a fake precision score. A five-point scale with arbitrary weights can conceal a missing owner or unknown deployment. Use a qualitative high, medium, or lower comparison with a written reason. OWASP SAMM expressly allows a simple qualitative classification and says not to invent a new scheme when a working one exists.
Work a selection decision
Illustrative portfolio, not a customer assessment: AlderPay has six repositories and one AppSec lead who can review two bounded scopes this month. An engineering manager confirms the following application map, but the export worker's production schedule is still unknown.
| Candidate application or scope | Repositories needed to understand it | Consequence and access | Open fact | Initial choice |
|---|---|---|---|---|
| Customer invoice download | billing-api, auth-common, route configuration |
Customer users can request invoice PDFs; cross-account disclosure would affect customers | Whether the storage layer also enforces ownership | Assess first, with storage control in scope |
| Finance export worker | finance-jobs, auth-common, job policy |
Scheduled service reads many invoices; broad authority could amplify an error | Which schedule and credentials are live | Assess second after owner supplies run evidence |
| Marketing site | marketing-web |
Public content with no known invoice access | Confirm production form destinations | Keep inventoried; review on next material change |
| Component library | ui-kit |
Shared UI code; no direct invoice access in the current map | Whether authentication components moved here | Include only relevant shared calls if discovered |
The billing choice is about a specific cross-account read path, not a promise to inspect every line of billing-api. The export worker may move to first place if it is deployed with unrestricted invoice access and a broad schedule. auth-common is included in both reviews because a control there can defeat or enable the claim. Treating it as a separate low-priority repository would miss its effect on both applications.
The AppSec lead records the decision as a short assessment brief:
- Selected: Customer invoice download at immutable billing API and shared-library revisions.
- Question: Can an ordinary customer user retrieve an invoice owned by another account?
- Boundary: Request route, authentication and authorization middleware, invoice lookup, storage access check, response delivery, and production route mapping.
- Owner and evidence request: Billing owner supplies deployed route and storage policy; platform owner supplies the release manifest.
- Deferred: Finance export until its deployment and credential facts arrive; marketing site and unrelated UI components until a relevant change or revised profile.
- Limit: A review of this path does not establish that the entire billing application, the shared library, or all security requirements are safe.
That brief is reusable. Replace the company, path, actor, effect, and owner. The security lead now has a question that can be completed and contradicted, not merely a request for more scanner output.
Spend the second slot on the fact that could change the order
Two bounded assessments do not imply that every candidate is ready. To make the choice concrete, the sixth repository in AlderPay's inventory is partner-connect; route and job configuration live with their services. A new partner integration is ready for review, while the export worker remains hard to inspect. The integration owner offers a complete diagram and an eager engineer. Convenience now competes with uncertain exposure.
Before choosing the second assessment, the lead caps discovery at one hour and names a deliverable: deployed worker identity, schedule and producer map, or an explicit missing-artifact list. The hour is a decision checkpoint, not a promise that discovery will finish. This consumes time inside the month's existing capacity. If the required artifacts remain unavailable at the checkpoint, the lead uses the fallback decision below rather than letting discovery consume the entire review slot. Platform supplies the following fictional evidence packet:
| Artifact | What it says | Effect on selection |
|---|---|---|
Effective schedule S12 |
Worker runs each night in production | “Possibly retired” no longer justifies deferral |
Identity policy J8 |
Worker can read invoice records across accounts | A wrong job-account binding could have broad effect; this is not itself proof of a flaw |
Job producer map P4 |
Customer export requests and staff batch requests share the same worker | Review must distinguish the authority of the two producers |
| Partner release decision | Integration has not launched; owner can keep it disabled for one month | Its new exposure can be deferred while current worker behavior is examined |
The lead keeps billing first because its prepared review is already underway, then chooses the worker for the second slot. Product agrees to defer the partner launch. Without that release decision, “review the partner later” would leave a consequential new path without a response; selection must be connected to launch authority.
The amended brief is specific:
Slot 2: Review account authority from the customer export request through the shared job producer and worker read at the supplied revisions. Include staff-batch behavior only where it shares enforcement. Platform owns effective schedule and identity evidence; Finance owns job semantics. Discovery used one hour of this slot, so exclude archive retention from this review and record it as unassessed. Partner integration remains disabled and receives the first available review next month.
A broad worker credential does not establish a vulnerability. It establishes why the review question is consequential. If the worker instead proves retired with no active schedule, the first-hour output can justify selecting the partner scope. If no runtime evidence arrives, the sponsor must resolve the orphan-service problem; the lead can use the remaining slot for partner review while explicitly leaving the worker's applicability unresolved. The word “unknown” must survive the prioritization meeting.
Check whether the selected boundary is answerable
Before starting either slot, mark the control-owning components. Billing needs the request route, caller identity, invoice/account binding and storage delivery. The worker needs both message producers, message authority and the worker's effective read. A nominally low-priority shared library enters the scope when either decision depends on it.
Then name the person who can act on the result. An absent owner is a sponsor problem, not a reason to label a dangerous system low risk. Finally, state what a completed review would change: release a bounded partner feature, schedule an approved invoice fix, reject a specific allegation, or request a missing policy. If the answer is only “increase our scanned-repository count,” the scope has not yet become a useful assessment.
Record why a convenient repository did not win
The easiest repository to connect can be a poor first assessment if it has little relationship to the business action at risk. Keep the selection reason in the brief so a later tool demo or available volunteer does not silently change the objective. In AlderPay, the component library is ready to inspect, but the current invoice boundary depends on the shared authorization package and storage policy instead.
A deferred scope should still have an owner and a reason to return. The partner integration waits because Product can keep it disabled for the stated period. If that commitment changes, its place in the queue must change too. The marketing site waits under the current map of its data and form destinations; discovering a credential-bearing integration would require reassessment. Deferral is a dated choice, not a permanent low-risk label.
Use a simple comparison at the next checkpoint: what consequence motivated the selection, what material facts arrived, and does the scope still fit the available review time? If the billing review discovers a service outside the initial map, decide whether it is necessary to answer the invoice question. Include it when its control or delivery behavior can change the conclusion; record unrelated discoveries for later work.
This avoids two forms of scope drift. The first is expansion into every neighboring repository because it exists. The second is refusing to inspect a decisive dependency because the original brief named only one repository. Both lose sight of the application boundary that made the review valuable.
At the end of the first month, compare the chosen questions with their outcomes. A complete rejection of an important cross-account allegation is a useful result; an unresolved worker boundary with a named evidence gap is useful but incomplete. Count them according to their actual state. The next selection should follow the risk and evidence map produced by that work, rather than simply moving to the next alphabetic repository.
Revisit the queue when facts change
Reassess the ranking when an application becomes internet-facing, starts processing more sensitive data, adopts a shared component, changes ownership, suffers an incident, or gains a credible new threat. OWASP SAMM calls for updating application risk profiles as conditions change. At a monthly review, ask whether each deferred item's reason remains true and whether the first assessments produced enough evidence to guide the next one.
For AlderPay, the immediate next action is to obtain the export worker's deployed schedule and credential scope while the billing assessment begins. The next decision is how to turn its results into a manageable queue; use the one-engineer AppSec program guide for the surrounding operating loop and the review cadence guide to reserve decision and fix-check time.