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 for handling embargoed security flaws, but Red Hat uses some industry standard guidelines 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 is easiest described as an undisclosed security bug; something that is not public information. Generally the audience that knows about an embargoed security issue is very small. This is so that the bug can be fixed prior to a public announcement. Some security bugs are serious enough that it’s in the best interest of all parties 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 the same principles still apply. The order is usually:
- Flaw discovered
- Flaw reported to vendor
- Vendor responds
- Resolution determined
- 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 most important thing to remember is that all who have knowledge of an embargo need to be discreet when dealing with embargoed security flaws.
Q: We reported a flaw to Red Hat but I think some info may have been shared publicly. What should we do?
A: Contact Red Hat Product Security at firstname.lastname@example.org. We will work with you to assess any potential leaks and determine the best way forward.
It’s not uncommon for a flaw to be reported to a 3rd 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 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.