Red Hat 계정으로 회원 프로필, 기본 설정 및 고객 상태에 따라 다음의 서비스에 액세스할 수 있습니다.
아직 등록하지 않으셨습니까? 등록해야 하는 이유:
- 한 곳에서 기술 자료 문서를 탐색하고, 지원 사례와 서브스크립션을 관리하고, 업데이트를 다운로드 할 수 있습니다.
- 조직 내의 사용자를 보고, 계정 정보, 기본 설정 및 권한을 편집할 수 있습니다.
- Red Hat 자격증을 관리하고 시험 내역을 조회하며 자격증 관련 로고 및 문서를 다운로드할 수 있습니다.
Red Hat 계정으로 회원 프로필, 기본 설정 및 자신의 고객 상태에 따른 기타 서비스에 액세스할 수 있습니다.
보안을 위해, 공용 컴퓨터 사용 중에 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.