Start with the original finding and the new immutable commit. Trace the changed path, then expand only to callers, shared controls, data stores and effects that could change the conclusion. This is a bounded reassessment: it saves work by using the old finding as a map, while still checking the new source where the security property depends on it. The boundary must be written down. If a refactor, missing dependency, new route or incomplete inventory prevents a reliable boundary, widen the review or return inconclusive; do not relabel old evidence as newly examined.
The method is useful when a repository is large but a proposed patch is small. A full repository assessment may be appropriate for a release gate or a broad architectural change. For a fix decision, the immediate job is narrower: decide whether the particular old harmful behavior remains, at the new revision and stated scope. The reviewed outcome should say both what changed and what was deliberately not reassessed.
An illustrative shared-guard change
Illustrative case, not a customer result: Cedar Docs has a verified source finding that a signed-in user can request a document ID from another account through a PDF download route. The original reviewed path at OLD_SHA crosses a route handler, canReadDocument, a metadata lookup and an object delivery service. The proposed patch at NEW_SHA changes canReadDocument to compare the document's owning account with the server-derived active account.
The change is only a few lines, but the guard has fourteen callers in three services. Some callers pass a full document object; others pass a document ID; one export job calls a similarly named helper in another package. Reassessing only the edited lines would miss whether the guard receives trustworthy account context and whether every affected delivery route actually uses it. Reassessing every unrelated parser, UI component and deployment script would not help the immediate closure decision. The right work unit is the affected call neighborhood, with a written expansion rule.
| Candidate scope | Why include it? | Cedar decision |
|---|---|---|
| Original PDF route and its downstream data read | Direct path in the finding. | Include. |
| Changed shared guard and all known callers | A new predicate can alter or fail differently for each call shape. | Include caller inventory; inspect caller-specific use. |
| Account identity provider and document owner lookup | Their provenance determines whether the comparison is meaningful. | Include. |
| Export route that uses a different helper | It may reach the same protected asset without the new guard. | Include as an alternate path check. |
| Unrelated image transcoder | No call, data or policy relationship to the document read in this finding. | Exclude, with reason and inventory source. |
| Unknown dynamically registered handler | Its route mapping is incomplete. | Mark as an unresolved boundary; obtain mapping or widen review. |
OWASP's Authorization Cheat Sheet recommends permission checks on every request and a deny-by-default posture. That principle explains why a changed central guard requires caller review: the reviewer must establish that each relevant request reaches the guard with the right resource and current actor, not merely that the guard contains a good comparison.
Step 1: Bind the claim and decide what must be re-proven
Write the old actor, entry, controlled input, intended policy, failed control and effect in one paragraph. Attach the old finding version and its immutable revision. Identify the proposed new revision and the patch's stated goal. If the old finding was provisional, assess its evidence before announcing that a confirmed vulnerability was fixed; you can still review the new control and report the improvement with that qualification. A patch can reduce risk even when the original report was overstated, but it cannot retroactively validate the old claim.
For Cedar, the question is: “At NEW_SHA, can an ordinary account A user still receive account B's document through a reachable delivery path?” The scope includes the direct PDF route and any route sharing the same read or delivery operation. It does not become a claim that every document feature in the product is secure.
Output: a one-sentence policy and a list of old evidence edges that the new revision must either preserve safely or invalidate with proof.
Step 2: Compare revisions and map moved code
Collect changed paths and inspect the relevant diff. Git's diff documentation supports comparing commits; its diffcore documentation explains rename and copy detection. These are navigation aids, not a security oracle. A move can change which middleware or caller invokes a function; unchanged source text may behave differently under a new route or configuration.
Make a mapping table with old path, new path, reason for inclusion and mapping confidence. Include deletions and new files that replace old behavior. Search for calls to the old and new helper names and inspect route registration, not only lexical references. If dynamic dispatch or generated wiring is involved, seek the configuration or runtime artifact that resolves it. Record anything the available source cannot establish.
Output: a current map of entry → guard → data access → response for every affected path. Check: a second reviewer can locate every mapped edge at NEW_SHA.
Step 3: Group callers only after checking what makes them equivalent
Cedar's fourteen known guard callers form three groups in this constructed inventory. Counts are illustrative, not coverage measurements from a real repository.
| Group | Callers | Shared shape | Required review |
|---|---|---|---|
| Ordinary document reads | 9 | Trusted current account plus authoritative document object; return the checked object. | Trace one complete path, then inspect each member's binding, failure behavior and returned object to establish that shape actually holds. |
| ID-loading adapters | 3 | Guard receives an ID and loads ownership internally. | Inspect the loader and each caller's ID source; do not borrow the full-object group's conclusion. |
| Delegated support reads | 2 | Support grant selects permitted account/action. | Review delegation authority separately; comparing only the support agent's home account would break legitimate access. |
Nine visually similar handlers are not automatically equivalent. One that reloads a different document after the check leaves the group and requires its own trace. A differing policy provider, cache, error branch or delivery mechanism can also invalidate the shared reasoning. Grouping saves repeated explanation of the same verified guard; it does not excuse inspecting each caller's connection to it.
The export job uses another package's similarly named helper and is outside these fourteen guard callers. Review it as an alternate path to the same asset, preserving the original PDF finding's boundary. The image transcoder remains excluded because the current inventory shows no relevant call, authority or delivery relationship.
A late registration artifact adds an event handler not present in the lexical caller list:
registry R6: "document-preview" -> preview_adapter
preview_adapter -> ID-loading guard -> checked document -> preview response
Bind R6 to NEW_SHA's artifact, inspect that adapter and update the inventory to fifteen callers: 9 full-object, 4 ID-loading and 2 delegated. If the loader and object continuity match the inspected ID group, reuse the group's guard explanation while recording the new adapter review. If the artifact cannot be bound, list the handler as unresolved rather than claiming a complete fifteen-caller assessment.
The stopping rule is path-specific: the direct PDF entry has a continuous authorized-object chain; each discovered neighbor has a bounded decision or explicit open record; unrelated work has a defensible exclusion. This supports a direct-PDF closure decision when its required deployment/behavior evidence is complete. It does not require inventing a product-wide document-safety claim.
Step 4: Verify the new behavior on the affected path
At NEW_SHA, inspect the guard and the provenance of its inputs. Does current_account come from the authenticated server context, or can a request supply it? Is the document owner read from a trustworthy record? Does a failed check prevent any protected bytes, metadata or usable delivery link? Can another route bypass the guard? Record exact source references and the strongest counterevidence, not only the patch diff.
Where the conclusion needs a runtime observation, use an authorized test environment with synthetic A/B accounts, a known B-owned document and a known deployed artifact. Confirm that A's own document still works and B's does not become available to A. A nonexistent document is a poor negative case: it can return “not found” even when cross-account access remains broken. If the test cannot be run, keep the source-supported conclusion separate from deployment proof. NIST's SSDF places verification alongside remediation; the specific verification method should match the claim.
Output: one of fixed, still exists or inconclusive, with revision, scope and evidence. A changed alert count is supplemental, not a closing criterion.
Step 5: Preserve old work without laundering it into new coverage
Reuse prior analysis when its inputs and assumptions still hold. Record the earlier review, matching file or artifact identity, and the changed callers, configuration and dependencies you checked before relying on it. Label it reused evidence, not a fresh examination of every unchanged file. A matching helper hash alone is insufficient if its caller now supplies a different identity or object.
The completed exercise record after R6 arrives is:
Original scope: direct PDF cross-account read at OLD_SHA. New review: changed guard, account provenance and fifteen identified callers with their bindings; export helper assessed separately. Included late: R6's preview adapter, now mapped to the ID-loading group. Excluded: image transcoder, with no relevant relationship in the checked inventory. Decision: direct PDF correction supported in source; its deployment/controlled behavior still require the recorded checks. Separate records: export's different helper and delegated-policy questions retain their own scope and outcomes. No whole-product closure is claimed.
That record makes the cost saving honest. It tells the next reviewer exactly which prior work was a map, which new source was examined, and why the remaining gap matters.
Make the expansion rule a decision the owner can fund
Before starting Cedar's reassessment, agree that a caller leaves its group when it changes authority provenance, object loading, denial behavior or delivery. That rule turns a late discovery into a concrete scope decision. The R6 adapter can join the ID-loading group only after its binding is checked; an unexplained provider requires additional work.
Record the planned boundary and the final boundary separately. If the initial estimate covered fourteen callers and the effective registry adds a fifteenth, show the additional review and any resulting delay. The number itself is not the security conclusion; it explains why the work grew.
If time runs out before a newly discovered path is understood, report that path as unresolved with an owner. Close the original direct-PDF scope only when its own acceptance evidence is complete and the outstanding path does not invalidate that conclusion. This keeps bounded reassessment efficient without using the initial estimate as a reason to ignore new relevant evidence.
Know when to widen the assessment
Widen beyond the original path when a shared security control changes across many resources, a framework upgrade changes authorization semantics, routing moves across services, the repository inventory is incomplete, or a new feature exposes the same asset. A small diff does not imply a small security effect. Conversely, a large formatting diff need not imply a full security reassessment if its semantics and affected callers can be established. The decision follows the path and control relationships, not the number of changed lines.
If the scope boundary cannot be defended, say inconclusive and request the missing artifact. For one patch this week, sketch the affected call neighborhood before opening the scanner or diff viewer; then compare the evidence you actually reviewed with the full new-commit verification method. If a quiet scanner run prompted the review, first use fixed versus no longer detected.