Understanding the risks and benefits of open-source software

Open-source software is the backbone of the internet. The Linux and BSD operating systems are embedded in millions of unique devices, and curl is the most shipped piece of software ever, with an estimated 10 billion installs across computers, phones, consoles, printers, and cars.

Whilst having the source openly available makes it easier for threat actors to find vulnerabilities, it equally provides an opportunity for outside developers to spot and fix them.

A community development model has proven itself to be stable, to ship features, and to provide a strong basis to build upon. Yet in the context of technology provision for goverment, there are legitimate concerns about the security risks posed by software with a non-commercial background.

A common view is that ‘open-source’ means ‘less secure’ because anyone can modify it, and anyone can read and find the vulnerabilities.

This argument isn’t entirely right or wrong. Indeed, whilst having the source openly available makes it easier for threat actors to find vulnerabilities, it equally provides an opportunity for outside developers to spot and fix them.

If we consider the converse, that closed-source software must be more secure, then evidence suggests that this isn’t necessarily the case. The 

 project has been tracking vulnerabilities across the software ecosystem since 1999 and contains over 250,000 entries from both closed and open-source components, most of them open. Although a useful source, it is not entirely representative of the closed-source landscape; whilst open projects must notify MITRE to get a CVE assigned for a bug, private companies are not required to. As such, issues discovered internally are not necessarily publicised and fixes can be pushed out under the heading of "miscellaneous bug fixes and improvements". 

We know these issues exist because when they do become public, they become big news. In 2021, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) 

 tracing the 30 most widely exploited vulnerabilities. Only two of the issues were from open-source projects.

This isn't a matter of reach - the "Log4shell" vulnerability from the Apache log4j project was the single most exploited bug precisely because of its almost ubiquitous usage in both open-source and closed-source Java software.

There is a downside to choosing an open project to build from – you’re not paying anything, so you’re not paying for support and risk management. For small businesses and hobby projects, posting for help on a forum might be sufficient, but this is a significant and understandable risk for government customers: when you’re trying to build something long-lasting and stable, the support lifecycle is critical.

This is where system integrators play a critical role. Underpinned by specialist expertise in software, integrators should take on that risk and provide the requisite support and training to government customers and end users through life.

Importantly, open-source also helps to mitigate vendor lock-in. Even if customers wish to keep using the same database engine under the hood, other integrators or consultants should be able to step in and work with it as the same technology is accessible to everyone.

So, whilst there are legitimate concerns regarding the security and stability of open-source software, there are considerable benefits. With the community development model providing a strong ecosystem of expertise to build upon, open-source software is a critical element of modern, dynamic technology provision.

Synthetic_training_software_Modelling_detection

Synthetic_training_software_Modelling_detection_ROWDEN23_1842

A view on open-source software security

The UK Government envisions its future defence-industrial base as a partnership between ‘smarter’ government customers and an ‘ecosystem of scientists, researchers, inventors, and innovators.’[1]

Traditionally, the evolution of military capability has been determined by the incumbent’s hardware design choices, yet future defence systems are increasingly dictated by software considerations.

To alleviate the challenges associated with the delivery of complex digital procurement programmes, the role of the System Integrator must evolve to bridge asymmetries and empower the Smarter Customer to succeed.

The Army are working on what we need and how we can retain the right skills in a marketplace that’s highly competitive and evolving quickly. We’ve experimented with apprenticeships in the DevSecOps world, but ultimately many leave us for better paid roles. The result is we are currently dominated by 'As A Service' contracts, but is that the right model?

Technological innovation is intrinsically tied to the efforts of a vast array of scientific research and engineering activities distributed across myriad commercial entities. These ‘technology systems’[3] are highly inter-dependent, complex, and extremely challenging for government to govern and integrate into existing ecosystems.

How is new technical expertise being generated and shared, by whom, and where can it be applied to defence problem sets? These questions are grow in importance as the delivery of future digital capability becomes increasingly dependent on the effective orchestration of these complex commercial technology systems.

