Mattermost Handbook
Need help?How to spend company moneyHow to update the HandbookRelease overview
0.2.1
0.2.1
  • Mattermost Handbook
  • Company
    • About Mattermost
      • List of terms
      • Business model
      • Mindsets
    • "How to" guides for staff
      • How to set up a 1-1 channel
      • How to update the handbook
      • How to manage Handbook notifications
      • How to change mobile device
        • How to handle a lost mobile device
      • How to do a mini-retrospective
      • How to autolink keywords in Mattermost
  • Operations
    • Company operations
      • Areas of Responsibility
      • Mattermost Leadership Team (MLT)
        • MLT cadence
      • Company measures
        • Metrics definitions
        • FY23 goals board
        • MLT metrics
      • Company cadence
      • Company policies
        • Community response policy
        • Security policy
      • Company processes
        • Issue/solution process
        • Company agreements
        • Publishing
          • Public web properties
          • Publishing guidelines
            • Brand and visual design guidelines
            • Voice, tone, and writing style guidelines
              • Contribute to documentation
            • Confidentiality guidelines
          • Post-publication quality control process
      • Handbook processes and policies
        • Handbook onboarding
      • Fiscal year planning
    • Research and Development
      • Organization
        • Tech Writing
        • Data engineering
        • Delivery
        • Cloud Platform
        • Site Reliability Engineering
        • GRC
        • Product Security
        • Security Operations
      • Processes
        • Feature Labels
      • Product
        • Product planning
          • Product philosophy and principles
          • Prioritization process
          • Release planning process
          • Roadmap views
          • Release plan
          • Launch plan
          • Feature requests
        • Development process
          • Mobile feature guidelines
          • Deprecation policy
          • Mattermost software requirements process
          • Jira ticket lifecycle
          • Creating new Jira bug tickets
            • Priority levels for tickets
            • Jira fix versions
        • Release process
          • Release overview
          • Feature release process
          • Dot release process
          • Security release process
          • Mobile app release process
          • Desktop app release process
          • Release tips
          • Release scorecard definitions
        • How-to guides for Product
          • How to use productboard
          • How to record a roadmap video
          • How to update integrations directory
          • How to write a feature release announcement
        • Product Management team handbook
          • Product Management Areas of Ownership
          • Product Manager onboarding
          • Product Manager levels
          • Professional development
        • Product Design team handbook
          • Product Design levels
        • Technical Writing team handbook
          • Work with us
          • User interface text guidelines
          • Documentation style guide
          • Our terminology
          • Guidelines for PMs and developers
          • Guidelines for community contributions
          • Technical Writer levels
          • Docathon 2021
            • Getting started with contributing
        • Growth
          • A/B testing methodology
          • PQL definition
        • Analytics
          • Product Analyst Engineer levels
          • Looker
            • Dashboards
            • Explores
          • Telemetry
        • Developer relations
        • Product team hangouts
      • Engineering
        • Infrastructure engineering
          • Cloud infrastructure cost KPIs
          • Cloud data export process
          • Cloud churn process
          • Reliability Manifesto
          • Production Readiness Review
          • Infrastructure Library
        • Integrations team processes
        • Plugin release process
        • Data Engineering
        • Sustained Engineering
          • On call
        • How to go to a conference
        • Public speaking
        • Core contributor expanded access policy
      • Quality Assurance
        • QA workflow
        • QA testing tips and tools
        • Rainforest process
    • Messaging and Math
      • How-to guides for M&M
        • How to create release announcements
        • How to create screenshots and GIFs
        • How to write Mattermost case studies
        • How to write guest blog posts for Mattermost apps and services
        • How to write Mattermost recipes
        • How to compose tweets
        • How to create a split test for web page
        • How to run meetups
        • How to run executive dinners
      • Checklists for M&M
        • Blog post checklist
        • Bio checklist
      • Mattermost websites
      • Demand generation reporting
      • M&M Asana guidelines
      • Content marketing
        • How to use the editorial calendar
        • Content development and distribution
        • Video content guidelines
        • How to contribute content
    • Sales
      • Deal Desk
      • Partner programs
      • Lead management
    • Deployment Engineering
      • Overview
      • Workflows
      • Frequently Asked Questions
      • Playbook for MME Sev 1 Outages
      • Status Update Template
    • Program Management
    • Customer Success
      • Customer Support
    • Legal
      • Contracts
      • Ironclad Basics
        • Company-Wide Workflows
        • Sales Contracts and Workflows
        • Signing a Contract and Contract Repository
    • Finance
      • Budget
      • How to use Airbase
        • Access Airbase
        • Navigate Airbase
        • How to submit a purchase request
        • How to submit a reimbursement request
        • How to review a reimbursement request
        • Vendor portal guide
        • Frequently asked questions
      • Onboarding
        • Vendor onboarding
        • ROW staff onboarding
      • Staff member expenses
        • How to spend company money
        • How to spend company money: Internships
        • Corporate credit card policy
        • How to access Airbase
        • Gifting policy
        • How to book airfare and travel
        • How to reimburse the company
        • How to convert currencies
        • How to get paid
      • Arrange a Bounty Program
      • Naming files and agreements
      • Risk management
        • Mattermost U.S. consulting agreements
      • Operations playbook
    • Security
      • Policies
      • Privacy
        • Data deletion requests
        • Data subject access requests
      • Product Security
        • Product Vulnerability Process
        • Working on security-sensitive pull requests
        • Secure Software Development guide
      • Security Operations
        • User guides
    • Workplace
      • PeopleOps
        • HR cadences
        • HR systems
        • HR Processes
        • Working at Mattermost
          • Onboarding
            • Things everyone must know
            • Staff onboarding
            • Engineer onboarding timeline and expectations
            • Manager onboarding
            • Frequently asked questions
          • Learning and development
          • Mattermost communication best practices
          • Paid time off
            • Out of office email example
          • Travel
            • Business travel insurance
          • Leaves of absence
            • Pregnancy leave
            • Baby bonding parental leave
            • Jury duty
          • Workplace program
          • Relocation
          • Total rewards
        • Performance reviews
          • Formal review process
          • New staff performance review
          • Informal review process
        • Transfers and promotions
        • Offboarding instructions for managers
        • People compliance
      • People policies
      • Groups
        • Staff Resource Groups
      • Approvals and iteration
      • IT
        • IT helpdesk
        • Hardware and software purchases
        • Hardware buy back policy
        • Software systems
  • Contributors
    • Contributors
      • Equity, diversity, and inclusion
      • How to contribute to Mattermost
        • Community Content program
        • Documentation contributions
        • Help Wanted tickets
        • Localization
        • Contribution events
      • Mattermost community
      • Contributor kindness
      • Community systems
      • Guidelines and playbooks
        • Social engagement guidelines
        • Contribution guidelines and code of conduct
        • Mattermost Community playbook
        • How to run a Hackathon
        • Hacktoberfest event organizer guide for Mattermost
    • MatterCon
      • Staff information privacy management
      • Mattermost events code of conduct
      • MatterCon2021
    • Join us
      • Ice-breakers
      • Help Wanted tickets
      • Localization
      • Mattermost GitHub sponsorship
      • Things candidates should know
      • Staff recruiting
      • Recruiting cadences
        • Product Manager hiring process
      • Exec recruiting
        • EA logistics
  • Help and support
    • Contact us
