Brand Promise
Summer, a B-Corp dedicated to helping student loan borrowers, is committed to ensuring the safety and security of our users. Toward this end, Summer has now formalized our policy for accepting vulnerability reports in our products. We hope to foster an open partnership with the security community, and we recognize that the work the community does is important in continuing to ensure safety and security for all of our customers.
We have developed this policy to both reflect our company values and to uphold our legal responsibility to good-faith security researchers that are providing us with their expertise.
Initial Program and Scope
Initial Scope
Summer’s Vulnerability Disclosure Program initially covers the following products:
- Summer’s primary web app at app.meetsummer.org
While Summer may develop other products, we ask that all security researchers submit vulnerability reports only for the stated product list. We intend to increase our scope as we build capacity and experience with this process.
Within the above product list, we will address vulnerabilities, but the following issues are
- Any activity that could lead to the disruption of our service (DoS).
- Attacks requiring MITM (Man in the Middle)
- Clickjacking on pages with no sensitive actions.
- Unauthenticated/logout/login CSRF.
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
- User account enumeration
- Vulnerabilities that require attackers to use social engineering to access another user’s authenticated session, tokens, or require physical access to their devices.
- Issues that depend on unpatched or outdated browsers or mobile platforms
- Vulnerabilities as reported by automated tools without additional analysis as to how they’re an issue.
- Version disclosure, detailed error messages, and any other findings whose only security impact is ‘attacker reconnaissance’
- SPF and email anti-spam ‘hygiene’ issues
We Will Not Take Legal Action If…
Legal Posture
Summer will not engage in legal action against individuals who submit vulnerability reports. We openly accept reports for the currently listed Summer products. We agree not to pursue legal action against individuals who:
- Engage in the testing of systems/research without harming Summer or its customers.
- Engage in vulnerability testing within the scope of our vulnerability disclosure program.
- Adhere to the laws of their location and the location of Summer. For example, violating laws that would only result in a claim by Summer (and not a criminal claim) may be acceptable as Summer is authorizing the activity (reverse engineering or circumventing protective measures) to improve its system.
- Refrain from disclosing vulnerability details to the public before a mutually agreed-upon timeframe expires.
Communication Mechanisms and Process
How to Submit a Vulnerability
To submit a vulnerability report to Summer’s Product Security Team, please utilize the following email: security@meetsummer.org
Non-binding Submission Preferences and Prioritizations
Preference, Prioritization, and Acceptance Criteria
We will use the following criteria to prioritize and triage submissions.
What we would like to see from you:
- Well-written reports in English will have a higher chance of resolution.
- Reports that include proof-of-concept code equip us to better triage.
- Reports that include only crash dumps or other automated tool output may receive lower priority.
- Reports that include products not on the initial scope list may receive lower priority.
- Please include how you found the bug, the impact, and any potential remediation.
What you can expect from us:
- A timely response to your email (within 2 business days).
- After triage, we will send an expected timeline and commit to being as transparent as possible about the remediation timeline as well as on issues or challenges that may extend it.
- An open dialog to discuss issues.
- Notification when the vulnerability analysis has completed each stage of our review.
- Credit after the vulnerability has been validated and fixed.
Versioning
This document, Version 1.1, was created March 19, 2021
