Zachary Bobroff
Director, AMI Product Office
During a meeting on cybersecurity at the US White House last January, officials from Amazon, Microsoft, Google and other major tech companies called for increased investment in open-source security. This meeting took place on the heels of a series of cyberattacks, most notably the Log4j attacks targeting the prominent open-source library solution from Apache used by nearly every enterprise app and cloud service – including the tech leaders present that day.
Who Owns Open-Source Vulnerabilities?
News of these vulnerabilities brought an essential question about open-source software security to light: If no single entity “owns” open-source software, whose responsibility is it to patch and protect these solutions when vulnerabilities are exposed?
In the wake of this meeting, Google Chief Legal Officer Kent Walker clearly described this dilemma by saying:
“Open-source software code is available to the public, free for anyone to use, modify, or inspect. Because it is freely available, open source facilitates collaborative innovation and the development of new technologies to help solve shared problems. That’s why many aspects of critical infrastructure and national security systems incorporate it. But there’s no official resource allocation and few formal requirements or standards for maintaining the security of that critical code. In fact, most of the work to maintain and enhance the security of Open Source, including fixing known vulnerabilities, is done on an ad hoc, volunteer basis.
For too long, the software community has taken comfort in the assumption that open-source software is generally secure due to its transparency and the assumption that “many eyes” were watching to detect and resolve problems. But in fact, while some projects do have many eyes on them, others have few or none at all.”
The distributed nature of its ownership and development means that open-source solutions have inherent security risks. Since technically no one “owns” the code and there is no accountability to ensure its security, the industry generally views open-source software as relatively insecure compared to proprietary solutions. But because many eyes are monitoring open-source code, its distributed nature can be leveraged as a security tool.
Successful management of open-source security requires close monitoring and accountability – meaning leadership, coordination and collaboration to take charge of disclosing and fixing security vulnerabilities. In this way, security vulnerabilities can be discovered and remedied relatively quickly – if leadership is in place to take control of coordination and collaboration within the community to fix security gaps.
Driving Open-Source Security Forward
AMI is firmly committed to the open-source ecosystem and driving our industry forward through our development of Aptio® OpenEdition and MegaRAC® OpenEdition open-source firmware solutions. To help build transparency around open-source security, we have outlined core principles for safeguarding the future of those tools today:
- We monitor our open-source software for vulnerabilities: Some open-source projects are well-tended by their creators, while others are not. AMI open-source solutions are tightly controlled and monitored for security vulnerabilities by the same teams, using the same security methods as our proprietary solutions. We constantly monitor the security landscape to identify vulnerabilities and quickly fix issues needing remediation.
- We push security fixes to our partners before the public disclosure date: We offer private security patches for our users operating under SLA before these versions make their way to the public repos. This method gives our clients security updates before they arrive in the open-source community, giving dedicated AMI partners the chance to protect themselves before vulnerabilities become public.
- We treat security announcements as highly confidential until public disclosure: We require all partners to receive updates under a nondisclosure agreement as part of the SLA. As the Spectre class of vulnerabilities taught the security world in 2018, going public with a security patch can negatively impact late adopters by publicizing the vulnerability and exposing unpatched users. AMI counteracts this threat by pushing patches out early and often, protecting those in our sphere from vulnerability months before public disclosure of any vulnerability.
Commitment to Open-Source Security Best Practices
Open-source projects are an essential part of our shared digital future. But within the broader open-source community, ownership of security fixes remains somewhat undefined. At AMI, we are committed to maintaining our contributions to the open-source repository with security best practices at the forefront of our efforts. When we identify needed security fixes, we act swiftly and with high confidentiality to secure our partners’ software before news of the vulnerability is made public.
As always, for any questions about firmware security in Aptio and MegaRAC OpenEdition Firmware Solutions, please contact your regional AMI representative for assistance.