Powered by GitBook
On this page
  • Overview
  • Goals
  • Scope
  • Process Definitions
  • Responsible Parties
  • Vulnerability Sources
  • Vulnerability Severity
  • Remediation SLAs
  • Issue Types
  • Backport Policy
  • Process Steps
  • Report
  • Triage
  • Remediation
  • Release Preparation
  • Post Mortem
  • Responsible Disclosure
  • Responsibilities Matrix

Was this helpful?

Edit on Git
Export as PDF
  1. Operations
  2. Security
  3. Product Security

Product Vulnerability Process

Overview

This document aims to provide guidance on the handling of product vulnerabilities. It describes the process and provides background information and definitions for the daily usage of all relevant stakeholders.

Goals

Establish and document a way of working that ensures:

  • Vulnerabilities are triaged efficiently and quickly

  • All parties are aligned around ownership and expectations

  • Patch releases are available within the agreed SLAs

  • Minimize the risk for Mattermost Cloud, on-premises customers, and Mattermost, Inc.

Scope

This process covers any vulnerabilities found in officially published Mattermost products or services that were either found internally, reported to us by a customer, or come in through the bug bounty program or via another third party.

Infrastructure vulnerabilities are explicitly out of scope for this process. Vulnerability management, as it relates to infrastructure, is owned by the Security Operations Team.

