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

Severity

Score

Reminder frequency

Severity

Score

Reminder frequency

Low

≥0.1

Twice a year

Medium

≥4.0

Once a quarter

High

≥7.0

Once a month

Critical

≥9.0

Once a week

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 https://docs.google.com/spreadsheets/d/11DheEtMDGrbA9hsUvZ2SEd4Cc8CaC4mAfoV8SVaLBGI/edit

      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: