fa5923610a
Aligns the repository with GitHub community-standard recommendations and makes the project's policies discoverable from the root, where contributors and tooling actually look for them. - CONTRIBUTING.md (root): router to per-project guides plus universal policies (branch from dev, ./book/binder setup, no `git add .`). - CODE_OF_CONDUCT.md (root): canonical Contributor Covenant 2.1, lifted from book/docs/. The book/docs version becomes a thin pointer so we have a single source of truth. - SECURITY.md: private vulnerability reporting via GitHub Security Advisory + maintainer email, with explicit in-scope/out-of-scope boundaries (textbook typos are not security issues). - CITATION.cff: machine-readable mirror of CITATION.bib so GitHub's "Cite this repository" button works. - .github/dependabot.yml: weekly bumps against `dev` for every actual ecosystem in the repo (pip, npm, github-actions), grouped where it makes sense (Next/React together). - .github/ISSUE_TEMPLATE/config.yml: blank_issues_enabled=false to keep reports on-template; added security-advisory contact link.
4.0 KiB
Security Policy
Thank you for helping keep MLSysBook and its users safe.
This repository contains a textbook plus several actively-developed software sub-projects. This document explains what we consider in-scope, how to report a vulnerability privately, and what response you can expect.
Reporting a vulnerability
Important
Do not open a public GitHub issue for a security vulnerability. Public reports give attackers a head start on users who haven't patched yet.
Use one of these private channels:
- Preferred — GitHub Private Vulnerability Report: https://github.com/harvard-edge/cs249r_book/security/advisories/new (requires a free GitHub account; gives us a structured triage thread)
- Email:
vj@eecs.harvard.eduandnkhoshnevis@g.harvard.edu. Please include "MLSysBook security" in the subject line.
Please include:
- A description of the issue and the impact you believe it has
- Steps to reproduce, or a proof-of-concept
- The affected sub-project and version / commit SHA
- Whether the issue is already public anywhere
Response expectations
We are an academic open-source project, not a product team with a 24/7 rotation. That said, we take security reports seriously:
| Stage | Target |
|---|---|
| Initial acknowledgement | within 5 business days |
| Triage and severity assessment | within 10 business days |
| Fix or mitigation plan | scoped to severity; critical issues prioritized |
| Public disclosure | coordinated with reporter; default 90-day embargo |
If you do not hear back within 5 business days, please escalate by re-sending the email and CC'ing both addresses above.
In-scope assets
These are the components where a vulnerability report makes sense:
| Component | Type | Why it's in scope |
|---|---|---|
interviews/staffml/ |
Public Next.js web app | Serves StaffML to users; auth, data integrity, XSS, IDOR, etc. |
interviews/staffml/worker/, staffml-vault-worker/ |
Cloudflare Workers (public API) | Internet-exposed API endpoints |
interviews/vault-cli/ |
Installable Python CLI | Code-execution risk for vault authors |
tinytorch/ |
Installable Python package | Distributed via pip; supply-chain and code-execution risk |
mlsysim/ |
Installable Python package | Same as above |
mlperf-edu/ |
Installable Python package | Same as above |
book/vscode-ext/, tinytorch/vscode-ext/, labs/vscode-ext/, kits/vscode-ext/, mlsysim/vscode-ext/ |
VSCode extensions | Run inside the user's editor; code-execution risk |
labs/ |
WASM-based browser labs | Same-origin / sandbox-escape risk |
GitHub Actions workflows in .github/workflows/ |
CI configuration | Token leakage, supply-chain injection |
site/newsletter/ |
Newsletter pipeline | Subscriber data handling |
Out of scope
These are not security issues — please use a regular bug report instead:
- Typos, factual errors, or pedagogical complaints in the textbook
- Broken links in chapters, slides, or the docs site
- Build failures of the Quarto book (
quarto render) - Stylistic issues with figures, tables, or callouts
- Findings against third-party services we link to (e.g. OpenReview, Google Scholar) — report those upstream
- Vulnerabilities in dependencies that are already public and have a fix available — please open a regular PR bumping the version
- "Best practice" hardening recommendations without a concrete attack scenario (we welcome these, but as PRs/discussions, not security advisories)
Safe-harbor for good-faith research
We will not pursue legal action against researchers who:
- Act in good faith to identify and report vulnerabilities
- Avoid privacy violations, data destruction, and service degradation
- Give us reasonable time to remediate before public disclosure
- Do not exploit a vulnerability beyond what is necessary to demonstrate it
Credit
Reporters who follow this policy will be credited in the published security advisory and in release notes, unless they request anonymity.
Last updated: 2026.