As membership in the team gives the individual access to potentially destructive information, membership is limited to people who have a proven track record in the Mautic community.

There are many ways to help the team that don't require access to confidential information:

• The most important help you can provide is to review proposed patches in Github with a security mindset.
• Report any issues you find and work with the team on a fix.
• Develop trust by meeting current security team members at real-world events and working with them on other team projects.
• Discuss and write about security best practices.
• Help out in the Github issue queue - consider joining the Triage Team.

Team members are expected to work at least a few hours every month. Exceptions to that can be made for short periods to accommodate other priorities, but people who can't maintain some level of involvement will be asked to reconsider their membership on the team.

How do you apply?

Send an email to [email protected].

The e-mail should include:

• How many hours you can commit to the team per month.
• A statement that you are willing to keep the confidential issues of the team confidential, and that you have read, agree to, and are willing to sign the security team disclosure policy
• Any relevant experience you have working on security issues. This should include
  • at least 5 issues you have worked on that are public security improvements in Mautic core.
  • At least 3 private security issues.
  • At least 30 issues you have worked on in public for Mautic core.
  • Please include a link to each issue.
• Whether you are already part of the Mautic Product Team and/or Core Team
• The kinds of work you'd like to do as a member of the security team
• The names of any security team members who can vouch for you
• Your favorite vulnerability and why

New Applicant Review process

1. An email is received from an applicant
2. At least 2 security team members validate the application and no security team members raise concerns about them joining . This can take up to 3 weeks.
3. The person is invited to help on specific issues in a provisional team member role to prove their commitment and appropriateness to joining the team
4. After some period of time being active on individual issues and proving to be trustworthy, the person is added to the team

We usually take 3-5 weeks to review new applicants. If you don't hear back after about 3 weeks, please send us a reminder email.

Improve Mautic’s security from outside the team

Before you apply or if you are not accepted at first, there are still many things you can do to improve the security of Mautic. In most cases, people are not accepted because the current team members don't know the applicant well enough. There are a few great ways to solve that problem.

As you do these things, please keep links to comments and PR’s that show your work for a future mail to the team showing your work:

• Do code reviews with a particular focus on security.
• Review the Documentation, Knowledgebase and Community Handbook, and improve or add resources relating to security
• Work on issues tagged with security improvements
• Attend a MautiCamp or MautiCon and talk with any security team members in attendance. Ask them questions about their experience and talk about your interests related to security.

Security Team Disclosure Policy

In general, information shared within the Mautic Security Team should only be shared outside the team on a “need to know” basis. If knowledge of team information will allow actors to create a patch or provide direct support to the security team in fixing an issue, this satisfies “need to know” and the actors should be invited directly to the issue. Offering team information to give actors advance knowledge of a supported patch release does not satisfy “need to know” (e.g. letting an organization know about a zero day for purposes of operational preparedness).

In the course of their duties on the Security Team, members should:

• Minimize risk that issues will be leaked beyond the team and posted to the public, outside of the release window and before a patch is released.
• Avoid creating a situation where people use still-private knowledge gained on the team to get an unfair advantage with no regard for the health of the Mautic ecosystem.

Receiving employer-sponsored time on security issues

If a team member wants to get sponsored time from their employer to spend more time moving the issue forward, it’s appropriate to provide their manager with a statement like “there is a serious vulnerability that affects code we frequently use. I would like to spend six hours working on it to help write a patch.”

However, do not give details as to what the exact security issue is.

Enlisting expertise or help from outside the Security team

If a team member wants to enlist the help of a colleague who has expertise in the area that is affected, it’s appropriate to add them directly to the issue so the colleague can review and collaborate with the team. Security team members should confirm a person is approved to contribute to the issue by asking at least one other team member (who does not work at the same company/organization) before inviting that person to the issue.

If you feel the need to discuss an issue to help resolve the issue, it is generally acceptable to share the following information with a colleague or community member outside of the security team:

• Any information that is already public, e.g. a release window.
• The numeric criticality of the issue (e.g. 20/25).

It is generally not OK to share outside of the Security Team:

• The specific aspect that is affected (e.g. Campaigns, Assets).
• The nature of the vulnerability (e.g. SQL Injection, XSS).
• Specific ways to mitigate the issue.
• Any other details related to the vulnerability or the sites it might affect.

Publicizing Security Team membership or issues

Do not use private information gained via the security team, or privileged access to that private information, for marketing purposes. In other words, marketing people should not write posts about your activity. Do not allow your company to market the fact that you have advance access to information. Instead, focus marketing on how contributing to the team has improved your organization’s handling of security issues across a wide variety of situations. This is not to conceal that you have access to team information, but rather to prevent misunderstandings when non-technical people read and write about technological topics.

If your use case is not covered in one of the above examples, ask the team: [email protected].

A security team member can request an exception to this policy by emailing the security team. The security team member should include, why they want the exception, how the exception benefits the Mautic community, and how they will mitigate the risk if any is created by the exception. The security team will make allowed exception requests public at a time when there is no risk to doing so. When deciding on exception requests, team members should indicate if they have a conflict of interest (COI). If there is no consensus, the request will be escalated to the security working group.

Conflict of Interest Policy when adding team members

If you comment on an application to become a team member AND you have a potential conflict of interest (a few examples: you are a coworker of an applicant, or contractor for the employer of the applicant, or employed by a competitor of the applicant) then you should explicitly disclose that fact prior to casting a vote. You should also give specific reasons why you think the person is or is not a good candidate (this is true regardless of any conflict of interest).

Security team members

The current list of security team members can be viewed here.