Vulnerability Disclosure Policy

At Liaison, we take the security of our systems and the data entrusted to us seriously. We value the contributions of security researchers in helping us identify and address potential vulnerabilities. This policy outlines how to responsibly report security concerns, the guidelines for conducting security research, and what to expect from our response process.

Purpose

Liaison takes the security of its systems and the data entrusted to it seriously. We value the work of the security research community and recognize that independent researchers often identify issues before we do.

This policy explains how to report a suspected vulnerability, what you may and may not do while researching, what protections we extend to good-faith researchers, and how we will respond.

If you believe you have found a security vulnerability in a Liaison system or service, we want to hear from you.

Reporting a Vulnerability

Primary channel: security@liaisonedu.com

Encryption: For sensitive reports, encrypt your submission using our PGP key, available at https://www.liaisonedu.com/pgp-key.txt (fingerprint: [FINGERPRINT]).

Preferred languages: English

What to Include

Reports are triaged fastest when they contain:

  1. A clear description of the vulnerability and its potential impact.
  2. The specific product, URL, IP address, endpoint, or parameter affected.
  3. Step-by-step reproduction instructions, including any required preconditions, accounts, or configuration.
  4. Any proof-of-concept code, requests, screenshots, or logs supporting the finding.
  5. Your assessment of severity and exploitability.
  6. Whether the finding has been disclosed to any third-party.
  7. How you would like to be credited, if at all, and whether you consent to being named publicly.

Liaison accepts vulnerability reports submitted anonymously or under a pseudonym. Reporters are not required to identify themselves or provide proof of affiliation, employment, certifications, or prior research history for a report to be received or evaluated. Liaison will assess eligibility for safe harbor based on the reporter’s conduct and compliance with this policy, not on the reporter’s identity or claimed legitimacy. However, a reliable means of communication is strongly encouraged because it materially improves triage, remediation coordination, and any request for public credit. Where Liaison is asked to confirm that particular activity was authorized under this policy to law enforcement, counsel, a platform provider, or another third-party, Liaison may be limited in its ability to do so unless the reporter has provided sufficient identifying information to link the report to the relevant activity.

What not to Include

Do not include actual personal data, credentials belonging to others, or student records in your report. If demonstrating impact requires evidence involving real data, describe what you observed and provide a minimal redacted excerpt only. Contact us before transmitting anything further.

Safe Harbor

Liaison authorizes security research only to the extent expressly permitted by Sections 4 and 5 of this policy and only against Liaison-owned or Liaison -operated assets identified as in scope. No authorization is granted for activity against third-party systems, customer-controlled environments, or assets not expressly included in scope. Authorization automatically ends when Liaison requests that testing cease.

For purposes of this policy, “good-faith” security research means activity undertaken for the purpose of identifying and reporting a potential security vulnerability so that it may be remediated, and that is conducted in a manner reasonably designed to avoid harm to Liaison, its customers, and end users. Good-faith research includes acting within the scope of this policy, limiting testing to the minimum necessary to validate a finding, avoiding access to, acquisition of, or retention of data except where unavoidably incidental to demonstrating the issue, promptly reporting the finding, and ceasing activity when requested. If sensitive data is unintentionally accessed, researchers must cease testing of the affected issue, avoid further review or retention of the data, and promptly report the circumstances to Liaison.

Good-faith research does not include extortion, coercion, service disruption, unauthorized data exfiltration, or disclosure to third-parties inconsistent with this policy.

If you conduct your research in compliance with this policy, Liaison will:

  • To the extent permitted by applicable law, Liaison will not knowingly pursue civil action against, or make a criminal referral concerning, a researcher solely for security research that Liaison determines was conducted in good faith, within the scope of this policy, and in accordance with its requirements. This commitment does not restrict Liaison from responding to legal obligations, law-enforcement requests, protecting individuals or systems from harm, addressing conduct outside the scope of this policy, or pursuing remedies for unauthorized activity unrelated to good-faith research.
  • Waive, on a limited basis and solely for activity conducted under this policy, any provision of our Terms of Service or Acceptable Use Policy that would otherwise prohibit your research.
  • Not pursue action against you for minor, inadvertent deviations from authorized scope that occur despite reasonable efforts to comply with this policy. If you inadvertently exceed the authorized scope, stop immediately and tell us — we will work with you to understand what happened.
  • Upon request, and where consistent with applicable law and company policy, Liaison will confirm that activities conducted in compliance with this policy were authorized if you are contacted by law enforcement, prosecutors, or third-party counsel regarding research conducted within it.
  • Liaison will not knowingly make a negative report to a third party solely because a researcher conducted security research that Liaison determines was authorized under this policy. This commitment does not restrict Liaison from making disclosures required by law, responding to legitimate security or abuse inquiries, or communicating factual information necessary to protect its systems, users, customers, or third parties.

