《Linux基金會：2025開源網絡安全最佳實踐之路研究報告（英文版）（33頁）.pdf》由會員分享，可在線閱讀，更多相關《Linux基金會：2025開源網絡安全最佳實踐之路研究報告（英文版）（33頁）.pdf（33頁珍藏版）》請在三個皮匠報告上搜索。

1、Pathways to Cybersecurity Best Practices in Open SourceHow the Civil Infrastructure Platform,Yocto Project,and Zephyr Project are Closing the Gap to Meeting the Requirements of the Cyber Resilience ActMarch 2025Mirko Boehm,PhD,The Linux FoundationHilary Carter,The Linux FoundationCailean Osborne,PhD

2、,The Linux FoundationForeword by Miriam Seyffarth,Open Source Business AllianceSPONSORED BY:The CRA introduces regulatory oversight on products with digital elements(PDEs),with important implications for OSS development across stakeholder groups.The CRA defines a new role of OSS steward,which are or

3、ganisations that systematically support the development of open source technologies which they do not monetize.Under the CRA,OSS stewards are responsible for cybersecurity policy,processes for handling&reporting vulnerabilities,cooperation with MSAs,&voluntary security attestations.Open source proje

4、cts need to establish a 5-year security roadmap,investing in PSIRT teams&security policies to prepare for CRA timeline requirements.Standardized security tooling accelerates CRA compliance,with SPDX 3.0,OpenSSF Scorecard,&OpenChain frameworks helping projects implement security best practices.Semant

5、ic versioning helps manufacturers track CRA compliance by mapping substantial modifications,minor updates,&bug fixes to clear versioning.SBOMs must provide greater granularity,as file-level tracking improves security visibility,risk assessment,&vulnerability response for manufacturers.Open source se

6、curity requires cross-industry collaboration,where manufacturers,governments,&projects co-develop policies,fund security,&ensure long-term software maintenance.The CRA presents an opportunity to strengthen OSS security by improving security practices,documentation,and collaboration across the ecosys

7、tem.AI introduces new security risks,requiring frameworks to mitigate threats from AI-generated code&poisoned training datasets.Leadership drives open source resilience,as project maintainers,directors,&steering committee members must actively build cultures of security through advocacy&outreach.The

8、 Linux Foundation&OpenSSF support CRA readiness by helping developers,manufacturers,&stewards align with cybersecurity regulations through collaboration&best practices.Copyright 2025 The Linux Foundation|March 2025.This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 Inte

9、rnational Public LicenseContentsForeword.4Executive summary.5Introduction:A policy challenge confronts the open source ecosystem .6Methodology.7The EU Cyber Resilience Act:What open source stakeholders need to know.10Key CRA conceptsCoverage of open source software in the CRAKey requirements of the

10、CRA for stewardsDue diligence when integrating open source components into commercial productsCase studies:Leading projects in CRA readiness and cybersecurity best practices .14Civil Infrastructure PlatformYocto ProjectZephyr ProjectInsights from the Stewards and Manufacturers Amsterdam Workshop .22

11、Conclusion:Strengthening Open Source Security and CRA Readiness .24Resources.29Endnotes.31Acknowledgments .31About the authors .324PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEForeword When the Cyber Resilience Act(CRA)regulation was drafted in 2023,the common fear among open source develo

12、pers at the time was that the new regulation might unintentionally harm global open source projects.Open source advocates and lawmakers subsequently engaged in a productive dialogue to build a mutual understanding of the open source ecosystems complexities.This effort was eventually crowned by succe

13、ss:The CRA now takes the different commercial and volunteer actors in the open source ecosystem into account.And the open source community learned once more that together we can make things happen.Many open source organizations are keeping this momentum going and are translating it into efforts to m

14、ake open source businesses,foundations,and communities CRA-ready.Many remember the spring of 2018 when the full compliance with the then new General Data Protection Regulation(GDPR)went into force seemingly overnight.Most organizations simply had not used the time until that date to prepare and beco

15、me compliant.The open source community at large seems determined to not repeat this mistake with the CRA.Organizations like the Linux Foundation,the Open Source Busi-ness Alliance,and many others are currently developing guid-ance materials to help everyone in their respective communities understand

16、 what they have to do to become CRA-compliant.This common effort is quite needed,as the CRA comes with challenges and opportunities alike.The CRA introduces for example new roles like the open source software steward.Open source developers have to grapple with these new concepts to understand how th

17、e requirements differ for manufacturers and software stewards and which of these roles apply to them.The new report Pathways to Cybersecurity Best Practices in Open Source”by the Linux Foundation promotes better under-standing of the CRA and helps to alleviate prevalent worries and uncertainties in

18、open source communities.Despite these challenges and uncertainties,we should however also use the new regulation to confidently point out the advan-tages of open source.Generally speaking,open source software has quite the lead on other software when it comes to transpar-ency and the potential to fu

19、lfill the CRA requirements.Already today some open source projects are going above and beyond what the CRA is asking,with the case studies in this report being a testament to this.There is still a lot to do until the CRA comes into full force in 2027.While some open source projects are already prepa

20、red for the CRA,others are not yet ready to fulfill its requirements.We should therefore do what we do best:cooperate,share knowledge,and support each other.Together we can spearhead global efforts to make software development and distribution more secure.This report contributes to this bigger effor

21、t,spreads awareness,and gives valuable recommendations.I hope that readers will be inspired by the featured projects and their leadership teams and that they will engage in their respective open source com-munities to ensure open source security and sustainability.Lets go and get CRA-ready!MIRIAM SE

22、YFFARTHHEAD OF POLITICAL COMMUNICATIONSOPEN SOURCE BUSINESS ALLIANCE5PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEExecutive summary:Cyber resilience in open sourceThe European Unions Cyber Resilience Act(CRA)presents a watershed moment for the open source ecosystem,imposing rigorous cybers

23、ecurity requirements on products with digital elements(PDEs)commercialized in the EU.While the regulation will not fully apply until December 2027,with certain provisions taking effect earlier,the stakes are enormouspenalties reach-ing 15 million or 2.5%of global annual turnover for non-compli-ance.

24、The Linux Foundations analysis of three flagship projectsCivil Infrastructure Platform(CIP),Yocto Project,and Zephyr Proj-ectreveals both the readiness and challenges facing open source software stewards under the new regulatory framework.The CRA introduces a novel distinction between commercial man

25、ufacturers who bear primary responsibility for product compliance,and open source software stewards who develop and maintain open source software without monetization.This acknowledges the reality that open source components often constitute up to 96%of modern software while respecting the fundament

26、al openness of the development model.Each project examined demonstrates advanced security practic-es that align substantially with CRA requirements.For example,CIP has pioneered adoption of IEC 62443-4-1 industrial cyberse-curity standards.Yocto Project provides reproducible builds that create indep

27、endently-verifiable paths from source to binary code.Zephyr functions as a CVE Numbering Authority with an established Product Security Incident Response Team.All three implement robust vulnerability management processes,though the mandatory five-year support window exceeds some proj-ects current lo

28、ng-term support commitments.The regulations impact extends beyond documentation and vulnerability reporting.It fundamentally alters the relationship between upstream open source projects and downstream com-mercial adopters,demanding greater collaboration for sustain-able security maintenance.Neither

29、 manufacturers nor stewards can meet CRA requirements in isolationmanufacturers must conduct due diligence when integrating open source compo-nents,while stewards must implement and document cyberse-curity policies that facilitate secure development.Challenges remain significant.Some industrial syst

30、ems have lifecycles spanning 30 to 50 years,far exceeding typical soft-ware support periods.Standardization gaps persist,particularly around software bill of materials(SBOM)formats and consistent naming conventions for vulnerability tracking.The regulation also introduces considerable uncertainty re

31、garding which entities qualify as stewards and how they should handle market surveillance authority(MSA)requests.The Linux Foundation and Open Source Security Foundation have launched initiatives to address these challenges,focusing on standards development,awareness building,and tooling improvement

32、.Key recommendations include adopting semantic versioning to communicate when substantial modifications trig-ger new conformity assessments,integrating security practices into development workflows,generating standardized SBOMs,and implementing automated security scanning.Beyond technical solutions,

33、leadership emerges as the critical factor in cybersecurity readiness.Projects with visible,advo-cating leaders attract attention,resources,and institutional support essential for long-term security improvements.As reg-ulation creates a more stringent operating environment,such leadership will determ

34、ine which projects thrive.6PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEThe CRA represents not merely a compliance burden but an opportunity to strengthen cybersecurity across the digital eco-system.Despite initial implementation challenges,it establishes a framework where security becomes

35、 an explicit priority rather than an optional consideration.If properly implemented with appropriate collaboration between manufacturers,stewards,and regulators,it may achieve its ambitious goal of“playing a leading international role in the field of cybersecurity”while preserving the innovation eng

36、ine that open source development represents.Introduction:A policy challenge catalyzes the open source ecosystem Today,there is a new impetus for greater collaboration between the communities that develop open source software and the downstream users of that software.That impetus is the Cyber Resilie

37、nce Act(CRA)1,recent legislation in the European Union(EU)whose impact on manufacturers,maintainers,and open source stewards will be significant.This report is among the numerous initiatives of the Linux Foundation to prepare stake-holders for the changing global cybersecurity policy landscape.The g

38、oal of the CRA is to establish cybersecurity requirements for devices and software commercialized in the EU.While the language of the CRA is confusing in some areas,it has nonethe-less passed into law,with some parts in force by 2026 and full compliance in force by 2027.The penalties for failing to

