For maintainers

Responsibility

See OEP-60 Open Source Security Working Group — Open edX Proposals 1.0 documentation.

• You are responsible for resolving security vulnerabilities in the repos you maintain.

• Have questions or need help? Email security@openedx.org.

• We’ll nudge you in proportion to the severity of the vulnerability using the scoring system below.

  • Tell us if you want to classify it differently. You have the final say on this.

• Please keep security vulnerabilities private until a fix is released.

Scoring

From CVSS v3.1 Specification Document.

Process

After getting a “New security vulnerability” email from security@openedx.org

1. Fix the vulnerability in a temporary private fork. Do not merge yet. [GitHub docs]

2. Post a release time in Security Announcements.

   1. Don’t post until you test your fix.

   2. Note: topics in Security Announcements are moderated. They may take a little time to appear publicly.

   3. Make the release time on a weekday at least 48 hours after your post.

   4. Template:

      1. Title:

         Security: Upcoming Security Release for {{repository_name}} on {{YYYY-MM-DD}}

      2. Body:

         **openedx/{{repository_name}}** version **{{version_number}}** will be released on [date={{YYYY-MM-DD}} time={{HH:MM:SS}} timezone="America/New_York"]. It will fix one security defect with a "{{severity}}" [CVSS 3.1 severity rating](https://nvd.nist.gov/vuln-metrics/cvss). Details will be published here after release: [GitHub security advisory]({{github_security_advisory_url}}).

   5. Example:

      1. Title:

         Security: Upcoming Security Release for xblock-drag-and-drop-v2 on {{2023-01-24}}

      2. Body:

3. Around release time, within a 2 hours window:

   1. Merge temporary private fork. [GitHub docs]

   2. PR and merge the fix to the active release branches:

      1. open-release/<current-release-name>.master

      2. open-release/<next-release-name>.master, if it already exists

      3. Find release-names in Support Windows

      4. TODO: include instructions for how to merge fix to release branch

   3. Link the PR(s) for the active release branches in #wg-build-test-release

      1. This way, BTR can take any actions needed to include your PR in releases.

   4. Publish security advisory. [GitHub docs]

   5. If this is a library, publish the new version to PyPI or NPM

   6. Reply to your Security Announcements post with the PR URLs:

      1. Template:

         1. Body:

      2. Example:

         1. Body: