the security@ problem

[Michael Richardson]

I wrote up my thoughts about the security@ problem.
I put it here, and linked to the notes.
https://docs.google.com/document/d/1lCeCgcBVUYcENxf5mbrTlO75VWeIIW8sBRXqzaCg_gM/edit?usp=sharing

I paste it below:

Most open source projects of any non-trivial size have maintained an alias like secu...@example.org, (or security-officers@ ,) for the purpose of receiving vulnerability reports. The historical situation is that this is a simple alias (/etc/aliases) which expands to half a dozen people (the officers) who can review the report.
Reports will ideally be encrypted using an OpenPGP key named for the alias, with the officers each having the private key, so anyone in the team can decrypt.

There are a number of challenges to this model:
Some projects live on github, gitlab, codeberg, and effectively do not have
an email system on which an alias can be established. Receiving encrypted
email on hosted email systems is not impossible, but often difficult.

Although the number of OpenPGP users has grown in absolute terms, relative to
the growth of the Internet, and even just the growth of security researchers,
the number of reporters that know how to use OpenPGP has decreased. While a
few hosted email systems can support it, it’s not well known how to use it.

Some organizations have created a clear process of who and how to respond, it
can still be difficult to be sure that the reporter gets a timely response.
One clear response, vs sometimes a few fractured replies.

Issues can take some time to be analyzed and replied to. They can get lost.
Tracking is important. Trackers, however, might not be adequately private
for sensitive issues.

Many issues that are reported are often, not really issues, so there is a bit
of Boy-Who-Cried-Wolf effect.

Reporters often push for CVE numbers to be assigned, and are impatient.
The /etc/aliases mechanism can result in delivery failures as the most naive,
1990-era methods will result in SPF and DKIM failures. Additionally, files
and patches that are attached can run afoul of malware scanners. While some
projects have security officers who have run their own email systems for
decades, and know how to deal with this, this is not true for newer projects.

The security@ alias is a spam and malware target, and it is trivial to find
delivery is impaired when hosted mail systems see this spam being forwarded.
This includes being unable to reply to the original reporter, who more often
than not, uses some hosted email system.

Some projects have tried turning the security@ into a mailing list, which
helps with delivery, managing membership, and facilitating discussion among
security officers, new reports get moderated. This now requires someone to
regularly watch the spam/moderation queue, cleaning it out of junk. The
reporter often receives a confusing message about them not being allowed to
post.

Other projects have tried turning the securit@ into an entry into an issue
tracking system. From ancient but still reliable “RT”, Mantis, Redmine?,
Gitlab?, … there are many advantages to this when it works well. That
includes:
Issues are tracked by number
Reporter receives clear acknowledgement
Responses to reporter are shared and logged
Officers can usually interact with each other over this issue
Possibly integrated with source code management systems
Possibility to publish thread after patch
Ability to bring in downstream managers in a controlled way

The problem is that setting this up well takes some effort, and there are
often brittle parts that do not get regular exercise.

What could be done
Show and tell of systems that do the right thing
Better HOWTO for various self-hosted systems on how to make this work
Something something github something
A hosted service that any project could use
Better templates for reporters to use
More use of security.txt and other mechanisms to provide the right keys