Security embargoes at Red Hat

The software security industry uses the term Embargo to describe the period of time that a security flaw is known privately, prior to a deadline, after which time the details become known to the public. There are no concrete rules (other than do not break the embargo, that is) for handling embargoed security flaws, but Red Hat uses some generally used security principles on how we handle them.

When an issue is under embargo, Red Hat cannot share information about that issue prior to it becoming public after an agreed upon deadline. It is likely that any software project will have to deal with an embargoed security flaw at some point, and this is often the case for Red Hat.

An embargoed flaw can be described as an undisclosed security bug; something that is not public information. Generally the group that knows about an embargoed security issue is very small. This is so the bug can be fixed prior to a public announcement. Some security bugs are serious enough that it can be in each party’s best interest to not make the information public before vendors can prepare a fix. Otherwise, customers may be left with publicly-disclosed vulnerabilities but no solutions to mitigate them.

Each project, researcher, and distribution channel handles things a little differently, but similar principles should still apply. The order is usually:

- Flaw discovered

- Flaw reported to vendor or project

- Vendor or project responds

- Resolution determined

- Communications plan agreed on

- Public announcement

Of course, none of this is set in stone and things (such as to whom the flaw is reported, or communications between a vendor and an upstream open source project) can change. The important thing to remember is that all who have knowledge of an embargo should maintain secrecy when dealing with embargoed security flaws.

If you’ve reported a flaw to Red Hat, but think that some of the information may have leaked, please contact Red Hat Product Security immediately. The Red Hat Product Security team will work with you to assess any inadvertent disclosure and determine the best way forward. For example, if you’ve filed a bug upstream that’s publicly visible before it was identified as a security vulnerability, we may need to determine if the embargo was broken.

It's not uncommon for a flaw to be reported to a third party before the news makes its way to Red Hat or upstream. This can be through a distribution channel, a security research company, a group like the United States Computer Emergency Readiness Team (CERT), even another corporation that works on open source software. This means that whilst Red Hat may be privy to an embargoed bug, the conditions of that embargo may be set by external parties.

Public disclosure of a security flaw will usually happen on a predetermined date and time. These deadlines are important as the security community operates 24 hours a day.

Contact Red Hat Product Security should you require additional help with security embargoes.