The industrial base is responding, but dependency on more specialist software-centric expertise, rather than capital-intensive industry or generalist consultancy, is growing. The key challenge for government customers, then, becomes one of ‘finding the right expert’ to deliver material value to frontline operators at pace.[4]

Things get sold because they’re well marketed, not because they’re technically superior or meet some technical thresholds.

The underlying logic behind the government’s ‘smarter customer’ aspiration is that when the knowledge of government teams meets or exceeds that of the supply chain, they are in a better position to limit historically identified poor behaviours in digital procurement programmes, such as vendor lock-in and high costs of exit or change.

The role of a systems integrator (SI) is the key to ensuring customers can succeed when there are high degrees of uncertainty and risk. A SI should not slow down the delivery of value. Rather, they should alleviate some of the challenges government customers will face in delivering complex technology projects.

01. A rapidly changing technological landscape, creating performance and obsolescence risk.​

System integrators must create the conditions for component change whenever it is deemed necessary and ensure management of obsolescence through long term technology planning, not bespoke contracts for unsupported components. ​

02. Requirements that are either too explicit or too loose.​

To drive a better performing and more cost-effective solution, integrators must take a tailored approach to procurement of components on the merit of the individual requirement.

03. Historical instances of ‘vendor lock in’ leading to a high cost of exit and contributing to an unaffordable Equipment Programme.​

Commercial openness should be prioritised to the same extent as system openness. The industrial base’s incentive to succeed should be partly based on the possibility of replacement.

04. Poor contractor behaviours leading to a lack of trust and collaboration.

Collaboration and good behaviours must be driven by the integrator with technical expertise and conviction. SI's should support with building non-traditional supplier-customer relationships to build robust supply chains. Equally, government must be bold and work with SI’s who accept risk when incentivised to deliver against difficult challenges, not contractors who mitigate through ‘risk sharing’.

Historically, issues arise where the government owns its code but is blocked or delayed from accessing it by a contracted DevOps function. Government ownership is a necessity to drive better value and operational capability; SI’s should ensure the customer owns its source code with immediate and easy access to its hosting environments.


What we’ve got to do is actually pick some winners.

An understanding of recurrent and new informational asymmetries in the defence-industrial base can critically inform the development of innovation management, knowledge creation, and communication strategies within the enterprise. These strategies will be critical to realising defence initiatives like Multi-Domain Integration in the UK or Integrated Deterrence in the U.S, which are dependent on cross-sector collaboration across multiple geographic and military boundaries.

Integrators have a responsibility to bridge knowledge asymmetries, drive good behaviours, and champion ‘smarter customers’. Equally, the government must back the best athletes who are delivering and let them get on with creating value. Those who can’t, should be penalised.

[1] See Global Britain in a Competitive Age: the Integrated Review of Security, Defence, Development and Foreign Policy. (2021) https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/975077/Global_Britain_in_a_Competitive_Age-_the_Integrated_Review_of_Security__Defence__Development_and_Foreign_Policy.pdf

[2] Brigadier Crossfield, Stefan. (2021) https://defencedigital.blog.gov.uk/2021/07/30/three-of-many-challenges-for-becoming-a-digitally-transformed-british-army/

[3] Carlsson and Stanciwicz. (1991). On the Nature, Function and Composition of Technological Systems. Journal of Evolutionary Economics.

[4] See HM Government. (2021). ‘The Consultancy Playbook’, p. 16. https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/987126/The_Consultancy_Playbook.pdf

[5] See interviews conducted by Bowne, Andrew S. 2022. National Contract Management Association. https://www.ncmahq.org/Shared_Content/CM-Magazine/CM-Magazine-July-2022/Innovations.aspx

[6] Gen. CQ Brown, speaking at the 2022 Reagan National Defense Forum. See: https://www.defensenews.com/industry/2022/12/04/air-force-chief-military-must-pick-some-winners-among-startups/

Journal

A view on open-source software security

Overcoming the barriers to delivering software-centric capability