Modern software today consists of modular components that get reused in different configurations. Components can consist of open source libraries, source code or other external, third-party developed software. This reuse lets innovation of new functionality flourish, especially as a large percentage of those components being connected together to form a system may be open source. Each of these components may have different limitations, support infrastructure, and quality levels. Some components may be obsolete versions with known defects or vulnerabilities.  When software runs a critical safety system, such as life support, traffic control, fire suppression, chemical application, etc., being able to have full transparency about what software is part of a system is an essential first step for being able to do effective analysis for safety claims.  

Why is this important?

When a system has functionality incorporated that could have serious consequences in terms of a person’s well being or significant loss, the details matter.  The level of transparency and traceability may need to be at different levels of details based on the seriousness of the consequences.  

Source: NTIA’s  Survey of Existing SBOM Formats and Standards

What does this have to do with Safety Critical Development? 

Safety Standards, and the claims necessarily made against them, come in a variety of different forms.  The safety standards themselves mostly vary according to the industry that they target: Automotive uses ISO 26262, Aviation uses DO 178C for software and DO 254 for hardware, Industrial uses IEC 61508 or ISO 13849, Agriculture uses ISO 25119, and so on.  From a software perspective, all of these standards work from the same premise that the full details of all software is known: The software should be developed according to a software quality perspective, with additional measures added for safety.  In some instances these additional safety measures come in the form of a software FMEA (Failure Modes and Effects Analysis), but in all of them, there are specific code coverage metrics to demonstrate that as much of the code as possible has been tested and that the code complies with the requirements.

Another item that all safety standards have in common is the expectation that the system configuration is going to be managed as part of any product release.  Configuration management (CM) is an inherent expectation in software already, but with safety this becomes even more crucial because of the need to track exactly what the configuration of a system (and its software) is if there is a subsequent incident in the field while the system is being used.  From a software perspective, this means we need several things:

• The source code at the time of release
• The documentation associated with it
• The configuration used to build the software
• The specific versions of the tools used to build the software

The goal, then, is to be able to rebuild exactly what the executable or binary was at the time of release.

From the above, it is inherently obvious how the SBOM fits into the need for CM.  The safety standards CM requirements, from a source code and configuration standpoint, are greatly simplified by following an effective SBOM process. An SBOM supports capturing the details of what is in a specific release and supports determining what went wrong if a failure occurs.

Because software often relies upon reusable software components written by someone other than the author of the main system/application, the safety standards also have a specific expectation and a given set of criteria for software that you end up including in your final product.  This can be something as simple as a library of run-time functions as we might expect to see from a run-time library, to something as extensive as a middleware that manages communication between components.  While the safety standards do not always require that the included software be developed in accordance with a safety standard, there are still expectations that you can prove that the software was developed at least in compliance with a quality management framework such that you can demonstrate that the software fulfills its requirements. This is still predicated on the condition that you know all of the details about the software component and that it fulfills its intended purpose.

The included software components can be from:

• Third parties
• Existing SW not developed according to a safety standard
• Internally developed software already in use

Regardless of the source or current usage of the software, the SBOM should describe all of the included software in the release.

To this end, the safety standards expect that the following is available for each software component included in your project:

• Unique ID, something to uniquely identify the version of the software you are using.  Variations in releases make it important to be able to distinguish the exact version you are using.  The unique ID could be as simple as using the hash from a configuration management tool, so that you know whether it has changed.  
• Any safety requirements that might be violated if the included software performs incorrectly.  This is specifically looking for failures in the included software that can cause the safety function to perform incorrectly.  (This is referred to as a cascading failure.)
• Requirements for the software component
  • This should include the results of any testing to demonstrate requirements coverage
  • Coverage for nominal operating conditions and behavior in the case of failure
  • For highly safety critical requirements, test coverage should be in accordance with what the specification expects (e.g., Modified Condition/Decision Coverage (MC/DC) level code coverage)
• The intended use of the software component
• The component’s build configuration (how it was built so that it can be duplicated in the future)
• Any required and provided interfaces and shared resources used by the software component.  A component can add demand for system-level resources that might not be accounted for.
• Application manual (documentation)
• Instructions on how to integrate the software component correctly and invoke it properly
• What the software might do under anomalous operating conditions (e.g., low memory or low available CPU)
• Any chained dependencies that a component may require
• Any existing bugs and their workarounds