Limits of safe harbor

Safe harbor applies only to activity that is within the scope defined in Section 4, complies with the authorized-activity rules in Section 5, and does not fall within the prohibited activities in Section 6.

Safe harbor does not extend to:

  • Third-party systems, services, or infrastructure not owned or operated by Liaison, even where they are integrated with or reachable from Liaison services. We cannot grant authorization on another party's behalf.
  • Systems belonging to Liaison customers, including institution-hosted environments and institutional identity providers.
  • Activity that continues after we ask you to stop.
  • Activity undertaken primarily for extortion, coercion, competitive intelligence, unauthorized data acquisition or conditioning disclosure on payment.
  • Liaison will assess compliance with this policy based on the circumstances and available evidence, including the researcher's reported intent, actions taken, scope, impact, and cooperation in stopping or mitigating unintended effects.
  • Researchers are responsible for obtaining and maintaining any accounts, equipment, software, connectivity, hosting, domains, certificates, or other resources they use to conduct research. Liaison does not authorize researchers to compromise, scan, or otherwise test third-party infrastructure for the purpose of conducting research against Liaison.
  • If a vulnerability appears to originate in a third-party product or service, researchers should report the issue to Liaison when Liaison's implementation or configuration contributes to the security impact. Researchers must not independently test, exploit, or attempt to compromise the third-party provider's infrastructure unless separately authorized by that provider.
  • This policy does not authorize any action that violates applicable law, and it does not limit the rights of third parties. It is not a bug bounty program; Liaison does not currently offer monetary rewards. Nothing in this policy creates a contractual obligation. Nothing in this policy waives any applicable legal privilege, protection, or immunity available to Liaison.

Scope

In scope

  • Internet-facing production web applications and APIs operated by Liaison under liaisonedu.com and the service domains listed at https://www.liaisonedu.com/.well-known/security.txt
  • Liaison mobile applications published under Liaison's developer accounts
  • Liaison-operated public infrastructure supporting those services
  • Vulnerabilities in Liaison-developed code, including exposed secrets in Liaison-published repositories or artifacts

Out of Scope

The following are outside this policy and are not covered by safe harbor:

  • Any domain, subdomain, IP address, or service not owned and operated by Liaison, including cloud providers, payment processors, CRMs, analytics platforms, email providers, third-party AI model providers, and vendor-hosted environments
  • Customer-controlled configurations, institutional identity providers, and institution-hosted systems
  • Liaison corporate IT, internal networks, physical offices, and personnel
  • Beta, staging, or non-production environments unless we have explicitly invited testing

Findings we generally may not act on

These may still be reported, but are typically triaged as informational:

  • Missing security headers or cookie flags without a demonstrated exploit
  • TLS configuration observations (weak cipher suite support, protocol version preferences) without a working attack
  • Results from automated scanners submitted without validation or demonstrated impact
  • Volumetric denial of service and network-level resource exhaustion
  • Rate-limiting observations without demonstrated security impact
  • Self-XSS requiring the victim to paste content into their own browser console
  • Clickjacking on pages with no sensitive state-changing action
  • Vulnerabilities requiring a fully compromised or physically accessed device
  • Publicly known vulnerabilities in third-party components within their vendor-supported remediation window
  • Social engineering susceptibility of staff or users
  • Spelling, UI, or UX issues without security impact
  • Reports that are purely theoretical with no demonstrated exploit path

Authorized Activity

