This policy explains how to report security vulnerabilities or sensitive-information exposures related to this repository. It is intended to support responsible reporting while protecting students, faculty, staff, maintainers, institutional systems, and the broader GitHub community.
Do not report security vulnerabilities, exposed credentials, or sensitive information through a public issue, discussion, pull request, commit, or comment.
- Supported Versions
- Security Issues Covered by This Policy
- Issues Not Covered by This Policy
- Reporting a Vulnerability
- Information to Include
- Handling of Reports
- Responsible Testing
- Exposed Credentials and Sensitive Information
- Coordinated Disclosure
- Academic and Institutional Requirements
- Provisional Status
- References
Security corrections are generally applied only to the current version of the authoritative repository.
| Repository version | Support status |
|---|---|
| Default branch and current release | Supported |
| Earlier releases or inactive branches | Best effort |
| Archived versions | Not supported |
| Forks, student repositories, and personal copies | Not directly supported by the upstream maintainers |
If a vulnerability found in a copy or fork originated in the authoritative repository, report it to the maintainers of the authoritative repository.
Examples of appropriate security reports include:
- Exposed passwords, access tokens, private keys, or other credentials
- Vulnerable repository scripts, applications, or configuration files
- GitHub Actions workflows with unsafe permissions or injection risks
- Dependencies with a vulnerability that affects repository functionality
- Instructions or automation that could expose personal, academic, or institutional information
- Unauthorized access to protected files, systems, or repository functions
- Unintended disclosure of nonpublic course, assessment, or student information
- Code that permits unintended command execution, privilege escalation, or data access
- Security controls that can be bypassed in a manner that creates a meaningful risk
A security weakness in an assignment, assessment, or automated test should be reported privately if public disclosure could expose answers, undermine an assessment, or enable academic misconduct.
Use the repository’s ordinary support channels for:
- General questions about a course, assignment, or repository
- Installation, configuration, or troubleshooting assistance
- Broken links, typographical errors, or ordinary software defects
- Feature requests or suggested improvements
- Academic-integrity or conduct concerns
- Problems limited to a separately maintained third-party product or service
Repository support options are described in SUPPORT.md. Conduct concerns are addressed in CODE_OF_CONDUCT.md.
Vulnerabilities in GitHub itself should be reported through GitHub’s designated security-reporting process rather than to this repository.
If private vulnerability reporting is enabled for this repository:
- Open the repository’s Security or Security and quality area.
- Select Advisories.
- Select Report a vulnerability.
- Complete the private report.
This method creates a private communication space where the reporter and repository maintainers can discuss the issue without exposing it publicly.
If private vulnerability reporting is unavailable, use an approved private institutional communication channel. Appropriate options may include:
- Privately contacting the course instructor through the learning management system
- Contacting a repository administrator through an established institutional channel
- Using the applicable institutional information-security or service-desk reporting process
Do not place vulnerability details in a public GitHub issue or discussion. Do not include working credentials, actual student records, or other sensitive data in a report.
Provide enough information for maintainers to understand and reproduce the issue safely:
- A concise description of the vulnerability
- The affected file, component, workflow, version, branch, or release
- The potential security or privacy impact
- The conditions required to reproduce the issue
- Clear reproduction steps using synthetic or non-sensitive data
- A minimal proof of concept, when necessary and safe
- Relevant operating system, software, or environment information
- Any temporary mitigation or proposed correction
- Whether the issue has been disclosed to anyone else
- A safe method for maintainers to request additional information
Remove credentials, student information, private communications, and unrelated personal information before submitting the report.
Repository maintainers will make a reasonable effort to:
- Review the report.
- Determine whether the issue is reproducible and within scope.
- Assess its potential impact.
- Identify an appropriate correction or mitigation.
- Coordinate necessary communication with institutional or platform personnel.
- Notify the reporter when the issue has been resolved or otherwise addressed, when practical.
Response and remediation times depend on the issue’s severity, complexity, available resources, academic calendar, and any required institutional review. This policy does not establish a guaranteed response time or service-level agreement.
Reports may be closed without remediation when an issue cannot be reproduced, is outside the repository’s control, presents no meaningful security impact, or concerns an unsupported version.
This repository does not offer a vulnerability-reward or bug-bounty program unless a separate written program explicitly states otherwise.
This policy does not authorize security testing against GitHub, institutional systems, course platforms, third-party services, other users’ repositories, or devices that you do not own or have explicit permission to test.
Unless separately authorized in writing, do not:
- Access, modify, retain, or disclose another person’s data
- Use real credentials or attempt to determine whether exposed credentials remain valid
- Conduct automated scanning against institutional or third-party systems
- Perform denial-of-service, load, or resource-exhaustion testing
- Use social engineering, phishing, or impersonation
- Bypass authentication or access controls
- Introduce malware or persistent access
- Disrupt instruction, assessment, repository availability, or other services
- Test using student records, grades, or other regulated information
When possible, perform analysis in a local copy using synthetic data and an environment you control.
If you encounter sensitive information unintentionally, stop testing, avoid additional access, preserve only the minimum information needed to report the issue, and submit a private report promptly.
If you discover an exposed credential:
- Do not use or test it.
- Report it privately and promptly.
- Identify its location without reproducing the complete secret.
- If the credential belongs to you, revoke or rotate it immediately.
- Follow applicable institutional incident-reporting requirements.
Deleting a secret from the current version of a file may not remove it from Git history, cached content, forks, logs, or prior workflow output. Revocation or rotation is therefore normally required.
Please allow repository maintainers a reasonable opportunity to investigate and address a reported vulnerability before disclosing it publicly.
The reporter and maintainers should coordinate:
- Whether public disclosure is appropriate
- What technical details can be shared safely
- When disclosure should occur
- Whether a security advisory or release note is needed
- How contributors should be credited
Do not publish details that expose credentials, personal information, student information, assessment content, or an uncorrected vulnerability without authorization.
Security reporting does not replace applicable course instructions, academic-integrity requirements, acceptable-use policies, privacy requirements, or institutional incident-reporting procedures.
Discovering a vulnerability does not authorize a person to exploit it, access restricted information, disrupt a course or service, or exceed the scope of an assignment. Any academic or disciplinary consequences will be determined through the applicable institutional processes.
Formal institutional review and approval of this Security Policy are pending. This interim document may be revised or replaced after that review is complete.
This policy does not create a safe-harbor agreement, authorize security testing, establish a contractual response obligation, or replace applicable institutional policies, course requirements, contractual obligations, laws, or platform terms. If a conflict exists, the controlling institutional policy, course requirement, law, contract, or platform term takes precedence.
This document uses original, academic-context wording informed by the following sources:
- Adding a security policy to your repository, which describes GitHub’s requirements for communicating supported versions and reporting procedures.
- Privately reporting a security vulnerability, which describes GitHub’s private vulnerability-reporting process.
- About coordinated disclosure of security vulnerabilities, which describes private collaboration and coordinated publication through repository security advisories.
- GitHub Community Guidelines, which establishes expectations for safe, respectful, and responsible participation on GitHub.
- GitHub Terms of Service, which governs access to and use of GitHub.
- Applicable institutional information-security, privacy, acceptable-use, academic-integrity, records-management, and incident-response policies.