39、comply with the CRA are steep,as high as EUR 15 million or 2.5%of global annual turnover,whichever is higher.As the proverbial clock for parties subject to the CRA is now ticking,the time to shore up compliance is now.But what is needed for compliance,and where do stakeholders begin?Under the CRA,th

40、e cybersecurity and fitness for purpose of a product-specifically a product with digital elements(PDE)-falls under the responsibility of downstream manufacturers.2 Most PDEs build on a foundation of open source components that often make up the majority of software in a device,reported in some insta

41、nces to be as high as 96%.3 In order to maintain the software in PDEs in an efficient and agile fashion,manufac-turers will have to rely on and consume documentation,col-laboration processes,and other support measures offered by upstream open source communities.While the CRA prescribes little about

42、this relationship between downstream manufactur-ers and upstream open source projects,this relationship will be crucial for manufacturers to comply with long-term support and rapid cybersecurity response requirements imposed by the CRA.To make the situation more complex,release cadences,quality assu

43、rance practices,data formats and many other aspects of the software supply chain may differ between different open source projects and the downstream manufacturers processes.The good news is that a number of widely used open source projects have long taken cybersecurity seriously.Many projects have

44、reliable,well-documented development and collaboration practices.They have invested considerable effort into support-ing their downstream users in the adoption of their software.And since all of these aspects are implemented in an open source environment,downstream users have the opportunity to stud

45、y them as good practises or even to adopt the same(or similar)time-tested tooling and processes for their own devel-opment.This is particularly true for open source projects that are intended to serve as the pre-competitive layer for creating devices or products,including operating systems and const

46、ruc-tion kits for device software.7PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEIn this report,we narrowed our focus to three widely used open source projects hosted at the Linux Foundation,each recog-nized for their security practices and,following a methodical research process,held up as

47、 effective stewards under the CRA and beyond it.The first project,the Civil Infrastructure Platform:Industrial Grade Linux(CIP)project,provides a base layer of industrial grade core open source software components,tools,and methods to create Linux-based embedded systems that meet the safety,reliabil

48、ity,and other requirements of modern municipal infrastructure and industrial automation.The second is the Yocto Project,the de-facto industry standard“tool kit”for building custom embedded Linux operating systems,regard-less of the hardware architecture.Third,the Zephyr Project is a real-time operat

49、ing system optimized for resource-constrained devices that supports multiple computer architectures.With cooperation from key contributors to these projects,this report captures both the extent to which their practices match the requirements of the CRA for stewards and where there may be potential g

50、aps,but also identifies the areas in which these critical projects go above and beyond the CRA requirements and push cybersecurity further than required by the new regulation.From these collective insights,combined with a textual analy-sis of the CRA and insights from other stakeholders described in

51、 the methodology below,this report provides a number of recommendations regarding what actions other open source projects and stakeholders can take,and which priority areas to focus on.We hope that these insights inspire other open source proj-ects and leaders to better understand their own cybersec

52、urity posture vis-a-vis the requirements of the CRA,and to take the necessary actions to improve them.Through greater collective understanding and collaboration,not only is there a pathway to achieving CRA compliance,but there has never been a greater opportunity to further the resilience,sustainabi

53、lity,and security of open source software.MethodologyThis report is intended to provide orientation,guidance,recom-mendations,and inspiration to practitioners,manufacturers,and open source software stewards in terms of improving their overall cybersecurity posture and readiness for the CRA.It com-bi

54、nes an analysis of the CRA text,a review of the cybersecurity practices of key open source projects,qualitative insights from interviews with project stakeholders from three Linux Founda-tion hosted projects,and considers takeaways from workshops and stakeholder engagements like the December 2024 St

55、ewards and Manufacturers Workshop.We describe each in detail below.Textual analysis of the CRAThe analysis of the CRA is based on the CRA text as published by the EU Council on 23 October 2024.4 It discusses the economic actor roles referenced in the law that are relevant to the work-ings of the ope

56、n source ecosystem,and reviews the relation-ships between them.In particular,the analysis investigates the explicit and implied relationships between economics actors.8PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEThe CRA explicitly describes the relationships between manufac-turers and con

57、sumers,manufacturers and market surveillance authorities(MSAs),and open source software stewards and MSAs.The CRA implies,but does not prescribe in detail,the rela-tionship between open source software stewards and manufac-turers.It also does not provide much detail on the relationship of unincorpor

58、ated open source communities,individual maintain-ers or contributors with downstream manufacturers or users of the software.Where possible,we attempt to bridge these gaps based on the practices and governance norms typically applied in Linux Foundation projects.The textual analysis concludes with a

59、brief summary of the obligations of the different actors imposed by the CRA,including an overview of which activities that are covered by the CRA and which are not.Qualitative interviews with CIP,Yocto Project,and Zephyr Project leadersNext,through qualitative interviews with key contributors,we rev

60、iewed the cybersecurity practices in three essential open source projects:Civil Infrastructure Platform,Yocto Project,and Zephyr Project.The qualitative interviews were guided by the following primary research questions:1.What is the current state of cybersecurity best practices,documentation,and su

61、pport processes in your open source project commonly used in products that will fall under CRA scope?2.How do the roles and obligations defined in the CRA map onto cybersecurity best practices in the relationship be-tween open source communities and downstream manufac-turers?3.What organizational an

62、d technical measures should open source stewards and manufacturers implement to enable efficient CRA compliance?While many projects under the Linux Foundation umbrella have prioritized cybersecurity best practices,these specific projects were chosen from the Linux Foundations large portfolio as repr

63、esentative examples of how open source communities can embed security into their development lifecycles as a means to improving not only their security posture,but to meet the requirements of stewards under the CRA.Having invested significant effort into their cybersecurity,quality assurance,and doc

64、umentation practices,they are widely recognized for their strong cybersecurity posture and long-term commitment to security best practices.In addition,each project serves as a foundation for numerous downstream products,giving them a particular impact on the state of cybersecurity across the globe.C

65、rucially,key contributors from each project were available and willing to collaborate on this report,providing firsthand insights into their security strategies.For these reasons,their selection as case studies allows us to highlight concrete practices and lessons learned that other projects and ind

66、ustry stewards may consider adopting,and give us confidence that the recommen-dations drawn from this research represent the state of the art of cybersecurity best practices.While these three projects offer valuable perspectives,it should be noted that the conclusions about cybersecurity best practi

67、ces cannot be easily generalized,as these three projects do not rep-resent the whole open source ecosystem in all its nuances,nor do they encompass the full spectrum of open source security approaches,nor are they the only LF projects in a strong position for CRA compliance.For example,all three pro

68、jects represent lower-level platforms providing operating system components including an operating system kernel.Other projectssuch as Kubernetes,SPDX,or OpenSSF initiativescould have provided 9PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEdifferent angles on CRA readiness.Nonetheless,our s

69、ample pro-vides a meaningful cross-section of approaches to cybersecurity and compliance in open source software development.We hope that they provide useful guidance as a starting point for a wide variety of open source community stakeholders.In the respective project case studies,we analyze their

70、classifi-cation under the CRA,how their current practices compare to what will be required by the CRA,what steps may be needed to close the gap between current practice and CRA obligations,and where current practices cover cybersecurity needs not refer-enced in the CRA or go beyond the baseline requ

71、irements of the CRA.Insights from stakeholder workshops with stewards and manufacturersThe Linux Foundation,embracing its role as a leading open source software steward,is actively engaging manufacturers and open source projects in the implementation of the CRA.To advance the communitys understandin

72、g of the respective roles and responsibilities of stewards and manufacturers the Open Source Security Foundation(OpenSSF)and Linux Foundation Eu-rope jointly held the Open Source Software Stewards and Manu-facturers Workshops shortly after the official publication of the CRA in December 2024.These w

73、orkshops convened 50 leaders from across the Linux Foundation,other upstream open source foundations,community experts,and government officials.5 The group shared understandings of the obligations of both manu-facturers and stewards,and explored opportunities for greater collaboration over the cours

74、e of the next three years,as the CRA ultimately comes into effect.In the plenary and workshop sessions,the participants charted the road to implementing the CRA through three thematic work streams:1.Awareness:Exploring pathways to building greater aware-ness of the CRA,its timelines,requirements,and

75、 overall readiness for when the legislation comes into force;2.Standards:Mapping the formalization and standardization of community best practices into recognized specifications,as well as developing processes;3.Tooling:Identifying the formats and tooling that support software supply chain flows,and

76、 identifying opportunities for greater impact.The workshop was both a catalyst for the establishment of the Global Cyber Policy working group under the OpenSSF,and also validated many of the themes raised during the qualitative inter-views.This information ultimately influenced and reinforced the re

77、commendations of this report.Through the above empirical approaches,this reports findings are intended to accelerate the necessary actions for open source project communities to implement the essential requirements of the CRA,as well as create broader awareness of the best practic-es that make all s

78、oftware more secure.10PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEThe EU Cyber Resilience Act:What open source stakeholders need to know The CRA is a landmark piece of legislation which aims to improve cybersecurity across the board for the internal EU market and world-wide.It aims to ach

79、ieve three policy goals(Recital 2):1.To reduce the number and severity of vulnerabilities in digital products;2.To ensure that cybersecurity is maintained throughout a well-defined products life cycle;3.To enable users to make informed decisions based on cybersecurity criteria when selecting and ope

