You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Our Security Policy

Reporting a vulnerability

To report a vulnerability you can either email security /at/ spamassassin.apache.org or open a bugzilla issue being very careful to set the Component to Security so that it is not generally visible. If you create the bug report you will have access to it, as will the security team.

Security team process

Once a potential vulnerability is reported to the committers, and has been verified to be an issue, here's what to do (based on what we did for bug 5480):

  • Open a bugzilla Security bug to track the issue/discuss it; ensure discussion cc's security /at/ spamassassin.apache.org, not dev.
  • Generally figure out which version(s) are impacted by the issue.
  • Write up a general vulnerability statement explaining the issue.
  • Request a CVE. security /at/ apache.org last said to contact Mark J Cox <mark /at/ awe.com> to get a number.
  • Notifications are made in advance to the vendor-sec mailing list <vendor-sec /at/ lst.de> and anyone the committers feel like informing, as long as it is kept private. notifications contain the vulnerability statement, CVE info, and patch (if possible). (We may need to override on an issue-by-issue basis; for certain issues (e.g. remote root hole in the default configuration via malformed mail messages or something), we may want to keep these *extremely* secret and be very careful with vendor/packager notification.)
  • Public releases and announcements are made at an agreed upon time, ideally 1-2 business days after the notification to vendor-sec.
  • Tarballs are prepared "in secret" without committing anything to SVN or discussing on a public list.
  • patch is not committed to SVN until the tarballs are released to the public.

Additional guidance may be required. See http://www.apache.org/security/ for more information.

  • No labels