While researching in scope, you must:

  • Minimize impact. Use only the access necessary to demonstrate the vulnerability. Stop as soon as you have confirmed it.
  • Use your own test data. Create your own test accounts where possible. Do not access, modify, exfiltrate, retain, or destroy data belonging to others.
  • Stop on encountering sensitive data. If you encounter personal data, student records, credentials, financial data, or any confidential information, stop immediately, do not access further, do not save or transmit it, and report it to us right away
  • Unexpected impact.  If testing causes, or appears likely to cause, unexpected service degradation, account compromise, data exposure, security alerts, or other material impact, immediately stop the relevant testing and notify Liaison. Do not attempt to restore, clean up, investigate further, or remediate the affected environment unless Liaison specifically requests it.
  • Limit request volume. Keep automated scanning to a rate that does not degrade service. If you need higher volume to demonstrate a finding, contact us first.
  • Test one instance. Confirm a vulnerability on a single account or tenant rather than enumerating across customers.
  • Delete retained data. Securely delete any Liaison data obtained during research once your report is submitted, or on our request.
  • Comply with applicable law, including data protection and export control law in your jurisdiction and ours.
  • Authorization limits.  Authentication testing is permitted only using accounts and credentials controlled by the researcher or credentials expressly provided for testing. Testing must not involve credentials obtained from another person, credential dumps, breached-password databases, password spraying, credential stuffing, or attempts to authenticate as another individual.
  • Control Requirements.  Researchers must limit testing to accounts, tenants, records, and resources they control. Researchers must not attempt to demonstrate cross-tenant access by accessing another customer's actual data. Where a vulnerability appears capable of crossing tenant boundaries, demonstrate the minimum necessary condition using researcher-controlled test data and report the potential cross-tenant impact.
  • Vulnerability Chain.  Researchers may demonstrate a vulnerability chain when reasonably necessary to establish security impact, provided that each step remains within scope, uses the minimum access and activity necessary to demonstrate the chain, and does not involve accessing or retaining another person's data.

Prohibited Activity

The following are prohibited regardless of intent and are not protected by safe harbor:

  • Accessing, modifying, deleting, downloading, or retaining data belonging to any other person or institution
  • Any denial-of-service, load, or stress testing
  • Physical intrusion or testing of Liaison facilities, hardware, or personnel
  • Social engineering, phishing, vishing, smishing, or pretexting against Liaison personnel, customers, or vendors
  • Credential stuffing, password spraying, or brute-force authentication attacks
  • Installing persistence, escalating privileges beyond what is required to demonstrate a finding, or moving laterally within Liaison environments
  • Exfiltrating data, including as proof of concept
  • Deploying malware, ransomware, backdoors, cryptominers, or destructive payloads
  • Publishing, selling, sharing, or trading vulnerability details, exploits, or obtained data before coordinated disclosure
  • Demanding payment as a condition of disclosure, or threatening publication to obtain compensation
  • Testing out-of-scope assets, including unlisted subdomains and third-party platforms
  • Impacting the availability, integrity, or confidentiality of live services used by students, applicants, or institutions
  • Researchers should not expand testing into additional attack paths, accounts, tenants, systems, or vulnerabilities merely because access becomes available through an in-scope finding. If exploitation of one vulnerability provides access to additional systems or information, stop and report the resulting access rather than continuing to explore it.
  • Researchers must not create persistent accounts, SSH keys, API tokens, OAuth grants, scheduled tasks, web shells, backdoors, cloud resources, or other mechanisms that survive the testing session, except where expressly authorized in writing by Liaison.

Liaison serves higher-education institutions and processes applicant and student information. Research that risks the confidentiality or availability of that data causes real harm to individuals and will be treated accordingly.

Our Commitments and Response Timeline

When you submit a report in accordance with this policy, we will:


Stage Target
Acknowledge receipt Within 3 business days
Initial triage and validity assessment Within 10 business days
Communicate severity, planned action, and expected remediation window Within 15 business days of validation
Progress updates during remediation At least every 30 days
Notify you when remediation is complete Promptly on closure


We will keep you informed as we work, remediate validated findings according to the severity-based targets in our vulnerability management program, and credit you if you wish to be credited.

We will not share your identity with third parties without your permission, except where legally required.

Coordinated Disclosure

We ask that you give us a reasonable opportunity to remediate before publishing.

  • Our standard coordinated disclosure window is 90 days from the date we acknowledge your report.
  • If remediation requires longer — for example, a complex architectural fix or a dependency on an upstream vendor — we will tell you why, give a revised estimate, and agree an extension with you rather than expecting silence indefinitely.
  • We are glad to review a draft write-up for factual accuracy and to coordinate simultaneous publication
  • Please do not include customer names, institutional identifiers, personal data, or live exploit code targeting unpatched instances in any publication.

Where a vulnerability affects a third-party component, we may coordinate with the upstream maintainer and, where appropriate, support CVE assignment and credit to you.

Where a vulnerability materially affects customer data or requires customer action, we will notify affected customers in accordance with our contractual and legal obligations, independently of this disclosure timeline.

Policy Governance

This policy is owned by the Chief Information Security Officer, reviewed at least annually, and updated when scope, contacts, or process change. Changes apply prospectively; research conducted in good faith under a prior version remains covered by the version in effect at the time of that research.

Questions about this policy, including requests to clarify scope before you begin testing, may be sent to security@liaisonedu.com. We would rather answer a scoping question in advance than have a researcher guess.