80、rating digital products.These requirements apply to all products with digital elements,covering software,hardware,or a combination of both,if they are commercially made available in the EU market.Assuming that international manufacturers as well will respond with stronger cybersecurity practices to

81、be able to offer their prod-ucts in the EU,the law aims to improve baseline cyber security globally.With this horizontal and mandatory approach,the EU requires all products with digital elements commercially available in the EU market to adhere to minimum cybersecurity standards,introduces sweeping

82、vulnerability reporting requirements,and imposes a mandatory support period for security fixes,typically five years or longer.While the scope of the CRA is clearly the in-ternal EU market,its ambitions extend beyond Europe,as stated in Recital 7 of the laws introductory text,where it states it aims“

83、to play a leading international role in the field of cybersecurity.”6 The CRA aligns with broader global trends,as other jurisdictions implement cybersecurity regulations with similar goals.For ex-ample,the U.S.Cyber Trust Mark program and IoT Cybersecurity Improvement Act,Singapores Cybersecurity L

84、abelling Scheme,Japans Cybersecurity Strategy,and Australias Security of Criti-cal Infrastructure Act all reflect growing international efforts to strengthen the security of digital products and infrastructure.After entering into force on 11 December 2024,a three year im-plementation period will beg

85、in during which additional guidance will be communicated.In particular,European standards will be adopted that elaborate the essential cybersecurity require-ments in general and for specific types of products in particular.Manufacturers will refer to these standards to indicate confor-mity of their

86、products with the CRA requirements with the CE mark.As stated in Article 71,most obligations introduced by the CRA will apply from 11 December 2027,however manufacturers need to be aware that the reporting obligations concerning ac-tively exploited vulnerabilities and severe incidents will apply 11

87、September 2026,and the provisions on notification of conformi-ty assessment bodies beginning 11 June 2026.11PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEUnderstanding the Cyber Resilience Act:Core definitions and frameworksThe CRA introduces a number of novel approaches to cyber-security r

88、egulation which will likely have a significant impact on digital supply chains.Some of them are novel compared to prior regulation,like the idea of products with digital elements.Others represent concepts that reflect the new dynamics of software development to account for the changes introduced by

89、open source software development.In this chapter,we highlight selected concepts in the CRA that manufacturers and open source projects need to be aware of.Products with digital elementsProducts with digital elements(PDEs)define the scope of prod-ucts covered by the CRA.7 PDEs include software or har

