Gibbon is school management software that brings student profiles, attendance, assessment, enrolment, and communication into one web application. The visible landing page may be a login screen or a public admissions form. The security question begins with the permissions attached to each role and the records those roles can reach.
A count-only ZoomEye query for app="Gibbon" returned 872 matches. The title="Gibbon" query returned 632. Both used sub_type=all, page 1, and pagesize 1. The near overlap is a useful deployment signal, but a matching product name does not establish that a school's records are exposed. It identifies candidate hosts for ownership and authorization review.
Review roles and public settings
Gibbon documentation describes student profiles as a central component that administrators and teachers use to access information, with visibility depending on Manage Permissions. It also distinguishes public and authenticated admission forms. Those settings are examples of why a site can be intentionally reachable while still carrying different data for different identities.
Inventory the administrator, teacher, parent, student, and support roles. Ask which modules each role can open and which records it can change. Pay particular attention to impersonation, messaging, individual education plans, medical or safeguarding fields, and access to student contact details.
Gibbon has added OAuth2 login handling and changed authentication-related areas in recent releases. The exact version and provider configuration matter. Verify the effective redirect, account-matching rule, and default role for an external identity. A directory account that is valid for a school's email domain should not automatically receive an administrator role.
Test public forms and private portals
Use an unauthenticated session, a parent account, a teacher account, a school administrator, and a support account with limited permissions. Confirm which pages and API calls each can reach. Test the public admissions form separately from the staff portal, because one may intentionally accept anonymous submissions while the other must reject them.
File uploads, messages, and profile photos may have different access checks from the record pages that link to them. Request a known file through a valid and invalid session. Do not collect or publish student data while testing. Use synthetic records in a controlled environment where possible.
Check session lifetime, password reset, and account deactivation. A parent who leaves the school or a staff member who changes roles should lose the corresponding access. External identity group changes need a measurable effect in Gibbon as well as in the identity provider.
Treat count differences as a coverage note
The 872 app matches and 632 title matches are close enough to suggest some fingerprint consistency, but the difference still matters. A school can customize the title, run a portal under another name, or expose an application endpoint without the visible label. An owner should resolve the host before applying a version-based conclusion.
Monitor authentication failures, role changes, permission changes, impersonation events, and access to sensitive student records. Correlate the application event with the identity provider and the responsible administrator. Keep the audit record free of unnecessary student details.
The useful outcome of a Gibbon inventory is not a list of 872 supposedly vulnerable schools. It is a reviewed set of hosts with an organization owner, a confirmed login policy, a role map, and evidence that sensitive records and public forms are separated. That evidence takes the count from an index result to a defensible security decision.