Conclusion

At a minimum, the SBOM describes the software component, supplier and version number, with an enumeration of the included dependent components.  This is what is being called for in the minimum viable definition of an SBOM to support cyber security[1] or safety critical software[2].   

Having a minimum level of information, while better than nothing, is not sufficient for the level of analysis that safety claims expect.   Knowing exactly which source files were included in the build is a better starting point.   Even better still is knowing the configuration options that were used to create the image (and be able to reproduce it), and being able to check via some form of integrity check (like a hash) that the built components haven’t changed is going to be key to having a sound foundation for the safety case.   SBOMs need to scale from the minimum, to the level of detail necessary to satisfy the safety analysis.   

While SBOM tooling may not be able to populate all of this information today, the tools are continuing to evolve so that the facts necessary to support safety analysis can be made available.   An international open SBOM standard, like SPDX[3] can become the baseline for modern configuration management and effective documentation of safety critical systems.

[1] The Minimum Elements For a Software Bill of Materials (SBOM) from NTIA

[2] ISO 26262:2018, Part 8, Clause 12 – Qualification of Software Components 

[3] ISO/IEC 5962:2021 – Information technology — SPDX® Specification V2.2.1

Authors

Peter Brink, Functional Safety Engineering Leader, kVA by UL, Underwriters Laboratories (UL)

Kate Stewart, VP Dependable Embedded Systems, The Linux Foundation

The post SBOMs Supporting Safety Critical Software appeared first on Linux.com.

In 2021, The Linux Foundation continued to see organizations embrace open collaboration and open source principles, accelerating new innovations, approaches, and best practices. As a community, we made significant progress in the areas of cloud-native computing, 5G networking, software supply chain security, 3D gaming, and a host of new industry and social initiatives.

Download and read the report today.

The post Download the 2021 Linux Foundation Annual Report appeared first on Linux.com.

If you manage or want to be part of an open source project, you might have wondered if the project is healthy or not and how to measure key performance indicators relating to project health. 

You could choose to analyze different aspects of the project, such as the technical health (such as number of forks on GitHub, number of contributors over time, and number of bugs reported over time), the financial health (such as the donations and revenues over time), the social aspects (such as social media mentions, post shares, and sentiment analysis across social media channels), and diversity and inclusion aspects (such as having a code of conduct, create event inclusion activities, color-blind-accessible materials in presentations, and project front-end designs). 

The question is, how do you measure such aspects? To determine if a project’s overall health, metrics should be computed and analyzed over time. It’s helpful to have such metrics in a dashboard to facilitate analysis and decision-making.

Why do metrics matter?

“The goal here is not to construct an enormous vacuum cleaner to suck every tiny detail of your community into a graph. The goal is instead to identify what we don’t know about our community and to use measurements as a means to understand those things better.”

The Art of Community – Jono Bacon

Open source software needs community. By knowing more about the community through different metrics, stakeholders can make informed decisions. For example, developers can select the best project to join, maintainers can decide which governance measures are effective, end-users can select the healthier project that will live longer (and prosper), and investors can select the best project to invest in [1]. 

Furthermore, Open Source Program Offices (OSPO), i.e., offices inside companies that aim to manage the open source ecosystems that the company depends on [5], can assess the project’s health and sustainability by analyzing different metrics. OSPO is becoming very popular because around 90% of the components of modern applications are open source [6]. Thus, measuring the risks of consuming, contributing to, and releasing open source software is very important to OSPO [5].

How do we define which metrics to evaluate?

• Set your goals: Measuring without a goal is just pointless. Goals are concrete targets to know what the community wants to achieve [3].

• Find reliable statistical sources: After defining your goals, you can then identify the source to help you achieve your goals. It is essential to find ways to get statistics on the most important goals [4]. Some statistics are apparent, such as on GitHub, you can collect the number of stars, number of forks, and number of contributors to a repository. It is also possible to get mailing lists subscribers and the project website visits. Some statistics are not so obvious, though, and you might need tools to help extract such numbers.

• Interpret the statistics: Interpret the statistics regarding the “4 P’s”: People, Project, Process, and Partners [4]. 