90、dware products,no matter if they are placed on the market as devices that integrate software and hardware or separately(Article 3(1).The CRA only applies if the PDEs intended purpose or reason-ably foreseeable use includes a direct or indirect logical or phys-ical data connection to a device or netw

91、ork(Article 2(1),but this applies to many products.PDEs also include their remote data processing solutions to the extent that they are necessary for their function(Article 3(2).Software is defined as those parts of a product based on computer code(Article 3(4),while hardware includes all physical c

92、omponents(Article 3(5).The definition of PDEs does not differentiate between open source software and other products.Instead,obligations differ based on whether PDEs are made available in the market with commercial intent or not,as discussed in more detail below.Making products commercially availabl

93、eThe CRA defines the“making available on the market”as the supply of a PDE in the course of a commercial activity(Article 3(22).It further defines“placing on the market”as the first such making available of a PDE(Article 3(21).In the digital world,“placing on the market”can be understood as the init

94、ial release or introduction of a new product,while later software or hard-ware updates would be“made available.”It may be necessary to relate this terminology to the development practices of manu-facturers and open source projects.The recitals clarify that supply in the course of a commercial activi

95、ty is not limited to charging a price for the product,but also includes indirect monetization,for example,through the acquisition of consumer data or other mechanisms.Anoth-er essential concept that the CRA introduces piecemeal and without a definition in Article 3 is that of provisioning software w

96、ithout commercial intent.For example,the provision of open source software that is not monetized is not considered to be a commercial activity(Recital 18).In contrast,making products available means supplying them for distribution or use in the course of a commercial activity.This distinction does n

97、ot change the nature of what is being supplied,as in closed source or open source products or related services.Instead,it assigns roles and responsibilities to manufacturers(and to a limited extent to oth-er actors)based on the commercial character of their activities.Monetization includes direct mo

98、netization,whereby a price is charged for a software license or device,as well as indirect monetization,as for example in acquiring user data from the use of software provided free of charge.It can be expected that what constitutes indirect monetization will be a subject to some debate,however it is

99、 clear that practices common today like the provision of software development environments or web brows-ers as sales channels for user account subscriptions fall under it.Indirect monetization also includes accepting donations that exceed the costs associated with the design,development and provisio

100、n of a product with digital elements.Accepting dona-tions without the intention of making a profit,however,is not considered to be a commercial activity(Recital 15).12PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEManufacturers and Open Source Software StewardsThe CRA is the first EU regulat

101、ion that explicitly differentiates the roles of manufacturers and open source software stewards.Manufacturers are those originally responsible for making a product with digital elements commercially available in the EU market.Open source software stewards(or stewards,in short)are organizations that

102、systematically support the specific devel-opment of open source products and ensure their viability.This distinction reflects an important market reality:Stewards make open source software available to anybody for any pur-pose,without necessarily engaging directly with the users of their products.Wh

103、ile stewards usually do not know exactly or to a full extent how widely their software is used,they provide essential open source software building blocks that are widely used to make up the majority of code on most modern digital products.An important cornerstone of the open source ecosys-tem is th

104、at users of the software do not need to request per-mission from or register their use with the upstream software communities.Nor are the open source software components provided by stewards monetized or commercialized by them.In-stead,stewards are typically financed by donations or member-ship fees

105、 that facilitate their operations and do not constitute a payment for using the software.With this in mind,it would be close to impossible for stewards to shoulder the responsibili-ty for the cybersecurity capabilities of the software that they provide free of charge.The CRA recognizes this challeng

106、e and places the responsibility to perform due diligence evaluations for the fitness for purpose of an open source component in a particular commercial product firmly with that products manu-facturer.Similarly to the typical open source development process,the intended relationship between manufactu

107、rers and stewards is based on voluntary participation and cooperation.Manufactur-ers are encouraged to ensure the viability of their open source dependencies via the requirements to provide security updates for their products over extended periods of time.Stewards are encouraged to provide release a

108、nd vulnerability documentation with their products.The CRA for the most part leaves it to the market to shape this future manufacturer-steward relation-ship,hinting however that manufacturers should assume their shared responsibility for the viability and maintenance of their open source dependencie

109、s.Coverage of open source software in the CRARecital 18 makes reference to the provision of products with digital elements qualifying as free and open source software(FOSS).Such products should only fall within the scope of the CRA if they are monetized by their manufacturers and supplied in the cou

110、rse of commercial activities.Participating in the devel-opment,maintenance,or distribution of open source software-including via online platforms-does not constitute in itself a commercial activity,regardless of how the development is funded or structured.Additionally,contributions to open source pr

111、ojects under somebody elses responsibility and the work of nonprofit organizations developing open source software are not considered to be commercial activities.This important clause should provide certainty to participants in open source projects and communities that their contributions to those a

112、re not covered by the CRA.The CRA does not pose a barrier to making contributions to existing open source projects.Manufacturers develop or manufacture products with digital elements or have them designed,developed or manufactured.Open source software stewards(aka stewards)are organisations other th

113、an manufacturers that systematically support the development of specific open source products and ensure their viability.13PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCENo explicit open source exemptionRather than providing a broad exemption for open source soft-ware,the CRA introduces an e

114、xemption specifically for software that is provisioned without commercial intent.This distinction has significant implications.Single-vendor open source compa-nies,for example,may not fall under the concept of“provision-ing”without commercial intent,as it can be assumed that all activities conducted

115、 in the regular course of business are driven by commercial objectives.Furthermore,offering consulting or other services related to open source components developed and owned by the same entity could be interpreted as a form of indirect monetization,potentially bringing such companies within the sco

116、pe of CRA requirements.The CRA does not reference the open source definition as main-tained by the Open Source Initiative.8 Open source software is widely understood as software whose source code is released under a license that enables four freedoms:the freedom to study the source code,the freedom

117、to use the source code,the freedom to modify the source code,and the freedom to redis-tribute it.In Article 3(48),the CRA defines free and open source software as“software the source code of which is openly shared and which is made available under a free and open-source licence which provides for al

118、l rights to make it freely accessible,usable,modifiable and redistributable.”9 The role of open source software stewards under the CRAThe CRA defines open source software stewards as organisa-tions that systematically support the sustained development of free and open source software and ensure thei

119、r viability.By ex-plicitly requiring that stewards to be a“legal person other than a manufacturer”,the CRA effectively shields stewards from the cybersecurity obligations imposed on manufacturers,but also defines constraints on the activities of stewards,which should benefit the development of open

120、source software and not con-stitute monetization.Even though individuals are considered a legal person and therefore could qualify as a steward,European Commission representatives have indicated their expectation that stewards are juridical persons or incorporated organisa-tions.A number of importan

121、t obligations for open source software stewards informed the questions posed during the qualitative research with case study stakeholders.Under the CRA,open source software stewards must implement and document a cy-bersecurity policy that promotes secure development practices,effective vulnerability

122、 handling,and the voluntary reporting of vulnerabilities(Article 24(1).They are also required to cooper-ate with market surveillance authorities upon request,providing necessary documentation to address cybersecurity risks(Article 24(2).Additionally,stewards must report any known,actively exploited

123、vulnerabilities,notify severe incidents,and inform im-pacted users while providing mitigation measures(Article 24(3).To support manufacturers integrating open source compo-nents,the CRA enables the establishment of voluntary security attestation programs,allowing developers and users to assess confo

124、rmity with cybersecurity requirements(Article 25).14PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEDue diligence when integrating open source components into commercial productsManufacturers that incorporate open source components into their commercial products inherently depend on the cyber

125、se-curity practices of the open source products they rely on.The security,maintainability,and compliance of open source com-ponents are shaped by established open source development practices such as semantic versioning,continuous integration/continuous deployment(CI/CD),and distributed version cont

126、rol systems(DVCS).Additionally,the extent of modifications made to upstream components affects both the security posture of the final product,and the ability to receive timely updates.Because of this,manufacturers must exercise due diligence when integrating components from third parties including o

127、pen source software(Article 13(5),and if a component vulnerability is found,the manufacturer must report it to the component maintainer(Article 13(6).The need for due diligence regarding open source dependency management was influential in the formation of the critical research question:“To what ext

128、ent are selected projects ready to support downstream manufacturers?”Case studies:Leading projects in CRA readiness and cybersecurity best practices Civil Infrastructure PlatformThe Civil Infrastructure Platform(CIP)is an open source software project hosted by the Linux Foundation that is focused on

129、 establishing a base layer of industrial grade core open source software components to enable the use and implementation of software building blocks in civil infrastructure projects.The CIP project intends to create reusable building blocks that meet the safety,reliability,and other requirements of

130、industrial and civil infrastructure.Additionally,the CIP is committed to providing long-term support(LTS)for its software components,targeting a minimum maintenance period of 10 years to accommodate the extended life cycles common in such systems.The CIP Governing Board is responsible for financial

131、matters with respect to the project while the Technical Steering Committee oversees the technical direction of the project.ClassificationThe CIP operates as an open source software steward rather than a manufacturer,which releases open source software that enterprises use to develop their own PDEs a

132、nd services.It provides updates(i.e.substantially modified versions)via tags.The CIP itself does not release PDEs or services that are monetized and it does not make commercial offerings that complement its open source software.However,interviews with project leadership revealed uncertainty of wheth

133、er CIP qualifies as a steward.This uncertainty highlights the need for more guidance about the CRA;for example,who will take on the responsibility of being a steward:the project,or the foundation that hosts the project?In the case of the CIP,it is our understanding that the Linux Foundation as the l

134、egal entity that hosts the project will be the steward,which delegates the CRA related compliance activities to the CIP.15PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCECompliance with essential requirements of the CRADEVELOPMENT PRACTICESThe CIP implements development practices that leverag

135、e established open source infrastructure,publishing all software source code on kernel.org and GitLab.The project maintains communication with users through subscription-based mailing lists for release notifications.The release process is thoroughly documented on the CIP website,ensuring public audi

136、tability,and aligns with IEC 62443-4-1:2018 requirements for secure development of industrial automation and control systems.In fact,the CIP,to the best of the project leaders knowledge,was the first OSS project to adopt IEC 62443-4-1 cybersecurity requirements.“We are trailblazers in this regard,”c

137、omments Stefan Schroeder,a member of the CIPs Technical Steering Committee and Security Working Group,who was among our interviewees for this report.This IEC standard specifies the process requirements for the secure development of products used in industrial automation and control systems.In additi

138、on,CIP maintains clear delineation between development and release versions through a tag and branch system,with ongoing development taking place in the main branch and dedicated feature branches.CYBERSECURITY POLICYThe CIPs cybersecurity policy is maintained in GitLab and complies with IEC 62443-4-

139、1 requirements.Vulnerability reporting operates through public channels,but there is also a private email address for responsible disclosure.The reporting mechanisms are primarily mailing lists,integrating with established Linux kernel and Debian community processes.During the interview,Schroeder ra

140、ises the concern that documentation is always evolving and there may be a need to version documentation and software together.In addition,he advocates for releases to be treated as comprehensive bundles of both software and documentation to ensure users can identify what documentation was applicable

141、 at the time of any given release.COOPERATION WITH MSASThe CIP retains contracted maintainers and benefits from significant commitment from member companies,enabling timely and diligent handling of requests.However,Schroeder acknowledges challenges in coordinating responses within a distributed comm

142、unity structure,suggesting that dedicated employed personnel might be beneficial for handling MSA requests.He strongly advocates for the adoption of the OpenSSF Scorecard and security.txt files as easily implementable best practices that communicate project security status effectively.VOLUNTARY CYBE

143、RSECURITY ATTESTATION PROGRAMMESThe CIPs position as an integrator presents unique challenges,particularly in managing upstream dependencies where they cannot mandate security practices of upstream projects.The project conducts due diligence on upstream projects to compensate for this limitation.Whi

144、le currently not providing SBOMs with releases,this capability is under discussion.For vulnerability disclosure,the CIP relies on kernel.org as the numbering authority for the kernel and on Debian for the rest.But as the CIP is not releasing specific package sets,this coupling is even more loose.The

145、 projects approach in many cases exceeds some CRA requirements through additional third-party attestation.However,there remains significant uncertainty about how open source software projects,which typically rely on community-driven development models,should approach cybersecurity attestation progra

146、ms.The lack of clear guidance on roles,responsibilities,and practical implementation creates challenges for projects like CIP.16PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCECybersecurity practices that go beyond the CRAThe CIP implements advanced security practices beyond CRA requirements,

147、particularly in its kernel working group,where all release tags and tarballs must be cryptographically signed.This non-repudiation principle ensures commit integrity and unambiguous committer identification,though the project notes concerns about developers using individual private keys rather than

148、a more standardized approach.Additionally,the CIP aims to provide long-term support(LTS)for its software components,targeting a minimum maintenance period of 10 years.This commitment helps ensure that civil infrastructure systems can operate safely and reliably over extended lifecycles.As with all o

149、pen source,development and source code results are available for public review and critique,enabling others to more easily find and report defects.Further insightThe CIP identifies several significant gaps in the CRA,particularly regarding the unique characteristics of open source software developme

150、nt and industrial applications.A primary concern is the regulations inadequate recognition of the diversity of governance models among open source projects within the open source ecosystem.Projects which do not implement the structures envisioned by the CRA(e.g.the role of open source foundations as

151、 stewards)may face similar expectations to their cybersecurity posture without the necessary support organisation.While many major open source software projects are hosted by open source foundations which act as stewards,others are not.For example,the Debian project develops a widely used Linux dist

152、ribution with a community of over 1600 contributors in 2024,without any hosting organisation that qualifies as a steward.Furthermore,since OSS contributors have no obligation to deliver any feature or patch in an OSS project at any particular time,industrial users cannot plan the roadmaps of their p

153、roducts that depend on given OSS projects.Users can contribute to OSS projects,but typical medium sized projects use at least thousands of OSS libraries and components-just looking after these dependencies and monitoring their licenses without any contribution is a hassle.No single industrial user c

154、ould support all OSS projects that they benefit from.As yet another example of how traditional IT workflows and business practices do not transfer to the open source way,there is the issue of sunsetting open source projects at their end of life(EOL).This is a complex topic in OSS,since even if the l

155、ead maintainer declared some OSS as EOL,others could fork and maintain it.New regulation forces industrial users to ensure freedom from vulnerabilities.If regulations begin to set deadlines,it will be challenging to enforce such deadlines.In addition,there are concerns about the CRAs support require

156、ments as set in Article 13 in the context of industrial systems with extremely long life cycles.Specifically,the CRA requires that the support period reflect“the length of time during which the product is expected to be in use.”However,railway systems typically operate for 30 to 50 years,and other s

157、ystems are also long-lived.This makes the CRAs requirement for free security patches throughout a products reasonable lifecycle potentially unsustainable from a business perspective.In particular,the obligation to provide free security patches for such extended periods creates unsustainable business

158、 planning scenarios,as organizations would need to budget for maintenance activities spanning multiple decades.This misalignment between regulatory requirements and the practical realities of long-lived industrial systems highlights a critical challenge in implementing the CRAs security maintenance

159、provisions in sectors with extended operational timeframes.17PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEThere is also a potential misalignment between the CRAs security requirements and the realities of highly regulated industries.For example,Schroeder explained that product assessment a

160、nd approval processes in these sectors often take several months,during which new vulnerabilities may emerge.Schroeder suggests a more nuanced approach to security management,proposing that different components could have different security handling processes based on their attack surface and critic

161、ality.For instance,a more robust certification process could be applied to critical components like the kernel,while other system components could follow a regular monthly update cycle.However,the project notes that industry practices and expectations would need to evolve to accommodate such an appr

162、oach.Many industrial manufacturers are primarily OSS users rather than contributors,which has led to insufficient funding for long-term maintenance.This imbalance often places a disproportionate burden on upstream developers,such as semiconductor vendors,and risks undermining the sustainability of c

163、ritical open source infrastructure.The Yocto ProjectThe Yocto Project is an open source software project hosted by the Linux Foundation that enables developers to create custom Linux-based systems regardless of the hardware architecture.It is the de facto industry standard“tool kit”for building cust

164、om embedded Linux operating systems.The project provides a flexible set of tools and a space where embedded developers worldwide can share technologies,software stacks,configu-rations,and best practices that can be used to create tailored Linux images for embedded and IoT devices,or anywhere a custo

165、mized Linux OS is needed.It operates with a hierarchical governance structure led by maintainers and coordinated by the Yocto Governance Board.ClassificationYocto Project operates as an open source software steward,which releases open source software that enterprises use to develop their own PDEs an

166、d services.The project itself does not release PDEs or services that are monetized nor does it make commercial offerings that complement its open source software.Despite operating as a steward,Yocto Project implements several cybersecurity practices that align with manufacturer obligations under Art

167、icle 13.The project conducts cybersecurity risk assessments through systematic Common Vulnerabilities and Exposures(CVE)monitoring and implements build-time CVE checks.This approach provides a foundation for downstream manufacturers who typically derive their operating system environment from Yocto

168、Project.The project uses a bug-tracking system,Bugzilla,for reporting and fixing bugs as well as a ma-chine-readable CVE checker.Regarding long-term security sup-port,Yocto Projects current four-year LTS support window falls short of the CRAs five-year minimum requirement for security updates and te

169、n-year availability period.The projects recent ex-tension of the Long Term Support period from two to four years may serve as an incentive for organizations to engage with the project,particularly those seeking long-term security support for their products.However,the project acknowledges this gap a

170、nd indicates readiness to extend its LTS period to meet the five-year threshold.Yocto Project supports a“co-traveller”model,where manufacturers using the platform contribute collectively to 18PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEsecurity through common tools,shared data and shared

171、updates and fixes.This collaborative approach amplifies security benefits across the user base,as vulnerability reports or fixes from any single manufacturer benefit the entire ecosystem.Compliance with essential requirements of the CRADevelopment practicesThe Yocto Projects existing cybersecurity p

172、ractices align well with the CRAs requirements,reflecting the projects longstand-ing commitment to robust security practices.This alignment is not coincidental;the project was initially conceived to bring order to software customization processes through carefully-designed and documented build proce

173、dures with input from manufactur-ers and downstream users across the ecosystem.Yocto Project maintains a structured release cadence with two primary release types:standard releases every six months(April and October)with six-month support windows,and Long Term Support(LTS)releases every two years th

174、at receive four years of project support.Updates are managed through a Git-based workflow that distinguishes between functional and securi-ty updates.Functional updates are typically reserved for the six-monthly releases,while security updates are provided be-tween releases as needed.The project emp

175、loys a branch and tag system where each release becomes a stable branch,governed by explicit maintenance policies.All development occurs in the master branch and undergoes continuous integration testing,indicating robust quality assurance practices.Communication about updates flows through multiple

176、community channels in-cluding IRC,mailing lists,blog posts,and member meetings.The projects comprehensive development practices are cen-tered on a Git-based workflow with clear release management processes.Software releases are communicated through mul-tiple channels,including email announcement lis

177、ts and weekly status reports that keep downstream consumers informed of upcoming releases.The release process is thoroughly document-ed on the projects wiki and docs.yoctoproject.org,ensuring transparency and auditability.The Yocto Project documentation is versioned to correspond to releases,making

178、it simple to match a release to the relevant version of the documentation.The proj-ect maintains a clear delineation between development versions and releases through its tagging system,with only tagged ver-sions considered official releases.Notably,Yocto Projects build process includes detailed doc

179、umentation of customizations for integrated upstream components,providing transparency in its software supply chain.Cybersecurity policyCybersecurity governance is structured around several key components.The project maintains a bug tracker in Bugzilla with security-specific tagging capabilities,and

180、 its security processes have been strengthened through an audit funded by Germanys Sovereign Tech Fund.The project provides CVE scanning tools that benefit both the core project and downstream manufactur-ers.Community engagement in security matters occurs through regular bug triage calls,where prior

181、ities are collectively iden-tified and addressed.Vulnerability information is shared with the community through mailing lists,and the project maintains documented best practices for bug reporting,including a rec-ommendation for“security files”in all layers.In handling actively exploited vulnerabilit

182、ies,Yocto Project follows a systematic approach coordinated by its Technical Steering Committee.The process begins with determining whether the vulnerability orig-inates in user-added code or project layers,followed by collabo-19PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCErative developme

183、nt of fixes through open source channels.This transparent approach to vulnerability management ensures that security improvements benefit the entire ecosystem of down-stream users.Cooperation with MSAsYocto Project maintains a security team which includes its found-er and Linux Foundation Fellow,Ric

184、hard Purdie.The team works closely with the U.S.National Vulnerability Database(NVD),a repository maintained by the U.S.National Institute of Standards and Technology(NIST).The projects community is prepared to handle security requests,with one full-time employee and sev-eral contractors able to han

185、dle security-related matters.Purdie explains that while they may be set up to answer the question from a technical perspective,they may not have sufficient time or people on staff to deal with these diligently and in a timely fashion.They would need funding to employ additional staff to do this more

186、 rapidly.Voluntary cybersecurity attestation programmesYocto Project approaches attestation through systematic docu-mentation and codification of its processes,with particular em-phasis on reproducible builds and compliance verification.How-ever,Purdie notes that the attestation terminology in the C

187、RA is not clear as the attestation programmes are voluntary and yet to be established.In addition,the Yocto Project holds an OpenSSF silver badge,and maintains robust security verification practic-es,including regular checks against vulnerability databases and automated compliance monitoring.The pro

188、ject generates a soft-ware bill of materials(SBOM)compliant with the SPDX(System Package Data Exchange)3.0 SBOM standard as part of its build process.It adopted SPDX because it was identified as an efficient path to meeting CRA requirements for traceability and transpar-ency.In addition,Yocto Projec

189、t provides tooling for CVE analysis and regularly generates reports using it through its Valkyrie automated testing system.These tools offer detailed patch metrics for both the core project and meta-layers,enabling thor-ough security monitoring.While the project doesnt currently provide vulnerabilit

190、y disclosure information(e.g.,Vulnerability Exploitability eXchange(VEX)and Common Security Advisory Framework(CSAF)with its releases(because it was not need-ed until now),it states that it could provide this information.In addition,it maintains comprehensive CVE checking capabilities that can be pe

191、rformed at build time,and offers public resources for tracking security status through its wiki.Cybersecurity practices that go beyond the CRAYocto Project implements several advanced cybersecurity prac-tices that extend beyond the CRA requirements.A cornerstone of these practices is the projects co

192、mprehensive commitment to reproducible builds.A build is reproducible if given the same source code,build environment,and build instructions,any par-ty can recreate bit-by-bit identical copies of all specified artifacts.Reproducible builds create an independently-verifiable path from source to binar

193、y code,countering many attacks.10 Yocto Project is one of the only projects to provide reproducible builds for source-based builds on arbitrary host systems,independent of build location.The reproducibility feature serves as a crucial security mechanism by enabling thorough verification of soft-ware

194、 integrity and supporting detailed analysis of how security might be compromised through specific build changes.Further-more,its proactive security posture is exemplified by its full sup-port for SPDX 3.0 and its emphasis on build auditability.Looking 20PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OP

195、EN SOURCEbeyond current CRA requirements,Yocto Project maintainers recommend a requirement for software manifests to contain sufficient information to enable rebuilding of open source soft-ware layers.This aligns with a broader vision of software repair-ability,where users should retain the ability

196、to rebuild and repair software independently,particularly in scenarios where manu-facturers may no longer be available.Additionally,they identify a need for standardized component naming in CVE processing,suggesting this standardization should extend beyond the EU to align with global vulnerability

197、databases like the NVD,creating a more unified approach to security vulnerability management across jurisdictions and the global software industry.Zephyr ProjectThe Zephyr Project(Zephyr)is an open source project focused on building a best-in-class small,scalable,real-time operating system(RTOS)opti

198、mized for resource-constrained devices across multiple architectures.It is a vendor-neutral project where silicon vendors,OEMs,ODMs,ISVs,and OSVs can contrib-ute technology to reduce costs and accelerate time to market for billions of connected embedded devices.Its community members support new hard

199、ware,developer tools,sensors,and device drivers.Improvements are frequently delivered to incor-porate enhancements in security,device management capabil-ities,connectivity stacks,and file systems.The Zephyr Govern-ing Board is responsible for financial matters with respect to the project while the T

200、echnical Steering Committee oversees the technical direction of the project.ClassificationZephyr operates as an open source software steward,releas-ing open source software that enterprises use to develop their own PDEs and services.Zephyr itself does not release PDEs or services that are monetized

201、and it does not make commercial offerings that complement its open source software.The proj-ect software is available for download for free from the project website and is developed openly on GitHub.Compliance with essential requirements of the CRADevelopment practicesZephyr implements structured de

202、velopment practices centered on GitHub-based release management.New versions come out every four months.Zephyr provides a support window for each release and every 2.5 years they come out with a long term sta-ble version which is supported for 2.5 years.Software releases are communicated through mul

203、tiple channels,including reposi-tory tagging,mailing list announcements,Discord notifications,and dedicated Q&A sessions.The release process is compre-hensively documented in the projects online documentation,ensuring transparency and auditability.The project maintains a clear distinction between de

204、velopment and release versions through its main branch development approach,semantic ver-sioning practices,and detailed“getting started”guides for new contributors.21PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCECybersecurity policyThe project has a mature cybersecurity posture,with extensi

205、ve documentation which includes a security overview,secure coding guide,and a sensor device threat model.In particular,Zephyr maintains robust security oversight as a CVE Number-ing Authority with an established Product Security Incident Response Team(PSIRT).The project provides clear channels for v

206、oluntary vulnerability reporting through a dedicated email address and maintains a vulnerability registry that includes re-mediation information.This comprehensive security framework ensures effective sharing of vulnerability information with the community and downstream consumers.Cooperation with M

207、SAsZephyrs status as a CVE Numbering Authority facilitates direct communication with PSIRT authorities for vulnerability no-tifications.The project actively monitors direct reports and maintains a responsive volunteer-based system with typical response times of one to two days for security-related r

208、equests.Regarding the mandatory five-year support period,Zephyrs Kate Stewart anticipates a shift in relationships with third-party maintenance organizations but doesnt expect significant chang-es in interactions between stewards and manufacturers.More specifically,Stewart contends that manufacturer

209、s are unlikely to increase their direct involvement in open source development despite the extended support requirements.Any particular version of Zephyr is supported for 2.5 years;an alternative for manufacturers beyond that timeframe is to upgrade to a newer version of Zephyr.This requires manufac

210、turers to be prepared to upgrade and have a testing infrastructure in place for their application.Voluntary cybersecurity attestation programmesZephyr already participates in voluntary attestation programs.The project utilizes the OpenSSF Scorecard and has achieved gold status in the OpenSSF Best Pr

211、actices Badge program,with annual reviews ensuring continued compliance.The project enables effortless generation of build-specific SBOMs in SPDX format.A public dashboard containing SBOMs for a wide set of build targets is made available by a project member,and illus-trates that SBOM generation can

212、 happen seamlessly as part of the build process.Cybersecurity practices that go beyond the CRAZephyr implements several advanced cybersecurity practices that extend beyond the CRA requirements.A key element is the projects embargo policy,complemented by a structured PSIRT that deliberately moves bey

213、ond single-person responsibility.The project maintains a proactive approach to security stan-dards through self-attestation and regular evaluation of new policies emerging from the OpenSSF scorecard for potential project implementation.Kate Stewart emphasizes the impor-tance of recognising the evolv

214、ing nature of security best practic-es,and in turn the necessity to continuously update the proj-ects PSIRT processes to align with changes in CVE and National Vulnerability Database(NVD)infrastructure.In addition,Stewart highlights various channels for continuous security improve-ments,including au

215、tomated prevention of security regressions through Motor Industry Software Reliability Association(MISRA)scans and dedicated secure practices training for contributors.This comprehensive approach ensures that security consid-erations are embedded throughout the development process while building sec

216、urity expertise within the contributor commu-nity.22PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEFurther insightRegarding potential gaps in the CRAs regulatory framework,Stewart raises two significant concerns.First,the devolution of guidance to member states,particularly regarding SBOMs,i

217、s seen as a missed opportunity for standardization.The potential emergence of different SBOM variants across member states could create unnecessary complexity in security documentation and compliance.Second,there is a gap in addressing software provenance risk assessment.Current regulations do not a

218、de-quately address the challenges that open source stewards face in evaluating and ensuring the integrity of code contributions,particularly regarding repository poisoning attacks and control over code submissions.Insights from stewards and manufacturers engagementThe December 2024 Stewards and Manu

219、facturers Workshop in Amsterdam was an invitation-only forum hosted by the Linux Foundation Europe and OpenSSF for open source stakeholders to advance the open source communitys readiness for CRA compliance.Discussions were structured around three criti-cal workstreamsStandards,Awareness,and Tooling

220、each focused on defining actionable steps to support cybersecurity best practices in open source software development and inte-gration,and to support the implementation of the CRA over the course of the next three years.These workstreams provided insights into the collaborative efforts required to a

221、lign open source governance with regulatory expectations,the need for broader industry awareness,and the importance of developing standardized processes and tools for vulnerability management and compliance.The workshop served as a vital forum for trans-lating CRA obligations into practical,communit

222、y-driven initia-tives that will help both stewards and manufacturers navigate the evolving regulatory landscape.Below are the takeaways from each.Awareness workstreamThe Awareness workstream addresses the need to improve understanding of the CRA among open source projects,man-ufacturers,and the broa

223、der ecosystem.Key initiatives include launching a worldwide survey to assess CRA awareness levels,developing an interactive decision tree to help organizations determine their regulatory classification,and updating and im-proving guidance provided by Linux Foundation about the CRA.Participants highl

224、ighted the need for the OpenSSF to lead efforts to create educational materials,including a“CRA 101”course,corporate training modules,and persona-based guidelines tailored to different stakeholders such as manufacturers,market surveillance authorities,and open source software stewards.Other planned

225、activities include dedicated CRA-focused events,workshops,and a comprehensive FAQ and glossary to standard-ize terminology and address common concerns.Standards workstreamThe Standards workstream focuses on the urgent need to es-tablish recognized cybersecurity standards aligned with the CRA based o

226、n best practices developed by the open source commu-nity.Participants discussed leveraging existing ISO processes to create standards that address the CRA,ensuring broad adop-tion and regulatory compliance.Given the tight timelinethe standards related to the CRA need to be in effect before the CRA f

227、ully applies(11 December 2027)participants emphasized the 23PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEneed for swift action in coordinating efforts with these standard-ization bodies as well as the risks involved with the accelerated development of standards.Building relationships with

228、European regulatory groups and ensuring liaison status with national bod-ies were highlighted as crucial steps.The overarching goal is to develop widely accepted standards that provide clarity for open source stewards and manufacturers while streamlining compli-ance efforts across industries.Tooling

229、 workstreamThe Tooling workstream focused on equipping open source projects and manufacturers with the necessary resources to meet CRA obligations.OpenSSF,alongside other Linux Founda-tion projects,will develop standardized cybersecurity policies and vulnerability reporting templates,ensuring that o

230、pen source projects have clear guidelines for secure development and disclosure practices.Efforts will also be made to establish com-munication channels for cooperation with market surveillance authorities(MSAs)and to document best practices for handling MSA requests.Additionally,the group explored

231、the possibility of a voluntary cybersecurity attestation program that could provide manufacturers with greater confidence in open source software security.This initiative may involve collaboration with OpenChain to develop standardized conformance artifacts,helping projects demonstrate their adheren

232、ce to security best practices and regulatory requirements.Workshop outcomesThe Amsterdam workshop underscored the critical need for collaboration among open source stewards and manufacturers to meet the CRA requirements.Participants emphasized the importance of establishing recognized standards,enha

233、ncing awareness,and developing practical tools to ensure compliance.However,long-term challenges persist,particularly the potential mismatch between regulatory approaches across jurisdictions(i.e.,beyond the EU),which could create friction for global open source development.Given that open source so

234、ftware operates across borders,fragmented cybersecurity regulations risk im-posing conflicting requirements on projects and manufacturers.To ensure open source continues to thrive as a pillar of innova-tion and security,regulatory frameworks must strive for greater harmonization,fostering an environ

235、ment where compliance efforts are aligned rather than fragmented.The lessons learned and actions identified in this workshop will play a crucial role in shaping best practices for secure and sustainable open source development in a rapidly evolving regulatory landscape.As a concrete outcome of the S

236、tewards and Manufacturers Workshop discussions,Linux Foundation Europe and the OpenS-SF have recently launched a global initiative to prepare main-tainers,manufacturers,and open source stewards for the CRA and other emerging cybersecurity legislation worldwide.This initiative focuses on developing c

237、ommunity-driven cybersecurity standards,providing compliance guidance,and implementing necessary processes and tooling.Additionally,the initiative will be informed by research conducted to empirically evaluate levels of CRA awareness across stakeholder groups.By aligning these efforts with the CRAs

238、objectives,the initiative aims to equip the open source community to navigate the evolving regulato-ry landscape effectively.For further details,see Global Cyber Policy Working Group Resources in the Resources section of this document.24PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEConclusi

239、on:Strengthening open source security and CRA readinessThis report has explored the key challenges and opportunities for open source projects in meeting the requirements of the CRA through the cybersecurity posture of three leading LF projects.Through these case studies,as well as LF and com-munity-

240、led workshop insights,and analysis of best practices in the CIP,Yocto Project and Zephyr Project,it has become clear that compliance with the CRA is not simply about adhering to a regulatory frameworkit is an opportunity to proactively improve security practices,standardize security workflows,and st

241、rengthen collaboration across the open source ecosystem.The CRA represents a sea change for open source communi-ties,introducing regulatory oversight in ways that will have a long-term and pervasive impact on the structure of the up-stream-downstream network.Unlike previous regulatory ap-proaches th

242、at focused primarily on licensing considerations,the CRA shifts attention to how open source software is provided,maintained,and secured.It formally recognizes the role of open source stewards as distinct from manufacturers,establishing dedicated responsibilities for those who maintain and devel-op

243、open source projects outside of direct commercial activity.By focusing on the non-commercial provision of open source software rather than licensing alone,the CRA acknowledges the complexity of how modern software is built,integrated,and maintained.Additionally,the CRA confronts a long-standing pain

244、 point in the open source community:projects that are open source in name but not in practice.Many software components are technically open source by license but lack meaningful community collabo-ration or transparent security processes.By imposing a baseline of cybersecurity requirements on project

245、s that provide critical software components,the CRA seeks to elevate security stan-dards across the open source ecosystem,ensuring that widely used software is not just shared under open source licenses but actively maintained in a secure and responsible manner.While significant challenges remaininc

246、luding fragmented reg-ulatory approaches,resource constraints,and evolving security threatsthere are clear steps that open source projects,gov-ernments,and enterprises can take to improve readiness.These steps include long-term planning for security sustainability,investment in education and trainin

247、g,adoption of standardized security tooling,deeper engagement in collaborative organi-zations and standards development,and,above all,strong public-facing leadership that drives projects forward.RecommendationsBuilding a sustainable security roadmapOne of the key takeaways from this report is the ne

248、ed for a long-term,structured approach to security planning in open source projects.In particular,larger projects need to think beyond short-term compliance goals and work toward a five-year secu-rity strategy that includes proactive vulnerability management,sustained funding for security personnel,

249、and clear processes for engaging with downstream users and regulators.Security transparency is also critical.Open source projects should communicate their existing security capabilities and needs clearly,ensuring that users and stakeholders understand both their strengths and their resource gaps.Est

250、ablishing a dedicated Product Security Incident Response Team(PSIRT)is a crucial step for larger projects in ensuring vulnerabilities are handled effectively and that security incidents are addressed systematically,rather than relying on ad-hoc efforts from indi-vidual maintainers.25PATHWAYS TO CYBE

251、RSECURITY BEST PRACTICES IN OPEN SOURCEEducation is another essential component.Open source projects and maintainers need better training on CRA compli-ance,and best practices adoption in vulnerability disclosure and secure development methodologies.Manufacturers and enterprises integrating open sou

252、rce software should also take responsibility for educating their teams on how to work with upstream projects in a way that strengthens security across the supply chain.Adopting cybersecurity best practices developed by broad collaborations from across the open source ecosystem is a proven approach t

253、o establishing a baseline level of security and supply-chain management practices.This includes applying the OpenSSF Scorecard to projects and maintaining security.txt files,as well as performing an OpenChain self-certification assessment as cybersecurity depends on well-defined supply chain process

254、es.Additionally,license transparency must be a priority.In the same way that security is now an essential concern in software development,clear and consistent licensing practices should be emphasized.Pursuing OpenSSF best practices accreditation is a good first step in the roadmap to improving secur

255、ity postures and aligning with industry-recognized security frameworks.Align development practices to CRA concepts where appropriateSince conformity assessment may have to be renewed in the case of substantial modifications to a PDE,projects should make it explicit if their releases should be consid

256、ered substantial modifications or a minor functionality update or bug fix.One way to do this is to use semantic versioning to map substantial modifications according to the CRA to major versions,minor functionality updates to minor versions and bug or security fixes to patch versions.This practice w

257、ill indicate to downstream users of the software when an updated conformity assessment may be necessary.If rolling software releases are made based on the projects main branch,it may be useful to label those as unfinished software(Recital 37),as otherwise it would be difficult for downstream users t

258、o differentiate substantial and minor changes.Since documentation about the projects cybersecurity policy or vulnerability management procedures may change over time,documentation should be versioned and tagged with the project(and possibly maintained as part of the project in the same repository as

259、 its source code).This enables adopters to identify the documentation that matches the software version in use.The long-term support requirements mandated by the CRA,and the even longer support periods in industries like rail transport or aviation,may exceed the lifespan of even well-maintained soft

260、ware projects.In these situations,organizations must not only ensure critical dependencies remain viable by actively par-ticipating in development communities,but also maintain the expertise and capacity to replace end-of-life components with newer technologies.The CRA does not cover individual cont

261、ributors or unincorpo-rated,loosely organized communities.There i also uncertainty about whether public sector organizations that release software qualify as manufacturers or stewards under the regulation.Nevertheless,these entities may benefit from voluntarily fol-lowing manufacturer and steward ob

262、ligations as guidelines.This approach aligns with ecosystem best practices,helps establish a cybersecurity baseline,and prepares organizations for potential future regulatory requirements.26PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEInvesting in tooling for compliance and securityTo effe

263、ctively operationalize security best practices,security tooling should be integrated into the software development process as seamlessly as licensing best practices.Just as GitHub prompts developers to choose OSI-compliant licenses when initializing a new project,there is a need for equivalent nudge

264、s and recommendations for security best practices,including structured vulnerability reporting,adoption of security policies,and use of standardized software component registries.Where practical,enabling them by default can eliminate frictions from adoption.Producing SBOMs,such as SPDX 3.0,will be c

265、ritical for open source projects looking to meet the CRAs requirements.SPDX 3.0 makes it easier for projects to document component de-pendencies,track vulnerabilities,and provide manufacturers with the data they need for risk assessments.However,greater granularity in SBOMs is needed to improve visi

266、bility into specific source files present in deployed software images,rather than only tracking component-level dependencies.Beyond SBOMs,open source projects should integrate automat-ed security tooling into their development pipelines,including vulnerability tracking,dependency scanning,and supply

267、 chain security monitoring.These tools will not only help projects com-ply with regulatory requirements but also improve the projects resilience against security threats.These efforts to reduce or limit costs,and make efforts as automatic as possible,will be especially important for smaller OSS proj

268、ects.A one-person project with at most a few hundred lines of code will typically be unable to sustain costly invest-ments in time and money.Even larger OSS projects have limited resources;ensuring that these efforts are“on by default”within development processes themselves can cause widespread impr

269、ovements.Governments and enterprises can support these efforts by in-vesting in open source security tool development and ensuring that widely used security frameworks are accessible,well-docu-mented,and easy for maintainers to adopt.Standards development and cross-sector collaborationSecurity and c

270、ompliance cannot be solved in isolation.Open source projects must actively engage with other projects,gov-ernments,enterprises,and nonprofit organizations to drive security standardization and harmonization across the industry.The CRA provides an opportunity to align security expectations globally,b

271、ut only if open source communities work together to shape regulations and best practices that reflect the realities of software development.One area requiring urgent attention is the standardization of software and component naming conventions.Without con-sistency in how components are identified ac

272、ross vulnerability databases,package managers,and compliance tools,tracking security risks becomes unnecessarily complex.Historically,Common Platform Enumeration(CPE)has been used,but CPEs centralized assignment system cannot scale up to the modern software ecosystem.Alternatives such as package URL

273、s(pURLs)could provide significant improvements,but only if they are agreed on and used.Projects should work together to establish unified naming schemas that align with industry-recognized vulnerability tracking frameworks like CVE/NVD.27PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEAdditio

274、nally,further clarity is needed around CRA terminology,particularly the distinction between“placing software on the market”and“making software available on the market.”These definitions impact compliance requirements for open source projects and their downstream adopters,and collaboration between op

275、en source stakeholders and regulatory bodies is necessary to ensure practical,workable interpretations.Open source projects should participate in security standards bodies,policy discussions,and cross-industry security initia-tives to ensure that open source realities are represented in cybersecurit

276、y regulations.It is sometimes difficult to find a way to fund such activities.Enterprises and manufacturers should likewise collaborate with the open source projects they rely on,not just consuming software but also contributing to its security and sustainability.To prevent regulatory fragmentation

277、across jurisdictions,gov-ernments must work with industry leaders as well as the wider open source community to harmonize cybersecurity require-ments.A globally aligned approach to security regulation will reduce compliance burdens,improve security outcomes,and support the long-term sustainability o

278、f open source develop-ment.Addressing emerging security challengesWhile many security best practices are well established,new challenges are emerging that current security frameworks do not fully address.One of the most pressing concerns is the security of AI models and the risk of poisoned training

279、 datasets.As AI-assisted and AI-generated code becomes more common in open source development,malicious actors may attempt to introduce vulnerabilities at the model-training level,making security verification far more complex.Open source security frameworks must evolve to account for AI-generated co

280、de and provide mechanisms for assessing the integrity of AI-trained models.This includes establishing guidelines for dataset provenance,implementing verification processes to detect potential tampering,and developing new auditing mechanisms to ensure AI-driven contributions adhere to security best p

281、ractices.Governments,enterprises,and security researchers must collaborate with the open source community to develop new strategies for securing AI-assisted development,ensuring that open source software remains a safe and trustworthy founda-tion for innovation.Leadership as the driving force for op

282、en source software securityWhile security tooling,education,and standards development are all critical,none of these efforts will succeed without strong,public-facing leadership.The most security-mature open source projects have one thing in common:leaders who proactively advocate for their needs,en

283、gage with external stakeholders,and push for real change,creating cultures of security through cross-project and industry collaborations that permeate their projects.The leaders of projects like CIP,Yocto Project,and Zephyr are not just technical expertsthey are security ambassadors.They write blogs

284、,give countless presentations,host webinars,and work tirelessly to make the case for security improvements.Their advocacy attracts attention from policymakers,funders,and industry stakeholders,creating opportunities for collabora-tion and investment.28PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN

285、 SOURCEFor open source security to advance,more projects must em-brace this model of leadership.Open source maintainers should not wait for solutions to come to themthey should actively seek grants,reach out to regulators,engage with enterprise partners,and make their security needs heard.Richard Pu

286、rdies blog post on the challenges facing the Yocto Project,for exam-ple,directly led to financial backing from Germanys Sovereign Tech Fund,demonstrating how visible,proactive leadership can yield tangible security improvements.11 Beyond her work with Zephyr,Kate Stewarts co-leadership of the SPDX p

287、roject helped it to become an internationally recognized ISO standard.12 And the leaders of the CIP speak regularly on security topics,a recent example being a webinar led by Yoshitake Kobayashi and Dinesh Kumar illustrating the projects value in delivering secure and robust infrastructure in the co

288、ntext of international stan-dards and regulations.13Governments and enterprises,in turn,must support this leader-ship by funding open source security initiatives,creating oppor-tunities for collaboration,and listening to the voices of open source maintainers,directors,and other principle stakeholder

289、s when crafting policy and compliance frameworks.The future of open source security depends not just on compli-ance with regulations like the CRA,but on a cultural shift that prioritizes security leadership,long-term investment,and global collaboration.By taking these steps today,open source project

290、s,enterprises,and governments can work together to create a stronger,more resilient,and more secure software ecosystem for the future.29PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEResourcesGlobal Cyber Policy Working Group Resources:Global Cyber Policy WG GitHub#wg-globalcyberpolicy on Sl

291、ack Global Cyber Policy WG Mailing List CRA Readiness+Awareness SIG Mailing List CRA Tooling+Process+Formats SIG Mailing List CRA Spec Standardization SIG Mailing ListVulnerabilities Reporting&Guidance:Guidelines on reporting vulnerabilities specific to LF projects and foundations.List of Linux Foun

292、dation projects Linux kernel security vulnerabilities should be reported to securitykernel.org as described in the Linux kernel securi-ty bugs page Report vulnerabilities specific to Linux Foundation infra-structure or the main LF website by emailing securitylinuxfoundation.org Alert on social engin

293、eering takeoversSecurity Best Practices and Tools:Alpha Omega partners with open source software project maintainers to systematically find new,as-yet-undiscovered vulnerabilities in open source code and get them fixed CNCF fuzzing handbook describes what fuzzing is,and how to apply it OpenSSF Techn

294、ical Initiatives,including Best Practices Badge,Scorecard,Sigstore and more System Package Data Exchange(SPDX)open SBOM standard(ISO/IEC 5692:2021)Post Quantum Cryptography Alliance for the adoption and advancement of post quantum cryptography Safer Languages discusses the benefits of programming la

295、nguages designed with security in mind(NIST)Secure by Design principles prioritize the security of custom-ers as a core business requirement(CISA)30PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEEducational Resources:Featured Certifications Kubernetes and Cloud Native Security Associate(KCSA

296、)Certified Kubernetes Security Specialist(CKS)Instructor-Led Training Courses Security and the Linux Kernel(LFD441)Kubernetes Security Fundamentals(LFS460)Zero Trust Security with SPIFFE and SPIRE(LFS482)Security Coding Fundamentals(WSKF601)Understanding Vulnerabilities and Security Threats(WSKF603)

297、Hands-On Learning Workshops Securing Coding Fundamentals(WSKF601)Understanding Vulnerabilities and Security Threats(WSKF603)Featured Free Training Developing Secure Software(LFD121)Developing Secure Software-Japanese version (LFD121-JP)Securing Your Software Supply Chain with Sigstore(LFS182)Underst

298、anding the OWASP Top 10 Security Threats(SKF100)Introduction to DevSecOps for Managers(LFS180)Introduction to Zero Trust(LFS183)Cybersecurity Essentials(A Must-Have for ALL Employees)(LFC108)Free Express Learning(60-90 minutes)Security Self-Assessments for Open Source Projects(LFEL1005)Securing Proj

299、ects with OpenSSF Scorecard(LFEL1006)Automating Supply Chain Security:SBOMs and Signatures(LFEL1007)e-Learning Courses Kubernetes Security Essentials(LFS260)Mastering Kubernetes Security with Kyverno(LFS255)Modern Air Gap Software Delivery(LFS281)Implementing DevSecOps(LFS262)Mastering Infrastructur

300、e Security:Strategies,Tools,and Practices(SKF200)Cloud Native Fuzzing Fundamentals(LFS251)Detecting Cloud Runtime Threats with Falco(LFS254)Research Empirically-driven,security-specific insights from LF Research31PATHWAYS TO CYBERSECURITY BEST PRACTICES IN OPEN SOURCEEndnotes1 https:/eur-lex.europa.

301、eu/eli/reg/2024/2847/oj 2 The CRA only applies to PDEs if their purpose or foreseeable use has a data connection,and in a few cases(like medical devices)there are separate regulations,but in practice the Act covers most commercial software.3 Frank Nagle,Kate Powell,Richie Zitomer,and David A.Wheeler

302、,“Census III of Free and Open Source Software:Application Libraries,”The Linux Foundation,December 2024.https:/www.linuxfoundation.org/hubfs/LF%20Research/lfr_ censusiii_120424a.pdf?hsLang=en 4 https:/eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02024R2847-20241120 5 https:/openssf.org/blog/2

303、024/12/23/cra-stewards-and-manufacturers-workshop-key-takeaways-and-next-steps/6 https:/eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847 7 https:/eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202402847 p.298 https:/opensource.org/osd 9 https:/eur-lex.europa.eu/legal-content/EN/

304、TXT/PDF/?uri=OJ:L_202402847 p.3110 https:/reproducible-builds.org/11 https:/www.yoctoproject.org/blog/2024/03/28/maintainer-confidential-challenges-and-opportunities-one-year-on/12 https:/www.linuxfoundation.org/press/featured/spdx-becomes-internationally-recognized-standard-for-soft ware-bill-of-ma

305、terials 13 https:/www.linuxfoundation.org/webinars/enhancing-cyber-resilience-with-cip AcknowledgmentsThe authors are grateful to our sponsoring project communities,and to all whose invaluable input and guidance enabled this reports publication,especially:Dan ApplequistGabriele ColumbroMarion Deveau

306、dMike DolanEsther GarciaUrs GleimAnna HermansenChristian“fukami”HorchertTakehisa Katayama Jan KiszkaMegan KnightClara KowalskyYoshitake KobayashiTodd MooreFederica NocerinoRichard PurdieChristopher“CRob”RobinsonStefan SchroederKate StewartChristian StormAndrew WafaaDavid A.Wheeler32PATHWAYS TO CYBER

307、SECURITY BEST PRACTICES IN OPEN SOURCEAbout the authorsMirko Boehm,PhDMirko Boehm is a free and OSS contributor,community manager,licensing expert,and researcher,with contributions to major open source projects such as the KDE Desktop(since 1997,including several years on the KDE e.V.board),the Open

308、 Invention Network,the Open Source Initiative,and others.He is a visiting lecturer and researcher on free and OSS at the Technical University of Berlin.Mirko Boehm has a wide range of experience as an entrepreneur,corporate manager,software developer,and German Air Force officer.He joined the LF in

309、June 2023 as senior director for community development for LF Europe,where he focuses on driving engagement and collaboration between all European open source stakeholders.Mirko speaks English and German and lives in the Berlin area.Hilary CarterBased in Canada with dual Irish and Canadian citizensh

310、ip,Hilary Carter joined the Linux Foundation in March,2021 to launch and lead LF Research,working extensively with stakeholders across the open source community.Since its inception,LF Research has published the definitive collection of empirical insights into open source as a paradigm for mass colla

311、boration at scale.Systematically measuring the impact of open source software,open hardware,open standards,and open data,LF Research has provided deci-sion-useful data for individual project communities,enterprises,governments,and society at large.Before joining the Linux Foun-dation,Hilary led a gl

312、obal,syndicated research institute focused on blockchain technology,and has years of professional experience in management consulting,communications,and financial services.She holds an MSc in Management from the London School of Economics.Cailean Osborne,PhDCailean Osborne is a senior researcher at

313、the Linux Foundation,who leads research projects on diverse open source trends and policy topics,from the impacts of open source funding to open source AI governance.Cailean has a PhD in Social Data Science from the Oxford Internet Institute at the University of Oxford,and in 2023-2024 he was a visi

314、ting researcher at Peking Universitys Open Source Software Data Analytics Lab in Beijing,China.Previously,Cailean worked in AI policy at the UK government and served as a UK government delegate at the OECDs Global Partnership on AI and the Council of Europes Ad Hoc Committee on AI.Cailean is a polyg

315、lot who is based in Berlin,Germany.The CIP is an open source project hosted by the Linux Foundation to develop and maintain a sustainable industrial-grade software platform for civil infrastructure systems.CIPs mission is to enable secure,reliable and long-lasting solutions that power critical syste

316、ms around the world.For more information,visit www.cip-project.org.Founded in 2021,Linux Foundation Research explores the growing scale of open source collaboration and provides insight into emerging tech-nology trends,best practices,and the global impact of open source projects.Through leveraging p

317、roject databases and networks and a commitment to best practices in quantitative and qualitative methodologies,Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.The Open Source Security Foundation(OpenSSF)is a cross-indus

318、try initiative by the Linux Foundation that brings together the industrys most important open source security initiatives and the individuals and companies that support them.The OpenSSF is committed to collaborating and working upstream and with existing communities to advance open source security.F

319、or more information,please visit us at openssf.org.The Yocto Project is an open source collaboration project that provides templates,tools and methods to help you create custom Linux-based systems for embedded system deployments in connected edge devices,servers,or virtual environments,regardless of

320、 the hardware architecture.Please visit yoctoproject.org.The Zephyr Project is an open source,scalable real-time operating system(RTOS)supporting multiple hardware architectures.To learn more,please visit zephyrproject.org.Copyright 2025 The Linux FoundationThis report is licensed under the Creative

321、 Commons Attribution-NoDerivatives 4.0 International Public License.To reference this work,please cite as follows:Mirko Boehm,Hilary Carter,and Cailean Osborne,“Pathways to Cybersecurity Best Practices in Open Source:How the Civil Infrastructure Platform,Yocto Project,and Zephyr Project are Closing the Gap to Meeting the Requirements of the Cyber Resilience Act,”foreword by Miriam Seyffarth,The Linux Foundation,March 2025.