With the growing use of open source in electronics software, now is the time to focus on its security

This article originally appeared in the March'24 magazine issue of Electronic Specifier Design – see ES's Magazine Archives for more featured publications.

However, open source software also brings its own security challenges, and – with the use of OSS only increasing – it must be addressed as part of a wider need to focus on its management more effectively. This is not to say that OSS is less secure than proprietary – though there are specific aspects to its nature that can bring their own challenges – but, in many cases, OSS security is not being prioritised. And this matters because if 2023 was the year security threats escalated, expect to see even more in 2024.

Alongside security sits compliance, and software teams involved in electronics must comply with a range of industry standards and regulations, especially in safety-critical applications, where all efforts to remove vulnerabilities and, hence, potential security or safety risks are minimised. Furthermore, compliance requirements are growing and can change frequently.

Of course, most users are aware of the increasingly pressing need to address security. The State of Open Source report found that respondents’ top open source support challenge is maintaining security policies and compliance at 79%. For the second most selected support challenge, 70% describe staying current with updates and patches as challenging.

However, security and compliance are often put on the back burner, not least because of a lack of resources. In already overworked development environments, teams prioritise fire-fighting. Plus, traditionally, security was something other teams looked after and not viewed as part of a developer’s responsibility, though that perception is changing. Likewise, IT operations staff such as platform engineers or system administrators know security is essential but are often just about keeping up with dealing with support tickets.

The good news is that there are some clear steps towards a better overall OSS security and management, which is much needed because OSS best practices have yet to match the growing maturity of OSS technologies. For example, an open source program office (OSPO) is a team dedicated to OSS: its adoption, use, and supporting processes. They can also be responsible for training other teams about OSS maintenance, compliance, and security.

Ideally, OSPOs would have been standard practice for years by now. However, there is still time to catch up, by employing individuals who understand the OSS supply chain, what to look for in terms of community support, best practice processes to adopt, and simply having better visibility and control over OSS can make a positive impact on OSS management and, within that, its security.

The end-of-life security risk

Of course, in today’s market, where IT talent of all kinds is in short supply, it may be necessary to use the services of a third-party OSS specialist organisation, especially when end-of-life (EOL) software is still being used. This is software no longer supported by the relevant OSS community, meaning that known bugs may not be patched, which could lead to system performance issues, security vulnerabilities, and being out of step with compliance.

For in-house teams, having the time and expertise to deal with unsupported EOL software can be onerous, yet they may also not have the capacity to move to an alternative. They are aware of this dilemma: 22% are still using CentOs, and 20%+ are still using AngularJS, yet 42% of all respondents say maintaining EOL software is challenging. A third party can support EOL software while helping organisations develop migration strategies to alternatives, including assisting in selecting future software.

SBOMs

Another valuable technique is creating an OSS Software Bill of Materials (SBOM). Many readers will already be familiar with BOMs as part of electronic design and manufacturing projects, giving teams a list of raw materials, electronic components and everything required for the final product.

SBOMs play a similar role and knowing all the software elements involved contributes to greater overall visibility. In turn, this supports better OSS management and security measures. However, be sure to use a modern approach to creating and modifying SBOMs, which, even in high-tech environments, are still sometimes based on Word documents, spreadsheets, or emails. These are not automatically updated and can quickly become outdated.

On that topic, automation is an integral part of all software security processes, rather than depending on manual effort and tools that aren't designed for the job. Automating as much as possible helps to reduce the risk of human effort and also liberates team members’ time to focus on other activities. Multiple automated tools are available to address different functions across software development and operations.

Finally, there is the need to consider the growth of open-source AI technologies, such as the increasingly popular large language models (LLMs). With the pace of AI’s evolution, developing appropriate security strategies is essential, whether open-source or otherwise. However, AI could be its own security solution to some extent, through the emerging introduction of secondary AI tools that act as AI software police, checking and verifying the primary AI’s results to mitigate data privacy and security risks, plus hallucinations and other issues such as hate speech. Already, Amazon has introduced this feature in its Guardrails project, and tools of this kind will become more widely available to more people and types of applications within the near future.

All these steps will contribute to better OSS security in the electronics industry. Naturally, they will initially create additional effort and require some investment, but given the combination of more attacks, greater use of OSS and AI, and growing and evolving compliance, now is the time to put in place some solid foundations for better security and overall OSS management.