• • Look at the numbers mostly related to the People in the community, such as contributors’ productivity, which channels have the most impact, etc. 

• • Then, look at the velocity and maturity of your Project, such as the number of PRs, and the number of issues. 

• • After that, look at the maturity of your Process, i.e., what’s your review process? How long does it take to solve an issue? 

• • Finally, look at the ecosystem view regarding your Partners — that is, statistics on project dependencies and projects that depend on you.

• Use dashboards to evaluate your metrics: Many existing tools help to create dashboards to analyze and measure open source community healthiness, such as LFX Insights, Bitergia, and GrimoireLab.
• Make changes: After measuring, it is necessary to make changes based on those measurements.

Learning from examples

Different projects use different strategies to measure the project’s health. 

The CHAOSS Community creates analytics and metrics to help understand project health. They have many working groups, each one focusing on a specific kind of metric. For example,

• The Diversity and Inclusion working group focuses on the diversity and inclusion in events, how diverse and inclusive the governance of a community is, and how healthy the community leadership is. 
• The Evolution working group creates metrics for analyzing the type and frequency of activities involved in software development, improving the project quality, and community growth. 
• The Value working group creates metrics for identifying the degree to which a project improves people’s lives beyond the software project, the degree to which the project is valuable to a user or contributor, and the degree to which the project is monetarily valuable from an organization point of view. 
• The Risk working group creates metrics to understand the quality of a specific software package, potential intellectual property issues, and understand how transparent a given software package is concerning licenses, dependencies, etc.

The Mozilla project collaborated with Bitergia and Analyse & Tal to build an interactive network visualization of Mozilla’s contributor communities. By visualizing different metrics, they were able to find that Mozilla has not only one community but many communities concerning other areas of contributions, motivations, engagement levels, etc. Based on that, they built a report to visualize how these different communities are interconnected.

LFX Insights

Many projects such as Kubernetes and TARS use the LFX Insights tool to analyze their community. 

The LFX Insights dashboard helps project communities evaluate different metrics concerning open source development to grow a sustainable open source ecosystem. The tool has distinct features to support various stakeholders [2], such as

• Maintainers and project leads can get a multi-dimensional reporting of the project, avoid maintainer burnout, ensure the project’s health, security, and sustainability.
• Project marketers and community evangelists can use the metrics to attract new members, engage the community, and identify opportunities to increase awareness.
• Members and corporate sponsors can know which community and software to engage in, communicate the impact within the community, and evaluate their employees’ open source contributions.
• Open source developers can know where to focus their efforts, showcase their leadership and expertise, manage affiliations and their impact.

The source code repository includes the number of commits in total and by contributor, the number of contributors, the top contributors by commits, and the companies that mainly contribute to the project. Users can extract Pull requests (PRs) from many tools such as Gerrit and GitHub. Furthermore, users, maintainers, and contributors to Linux Foundation projects, such as TARS, can extract various metrics from LFX Insights. 

Similarly to commits, the number of PRs in total, by contributor, and by company. The tool also calculates the average time to review the PR and the PRs that are still to be merged. You can also extract metrics for issues and continuous integration tools. Besides that, LFX Insights allows projects to collect communication and collaboration information from different communication channels such as mailing lists, Slack, and Twitter.

Projects might have different goals when using LFX Insights. The TARS project, part of the TARS Foundation, uses the LFX Insights tool to have a big picture of each sub-project (such as TARSFramework, TARSGo, etc.). Through the dashboards created by the LFX Insights tool, the TARS community can know the statistics of each project and the community as a whole (see Figure 1 and 2).

Using LFX Insights tools, the TARS community analyzes how many people contribute to each project and which organizations contribute to TARS. Additionally, they extract the number of commits and lines of code contributed by each contributor. The TARS community believes that by analyzing such metrics, they can attract and retain more contributors.

About the authors: 

Isabella Ferreira is an Ambassador at the TARS Foundation, a cloud-native open-source microservice foundation under the Linux Foundation.

Mark Shan is the Chair at Tencent Open Source Alliance and also Board Chair of the TARS Foundation Governing Board. 

REFERENCES

[1] Jansen, Slinger. “Measuring the health of open source software ecosystems: Beyond the scope of project health.” Information and Software Technology 56.11 (2014): 1508-1519.