Process Definitions

Responsible Parties

  • Product Security Team: Process Ownership; Vulnerability Owner

  • Development Team: Vulnerability Remediation

  • Release Manager: Release Planning

  • Release Team: Build Process

  • Marketing Team: Security Updates Email Newsletter Distribution

  • Security Operations: Vulnerability mitigation for Mattermost Cloud, verification whether it’s been exploited in Mattermost Cloud.

Vulnerability Sources

Vulnerabilities are reported from a variety of sources that are explained below.

Internal Finding

The vulnerability has been discovered by the internal security, development, or QA team.

Security Automation

The vulnerability has been discovered by internal security automation tools such as Dependency Track or CodeQL

Responsible Disclosure

Bug Bounty Program

Customer Report

The vulnerability has been reported from customers as part of an internal audit or on-going operations.

Public Leak

The vulnerability has not been officially reported, but released to the public without any notice. It is possible that it can contain reproduction steps or not.

Vulnerability Severity

Vulnerabilities must be scored according to the Common Vulnerability Scoring System Version 3.1 (CVSS 3.1). The CVSS is an industry-wide accepted standard to determine the impact of vulnerabilities in software products and takes impacts such as attack vector, complexity, user interaction, scope, and various other components into consideration. The Product Security Engineer may overwrite the CVSS severity if we think the risk to our customers is lower or higher than the calculated score. A justification must be provided in the vulnerability ticket.

FIRST provides a CVSS calculator at the following URL: https://www.first.org/cvss/calculator/3.1

The CVSS 3.1 provides a textural representation of the severity score in Section 5 of the Specification Document. The mapping is included below:

Rating
CVSS Score

None

0.0

Low

0.1 - 3.9

Medium

4.0 - 6.9

High

7.0 - 8.9

Critical

9.0 - 10.0

Remediation SLAs

Issue Types

Vulnerabilities must be assigned one of the following vulnerability types:

Backport Policy

For Mattermost server, the following backport policy applies:

Vulnerabilities with Low Score:

  • Upcoming Release

  • Extended Support Release

Vulnerabilities with Medium to Critical Score:

  • Upcoming Release

  • Extended Support Release

  • Last 3 Releases

Notes:

  • The Mattermost server policy also applies to vulnerabilities in bundled plugins within the respective version

  • There is no backport policy for Desktop, Mobile and standalone plugins.

Process Steps

Report

Vulnerability reports are received from internal or external parties via one of the methods outlined above. The Product Security Team must acknowledge to the reporter that it received the report within 48 hours on business days and will investigate whether it’s a valid issue.

After the report was received, a “Security Vulnerability” ticket must be created in the Jira ticket that contains the following information:

  • Title

  • Description

  • Category [If possible]

  • Reporter

  • Source

  • Component

The security engineer that acknowledges the initial report must create a Mattermost Playbook Run using the "Security Vulnerability Playbook" and follow the process steps documented to continue with the Triage step. The playbook links to the Jira ticket created above, ensures the right process steps are completed, and informs relevant parties.

