How to design a least-privilege developer finding view

A developer finding view should show the findings that person is authorized to read, with enough evidence to investigate and repair them. Decide whether repository membership grants access or assignments restrict it; workload order alone is not a reason to hide findings. Decide access from the current person, account, repository, assignment, finding and field sensitivity before building the response. Use the same decision for a direct link, search result, report and export. If the engineer is also an authorized security reviewer, grant that broader work explicitly; a job title or ownership hint should not silently expand the developer view. OWASP recommends denying by default and checking authorization on every request, including requests made outside the normal UI (Authorization Cheat Sheet).

This is a design decision, not merely a choice of columns in a table. A hidden row can still leak its title through a count, its existence through a cursor, or its technical content through an export. A generous finding view can also expose code paths, security control weaknesses and customer context to people who do not need them. The useful outcome is a small, explainable access rule and a delivery contract every surface can enforce.

Start with the repair task, not an all-purpose role

Write down what a developer needs to repair an assigned issue: the harmful behavior in plain words, affected component and revision, the permitted evidence range, expected control, fix direction, owner, status and a check for closure. A developer usually does not need another team's findings, raw scanner transcripts, secrets, a full repository copy or an executive risk dossier. An AppSec reviewer may need counterevidence and rejected candidates, but that is a separate capability.

The decision has at least four parts:

1. Who is asking? Resolve the authenticated subject and current account membership from the server's trusted identity and policy records. Do not accept a browser-supplied role or account ID as authority.
2. Which work may they see now? Check repository entitlement and any assignment restriction the policy actually requires. Under repository-wide access, assignment and queue size only route work; they do not constrain readership.
3. Which sections may be released? Define a technical repair projection, an AppSec review projection and a business projection separately. Field names alone are insufficient: prose, comments and attachments can carry the same sensitive detail as a dedicated exploit_steps field.
4. What happens after a change? Recheck current policy on every read. Apply the declared rule after reassignment, repository removal, role change or finding closure. Closing a finding need not remove access to its repair history. Previously downloaded content cannot be recalled.

The service that owns the finding must enforce this rule against the actual resource and its parent repository. A gateway can help establish trusted caller context, but a downstream service still has to protect its own object and output; OWASP's Authorization Patterns guidance describes this resource-level enforcement.

Illustrative case: two developers, one restricted backlog

Illustrative case; the organization, repositories and numbers are invented. Northstar Analytics has a billing repository and a customer-support repository. Mira is a billing developer. Sol is a support developer. Five billing findings have been approved; an AppSec dispatcher assigns the first two active repair items, including B-17, to Mira. The other three remain in a restricted dispatch backlog. B-17 concerns an invoice export; its developer section contains the affected route and a short evidence excerpt. Its review section contains a disputed alternate path and an internal customer-impact note.

Mira needs B-17's repair section and status. She does not need the disputed review note unless given reviewer authority. Sol should not discover B-17 through a search, count or guessed URL. A finance executive may need to know that billing export access is under review and what decision is due, but should not receive the route, precise source location or reproduction instructions.

The decision record can be short enough to review in a design meeting:

The table is an access contract, not evidence that any particular product implements it. Replace its invented names and window with your own policy. OWASP's guidance on authorization decisions and output handling calls out list, search, export, count and aggregate outputs as parts of the same protected result.

Decide whether assignment is routing or authorization

Two reasonable policies produce different answers for Mira. With repository-wide access, Mira can read all five billing findings and assignment merely routes work. With assignment-limited access, only her two current items are readable. Choose based on the actual sensitivity and collaboration needs; an arbitrary cap can hinder repairs without protecting a meaningful boundary.

For the rest of this synthetic example, the organization deliberately chooses assignment-limited access. The dispatcher establishes Mira's ordered eligible set as [B-17, B-21]. The hidden backlog is [B-30, B-34, B-40]. A search is applied to the eligible set, not used to pick a new set:

eligible = current_authorized_assignment_window(Mira, billing, limit=2)
visible = filter(eligible, requested_search)
response = paginate(project_repair_fields(visible))

Suppose only B-30 contains “refund.” A search for that word returns zero matches. The tempting implementation below leaks the backlog because it changes the security window when the query changes:

# Wrong under this policy
first_two(findings_for_repository(billing).search("refund"))

A zero result means “zero matches among the work you may currently see,” not “no refund finding exists.” Counts and facets must use the same set. A cursor must be bound to this viewer, scope and policy state; an old cursor must not reopen the previous assignment after reassignment. If the authorization service returns an incomplete set, do not label its count the complete backlog count.

