This is an old revision of the document!
Handling Security Issues
This document provides guidelines to report security issues in MantisBT, and describes the process we follow to deal with them internally.
For users
If you discover a security issue or what you think could be one, please
Open a new issue in our bug tracker following the guidelines below.
Set
Category to
security 1)
Make sure that
View Status is set to
Private 2) so that your report is not visible to the general public (only MantisBT developers will have access to it).
Set the Product Version as appropriate; if necessary (e.g. when multiple versions are affected), include additional information in the Description field.
Provide a descriptive Summary and clear Description of the issue
Do not forget detailed Steps To Reproduce to facilitate our work in analyzing and fixing the problem
If you already have a patch for the issue, please attach it to the issue
Should you wish to be credited for the finding, kindly indicate it under Additional Information or in a bug note. Your name/e-mail/company will be included in the CVE report
One of the core team members will review, reply, ask for additional information as required.
We will then discuss the means of fixing the vulnerability and agree on a calendar for disclosure. Generally this discussion takes place within the issue itself, but in some cases it may happen privately.
Note: do not submit a Github Pull Request or post on the mailing list, as these are public channels which would effectively disclose the security issue.
For developers
If you are notified of a security issue directly (e.g. by e-mail), start by logging the issue in the tracker as described in the section above.
Once the issue has been logged
Take ownership of the issue
Assign it to yourself
Update Priority and Severity as appropriate
Set Target Version to the next stable release (e.g. “1.2.x”)
Make sure it is indeed Private
Notify the rest of the core team about the vulnerability by adding them to the email thread / issue discussion (use the Send Reminder feature).
Propose a fix by
attaching a git patch to the issue
3).
The original reporter as well should test the fix to confirm resolution
If possible, at least one other MantisBT developer should review and test the fix as well
Once the fix has been tested
Feedback from the Reporter and a peer review confirm that the fix addresses the issue.
Agree with the reporter to a timeline for disclosure
Commit the fix to both the stable and development branches, and push to Github.
-
Once a CVE ID has been assigned, the bugtracker issue summary must be updated
-
Obtaining a CVE ID
Send an e-mail to the oss-security mailing list (does not require subscription) as per the following examples 1, 2.
The request must include:
description of the issue, including but not limited to
type, e.g. XSS, sql injection…
which area of Mantis are affected
potential consequences of exploiting the bug
indication on severity
affected MantisBT version(s)
link to MantisBT issue
optionally, information about the reporter (if available and they do not refuse to be quoted)
information about the patch (i.e. where it can be found, commit SHA)
optionally, attach the patch itself
Usually, the CVE ID gets assigned within one business day.