[2] https://www.youtube.com/watch?v=hwTOrDg3LsI

[3] https://opensource.com/bus/16/8/measuring-community-health

[4] https://dzone.com/articles/-measuring-metrics-in-open-source-projects

[5] https://opensource.com/article/20/5/open-source-program-office

[6] https://fossa.com/blog/building-open-source-program-office-ospo/

The post Measuring the Health of Open Source Communities appeared first on Linux.com.

The recent presidential Executive Order on Cybersecurity focuses on producing and consuming SBOMs (Software Bill of Materials). SBOMs are especially critical for a national digital infrastructure used within government agencies and in critical industries that present national security risks if penetrated. SBOMs improve understanding of those software components’ operational and cyber risks from their originating supply chain; however, their use is not widespread.

The SBOM readiness survey is the Linux Foundation’s first project addressing how to secure the software supply chain. Software producers and consumers will be surveyed to better understand organizational approaches to software development, procurement, compliance, and, most important, security.

Key questions the survey will address include:

• How concerned is your organization about software security?
• How familiar is your organization with SBOMs?
• How ready is your organization to consume and produce SBOMs?
• What is your commitment to the timeline for addressing SBOMs?
• What benefits do you expect to derive from SBOMs?
• What concerns you about SBOMs?
• What capabilities are needed in SBOMs?
• What does your organization need to improve its SBOM operability?
• How important are SBOMS relative to other ways to secure the software supply chain?

Data from this survey will enable the development of a maturity model to establish the value of SBOMs within software supply chains over time. To take the 2021 SBOM Readiness Survey, click the button below.

After arriving at the survey landing page, you may also choose to issue your responses in German, Russian, French, Chinese, Japanese, or Korean.

The post Please participate in the Linux Foundation Cybersecurity Survey appeared first on Linux.com.

The post What Is OpenIDL, the Open Insurance Data Link platform? appeared first on Linux.com.

The primary source of United States federal government restrictions on exports are the Export Administration Regulations or EAR. The EAR is published and updated regularly by the Bureau of Industry and Security (BIS) within the US Department of Commerce. The EAR applies to all items “subject to the EAR,” and may control the export, re-export, or transfer (in-country) of such items.

Under the EAR, the term “export” has a broad meaning. Exports can include not only the transfer of a physical product from inside the US to an external location but also other actions. The simple act of releasing technology to someone other than a US citizen or lawful permanent resident within the United States is deemed to be an export, as is making available software for electronic transmission that can be received by individuals outside the US. 

This may seem alarming for open source communities, but the good news is open source technologies that are published and made publicly available to the world are not subject to the EAR. Therefore, open source remains one of the most accessible models for global collaboration.

Click here to read the Linux Foundation blog

The post Understanding US export controls with open source projects appeared first on Linux.com.

Read More at The Standards Blog

The post All About CLAs and DCOs appeared first on Linux.com.

“…a CII Best Practices badge, especially a gold badge, shows that an OSS project has implemented a large number of good practices to keep the project sustainable, counter vulnerabilities from entering their software, and address vulnerabilities when found. Projects take many such steps to earn a gold badge, and it’s a good thing to see.”

Read more at the Linux Foundation

The post Why CII best practices gold badges are important appeared first on Linux.com.

When source code, documentation and other content is contributed to an OSS project, the copyrights in those contributions typically remain owned by the original copyright holders¹.

[Source: Linux Foundation Blog]

The post Copyright Notices in Open Source Software Projects appeared first on Linux.com.

For example, perhaps your organization believes that the latest GPL license (GPLv3) is the best for your company due to its updated provisions. If you mandated GPLv3 for all future contributions vs. GPLv2, you would be prohibited from contributing code to the Linux kernel, since that is a GPLv2 project and will likely remain that way for a very long time. Your engineers, being part of that open source community project, would know that and would automatically choose GPLv2 in the absence of such a mandate.

Bottom line: Enabling engineers to make these decisions is wise and efficient.

To the extent your organization may have to restrict the use of certain licenses (e.g., due to certain intellectual property concerns), this should naturally be part of your guidelines or policy.

Read more at OpenSource.com

The post Let your Engineers Choose the License: A Guide appeared first on Linux.com.