Review Board centers its workflow on review requests. A review request can contain code diffs, design documents, attachments, comments, and approval history. Its visibility depends on repository access, review groups, reviewer lists, and account permissions. An exposed login page can be ordinary. An exposed review request is a different finding.
What the measurement shows
On 2026-11-10T17:47:11.934453+00:00, a ZoomEye SDK query used sub_type=all, page 1, and page size 1:
title="Review Board"
The query returned 493 total matches. This is a title-based product observation. It can include documentation pages, hosted services, and review portals. It does not prove that review requests or attachments can be read anonymously.
Map the repository boundary
Review Board documentation states that a review request on a private repository can be viewed by users on the reviewer list, the repository user access list, or a group on the repository group access list. The access control model therefore combines repository ACLs with review-request participants.
A repository marked private should have an explicit access list. Review Board can also support anonymous read-only access, so verify that setting before assuming a login is required. For each repository, record whether it is public, private, linked to an external source, and accessible to which groups.
Review groups and API tokens
Permission groups manage review request permissions. A group can be convenient for project membership, but it can also accumulate users who no longer need access. Reconcile group membership with the source directory and the project owner's approval record.
Review Board API tokens can be read-only or have broader write capability. They are created through account settings and act under the user's permissions. For each token, record the owner, purpose, scope, creation date, and last use if available.
Test that a read-only token cannot post a review or change a review request. Verify that a token from a user removed from a private group cannot continue to read that repository's review requests.
Check attachments and integrations
Review requests can include file attachments, PDFs, office documents, and repository connections. Access to a review request should cover its attachments, but the integration path may use a separate credential.
Review the source-code integration token for GitHub, GitLab, or another repository host. Grant access only to the repositories that Review Board needs. A repository integration token with organization-wide scope can expose more metadata than the review UI shows.
Inspect webhook endpoints and their authentication. A webhook that can trigger repository synchronization should reject forged requests and should have a replay-resistant signature or secret.
Use ZoomEye as a candidate set
Use the title query to find Review Board candidates, then verify the product with the public page or an approved configuration review. Do not enumerate review requests or attempt account access on an unowned host.
Compare the candidate with the engineering inventory. A review portal used by a small project may be intentionally public. A portal that serves private repositories should have a named owner and a reviewed access list.
Keep access evidence current
Store the query, count, timestamp, hostname, repository visibility, anonymous-read setting, and reviewer. Recheck after repository onboarding, group changes, token rotation, and hosting migrations.
Review Board's value is tied to code-review visibility. The repository ACL and API token state decide whether that visibility matches the intended audience.