Give the developer enough to make the fix

For B-17, a useful repair projection could be:

{
  "id": "B-17",
  "problem": "Invoice export omits the stored account check",
  "component": "billing export handler at illustrative revision C42",
  "evidence": "The lookup selects invoices by ID without account scope",
  "repair": "Bind each selected invoice to the verified account before export",
  "acceptance": "Own-account export works; mixed-account export releases nothing"
}

This is invented output, not a product schema. Its specificity makes the repair possible without sending the entire scanner conversation. The source excerpt, if included, must itself be approved for Mira's audience. Removing a field called secret while leaving the credential in the evidence prose accomplishes nothing.

At 11:00 the dispatcher reassigns B-17 to Sol, after giving Sol an appropriate billing repository grant. Mira's fresh detail, export and search requests now deny B-17. Sol receives the repair projection; neither automatically receives review notes. If Sol has no billing entitlement, reassignment fails or remains pending without releasing content. Assignment cannot manufacture the missing parent permission.

The product should explain “This item is no longer in your assigned work” without naming the new owner or hidden backlog unless that information is separately allowed. If Mira already downloaded the evidence, future access can be stopped but that copy cannot be recalled. This is a reason to minimize the initial projection, not a reason to pretend revocation is useless.

A design review succeeds when the team can resolve these concrete cases consistently. OWASP's collection-output guidance supports applying authorization to all returned forms; the particular two-item policy here is an illustrative product choice, not an OWASP requirement.

Make the response contract as strict as the decision

Prefer building the authorized data set before retrieval or filtering candidates inside a trusted service before release. Never fetch every finding to the browser and hide unauthorized cards with CSS. If a detail endpoint checks the rule but a report generator uses a broad service credential, the design is incomplete. OWASP's output-handling guidance explicitly includes counts and exports, and the API Top 10 property-level entry addresses fields a caller should not receive.

List the surfaces in the design record: list, detail, search, metrics, comments, report snapshots, CSV/JSON/SARIF exports, links in notifications, integrations and any machine interface. For each, name the enforcing service, the policy inputs, the allowed projection and the behavior when policy data is missing. Historical evidence may stay immutable while current readership changes. A cached report is not a permanent reading grant.

Keep denied output plain. Do not return “three hidden critical findings,” a different pagination cursor for excluded rows, or an error that reveals an unknown finding's title. Avoid promising that a uniform error makes the system impossible to enumerate; timing, caching and adjacent APIs still merit review. Minimize sensitive detail in broad audit logs and notifications.

Review the rule with a small evidence packet

Ask the service owner for the current membership and repository source of truth, the assignment/version record, section schema, list query, detail lookup, export path and cache behavior. Walk one allowed request and four denied requests: wrong repository, wrong account, out-of-window finding and revoked assignment. For each, capture the policy version, resource parent, decision and actual fields returned. Do this in an authorized environment with synthetic records. A unit-level policy result alone cannot prove the list, export or download path enforces it.

If the parent repository is missing, a decision service times out or a finding carries conflicting ownership, withhold the content and investigate. If a reviewer finds an upstream filter, inspect whether it governs every route and whether the downstream reader could bypass it. If you have only source code, label the conclusion source-supported; a deployed system needs controlled runtime evidence before claiming the boundary works in production.

Design collaboration without widening every reader's access

Assignment-limited access can make a repair harder if Mira needs help from another billing engineer. Decide how collaboration works before developers begin copying restricted evidence into general chat. In Northstar's chosen policy, an authorized dispatcher could add a named collaborator to B-17 with the repair projection only. That grant should be explicit and removable; a comment mention should not automatically create it.

The collaborator needs the same resource and field checks as the primary assignee. Sharing a link is a navigation action, not a permission grant. If the link recipient lacks access, the response should explain the ordinary request path for help without exposing the finding's title or sensitive content. A reviewer can then decide whether the person needs access or whether a narrower engineering question is sufficient.

Repair history presents a separate product decision. If the team keeps closed findings visible to authorized repository developers, record that policy and protect any review-only sections. If assignment-limited access ends when work closes, preserve a restricted record for later regression investigation. Neither choice should emerge accidentally from whether an archived row remains in a search index.

This makes least privilege workable for the people doing the repair. The view gives enough evidence to act, offers an explicit way to involve help, and keeps broader review material under its own authority.

Next action: draft a one-page matrix like Northstar's for one sensitive repository and trace each row through list, detail and export. Continue with how to check list and detail authorization and how to review stale access after permission changes.