Open Source Computer Security Incident Response Team
The oCERT project was started in March 2008 and concluded in August 2017.
The oCERT was a public effort to provide security vulnerability mediation
for the open source community, maintaining reliable security contacts between
registered projects and reporters that needed to get in touch with a specific
project regarding infrastructure security issues or projects vulnerabilities.
The project was announced at the CanSecWest conference in March 2008, many years before bug bounties or efforts like Google Project Zero were introduced. The oCERT effort was very much ahead of its times.
The idea spawned from the quite obvious need for coordinated vulnerability investigation and disclosure among open source projects, particularly with multiple libraries statically included by a vast number of software.
To this end Andrea Barisani and Daniele Bianco from Inverse Path along with Will Drewry and Tavis Ormandy from Google, decided to create oCERT. The team was assisted by an advisory board with Solar Designer and Dragos Ruiu as members.
The project contributed 61 advisories covering vulnerabilities ranging from single project bugs, to critical findings affecting core libraries and numerous projects sharing their code, up to entirely new classes of vulnerabilities affecting multiple programming languages.
The oCERT project was sponsored by Inverse Path and Google with hosting kindly provided by the OSU Open Source Lab.
oCERT was authorized to use the CERT mark by Carnegie Mellon University's Software Engineering Institute; however, oCERT has never been otherwise affiliated or endorsed by Carnegie Mellon University or its CERT Coordination Center.
All published advisories are archived here.
All membership requirements and responsibilities were publicly known.
Distribution was determined in two ways, registered
vendors/maintainers and extracted Open Source project contacts
from authoritative resources like code.google.com/sourceforge/rubyforge/etc where applicable.
oCERT agreed to keep things moving efficiently, acknowledging that long or
moved embargo dates can have significant impact on vendors, users and open
disclosure and will be avoided where possible.
All bug/incident timeline and discussion summary were made
public after an embargo date. The embargo was optional and applied only
when considered necessary for appropriate coordination, reports were released
as early as possible and in any case embargo was not longer than 2 months.
The following time frames regulated oCERT embargo proposals:
* 7 days, in case the issue is already well narrowed down and tested, requiring trivial configuration and/or code change
* 14 days, standard embargo for most cases
* 30 days, in case of critical and complex vulnerabilities (example, trivial exploitation of administrative privileges on a static library affecting a large number of packages), and with the agreement of all parties
* under extremely exceptional circumstances, if the oCERT Team and all the parties involved felt the need for longer time, a 2 months embargo was applied, in this case we would clearly document the decision for public review
* in any circumstance reporter preference was always honoured in case a joint agreement was not reached, as oCERT would be anyway unable to force its embargo