If the vulnerability was published on a news site/blog/etc. and is considered a public leak the Head of Marketing and VP Legal should be notified and invited to the playbook run.

Triage

After a vulnerability report was acknowledged it must be confirmed whether it is a valid finding within 96 hours of receiving it on business days. The security engineer should determine:

  • Is the report a duplicate of a previous or current report from another reporter?

  • Does the report have a security impact?

  • Can the report be reproduced?

  • If neither of the above hold true, does the report have an impact on any production infrastructure or systems and thus should be reviewed nevertheless?

After confirming that the report is valid the Product Security Team member must move the report to the next stage, called “Remediation” and must fill in the following information in the ticket:

  • Vulnerability Category

  • Steps to Reproduce

  • Recommended Mitigation

  • Security Update Text

  • CVSS Score

  • CVSS Severity

  • Final Severity

  • Mattermost Team

  • Development Team

  • Playbook Run link

  • Bug Bounty Link

  • Affected On-Premises Versions [Text]

  • Affects Cloud [Yes/No]

Additional auto-populated fields

  • A Mattermost-specific vulnerability ID is automatically assigned when a report is moved from “Triage” to “Fix Development”.

  • A Due Date field is automatically populated when when a report is moved from “Triage” to “Fix Development” based on the Final Severity and the SLAs.

If the vulnerability is not confirmed valid or considered a duplicate, the security engineer must notify the reporter about the decision. If we don’t consider it a vulnerability, the justification for our decision should be included both in the response to the reporter and as a comment in the Product Vulnerability ticket. The ticket should afterwards be closed either as duplicate or as invalid.

If the report is deemed a security improvement (but not vulnerability), a development ticket should be created and the security vulnerability ticket closed with the development ticket added as a reference. A report is considered a security improvement when it is not exploitable without the presence of any additional vulnerabilities or only increases the general security posture.

Remediation

The Product Security Engineer must create a development ticket and link it to the vulnerability ticket. The Lead Engineer and the Product Manager of the feature team responsible for the vulnerability fix and the Release Manager should be invited in the vulnerability’s playbook run channel and be informed about the vulnerability and its severity. The Lead Engineer must acknowledge the report and assign the development ticket to an engineer. The Lead Engineer should work together with the Product Manager on the prioritization of the reported security vulnerability.

The development team is responsible for the development of the fix. The assigned Product Security Engineer is responsible to notify the developer teams if an agreed SLAs is at risk for the fix development and document once the SLA is broken. Developers should work together with the assigned Product Security Engineer during the vulnerability remediation to clarify questions and mitigation approaches. Once the development team finishes the development of the fix for the current version, the assigned Product Security Engineer should review that the fix properly mitigates the vulnerability. The fix must then be backported to previous releases. This is not the case if:

  • The affected feature did not exist in the version in question

  • The vulnerability has a low severity

If in doubt, refer to the Backport Policy section above. After the fix development has finished and has been reviewed by peers, security and QA, a new dot release must be prepared.

In parallel with the development of the fix by the Engineering team, the Product Security Engineer must invite in the playbook run channel the Security Operations team, if the vulnerability is of “High” or “Critical” severity or if cloud installations are at risk of exploitation. If cloud installations are at risk of exploitation, the Security Operations team must look at possible no-code mitigation steps to prevent the vulnerability from being exploited in the cloud until a fix is deployed. If the vulnerability is of “High” or “Critical” severity, the Security Operations team must investigate for any exploitation attempts with the guidance of Product Security. If exploitation is confirmed, a separate process will be triggered which is outside of the scope of this document. The Product Security Engineer may invite the Security Operations team to look for exploitation attempts for “Medium” severity vulnerabilities on a case by case manner.

Release Preparation

Post Mortem

The Product Security Engineer must conduct a post mortem using the provided template for any vulnerabilities with “High” or “Critical” severity. The Product Security Engineer and the Lead Engineer of the feature team responsible for the vulnerability fix should meet and discuss:

  • Why did this vulnerability occur?

  • How can we verify that the vulnerability doesn’t exist in other parts of the product?

  • What actions do we need to take to prevent it from happening again?

The outcome of the post mortem must be action items based on the answers to the questions above. The Product Security Engineer must then fill the retrospective of the playbook run based on the answers in the above questions and create backlog tickets with the agreed action items.

The Release Manager must create a draft for the email newsletter. The Marketing team and Product Security Engineering Lead must review the draft and send it out to all subscribers of the Security Updates mailing list.

Responsible Disclosure

This section is applicable if the vulnerability affects publicly released software artifacts.

Responsibilities Matrix

Product Security
Development Team
Release Manager
Security Operations
Marketing
SRE

Triage Vulnerability

x

Product Vulnerability & Development fix Jira tickets creation

x

Product Vulnerability Jira status progression & fields completion

x

Security Vulnerability Playbook run creation & administration

x

Vulnerability fix development

x

Discovery of exploitation attempts (High/Critical only)

x

Security Review of the fix

x

Notify the Release Manager for a new release version cut

x

Cloud Release Preparation

x

x

Self Hosted Release Preparation

x

Post Mortem discussion (High/Critical only)

x

x

Post Mortem documentation & action items Jira tickets creation (High/Critical only)

x

Email newsletter draft

x

x

Review newsletter draft & send it to the Security Updates mailing list

x

Release of the security update notes

x

Prepare and publish CVE

x

PreviousProduct SecurityNextWorking on security-sensitive pull requests

Last updated 6 months ago

Was this helpful?

The vulnerability has been reported through our .

The vulnerability has been reported through our .

Refer to this .

Bundled plugins are the plugins that are pre-installed in the Mattermost server. The list of bundled plugins can be found in Mattermost server's . Any other plugin is considered standalone.

After reviews have been completed, the developer must notify the Cloud SRE team and the Release Manager that a new cloud release version can be cut. Cloud rings soak times for patches with vulnerability fixes can be found in this . Once the cloud release patch with the fix has been rolled out in the cloud, the Release Manager must cut a new dot release for all versions that received the security fix and release it. In case there are any problems during the release, the Delivery team should be notified to fix potential issues.

After the new versions are released, the Release Manager must update the based on the Reporter field from the Jira ticket.

Once the versions with the vulnerability fix are released, the Product Security Engineer must verify that all required information is included in the initial vulnerability ticket. The Release Manager must publish the security update notes for the vulnerabilities that have been fixed and released in the page. No details must be added in the “Issue Details”. Instead the following message must be posted: “Details on the security update will be posted here on DATE, as per our Responsible Disclosure Policy.” The DATE refers to 30 days after the release day.

The Product Security Engineer must prepare for a CVE disclosure. Specifically the Product Security Engineer must create a JSON file with all the needed CVE information. A tool like can be used for this purpose. A CVE ID can be reserved using the library.

30 days after the release with the vulnerability fix, the Product Security Engineer must publish the CVE details using the library. At the same time, the release manager must update the security update notes for vulnerabilities released in the page, this time properly populating the content of the “Issue Details” column.

Update the

responsible disclosure program
Bug Bounty program running on Bugcrowd
internal matrix
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-352: Cross-Site Request Forgery (CSRF)
CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
CWE-287: Improper Authentication
CWE-284: Improper Access Control
CWE-400: Uncontrolled Resource Consumption
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
CWE-1395: Dependency on Vulnerable Third-Party Component
CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
CWE-922: Insecure Storage of Sensitive Information
CWE-319: Cleartext Transmission of Sensitive Information
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-918: Server-Side Request Forgery (SSRF)
Makefile
internal matrix
hall of fame list
Mattermost Security Updates
vulnogram
cvelib
cvelib
Mattermost Security Updates
hall of fame list