The OSS Good Governance Manual is intended as a guide for companies that promotes the proper use of open source software as well as the protection of companies against technical, legal and IP threats.
The manual is the product of the new Open Source Program Office (OSPO) alliance, a coalition of Europe’s leading open source non-profit organizations, including OW2, Eclipse Foundation, OpenForum Europe and Foundation for Public Code, with a mission to raise awareness free software and promote their structured and professional management by companies and administrations.
There are two perspectives on running an open source software project; one is that of the manager / maintainer / contributor and the other that of the company which depends on it. I have covered the first aspect of “The Open Source Guides To Managing Open Source Software Projects” which examines another manual, a set of guides from Github detailing the ins and outs of launching, managing, maintaining and running. contribution to open source projects.
The flip side is getting the software out of the hands of the manufacturers and using it in an enterprise environment, which frequently requires integration with other software, especially libraries. Of course, a business can also play the role of contributor by giving back to the project and to the community at large.
We all know how ubiquitous oss software is in all environments, whether at home, at work or in corporate environments. It is so pervasive that has infiltrated the collective mentality so much that the European Commission has just announced that it is adopting new rules that will allow its software solutions to be open source and accessible to the public whenever there are potential benefits for citizens, businesses or other public services. And for good reason, a study has shown that:
investing in open source generates on average four times the returns for the EU economy.
The European Commission’s love for open source goes back further than the recent initiative, when it launched a state-sponsored bug bounty that showed that among bureaucrats there were tech savvy people. who understood the true value of OSS software to society, and as such the impact when its security goes wrong.
This bug bounty is part of the Free and Open Source Software Audit (FOSSA) project, thanks to Julia Reda, MEP from the EU Pirate Party, who started the project thinking enough is enough after Serious vulnerabilities have been discovered in key infrastructure components like OpenSSL. This prompted her to involve the European Commission in contributing to internet security. More information on this subject in “EU Bug Bounty – Software security as civil law”.
So, having established how beneficial free software is to society, let’s take a look at it in a business setting. A business has to implement professional management and juggle a lot of baggage when adopting open source software, especially when compiling code with a mix of dependencies. The OSS good governance manual has classified these activities into:
Manage legal compliance
Manage software vulnerabilities
Manage software dependencies
Manage key indicators
Perform code reviews
Promote best practices in open source development
Contribute to open source projects
Belong to the open source community
Engage in open source projects
Support open source communities
Engage with open source providers
Publicly affirm the use of open source
Open source procurement policy
Set up an open source corporate governance strategy
Awareness at C level
Open source and digital sovereignty
Open source enables innovation
Open source at the service of digital transformation
with the following requirements in mind:
Any type of organization is covered: from SMEs to large companies and non-profit organizations, from local authorities (eg town halls) to large institutions (eg European or governmental institutions). The framework provides the building blocks of a strategy and guidance for its achievement, but the way in which activities are carried out depends entirely on the program context and is the responsibility of the program manager.
No assumption is made on the level of technical knowledge within the organization or field of activity. For example, some organizations will need to set up a comprehensive training program, while others may simply offer ad-hoc material to teams.
Each activity stub is divided into the following sections:
- The description
- Opportunity assessment
- Progress assessment
As a working example of what each stub includes, let’s give a small sample of the Manage Software Vulnerabilities activity.
Its code is as secure as its less secure part. Recent cases (eg heartbleed1, equifax2) have demonstrated the importance of checking for vulnerabilities in parts of code that are not directly developed by the entity. The consequences of exposures range from data leaks (with a huge impact on reputation) to ransomware attacks and downtime of services threatening the business.
Any business that uses software should monitor its vulnerabilities by:
- its infrastructure (e.g. Cloud infrastructure, network infrastructure, data stores),
- its business applications (HR tools, CRM, internal and customer data management),
- its internal code: for example the company’s website, internal development projects, etc. , and
- all direct and indirect dependencies of software and services.
Little is known about the ROI of vulnerabilities until something bad happens. Consider the consequences of a major data breach or service downtime to estimate the true cost of vulnerabilities.
There should be a dedicated person or team to monitor vulnerabilities and easy-to-use processes that developers can rely on. Vulnerability assessment is an integral part of the continuous integration process and users are able to monitor the current state of risk in a dedicated dashboard.
The following checkpoints show the progress of this activity:
- Business is covered when all internal software and services are evaluated and monitored for known vulnerabilities.
- Activity is covered when a dedicated tool and process is implemented in the software production chain to avoid introducing problems into daily development routines.
- A person or team is responsible for assessing the risk of VEC / vulnerability versus exposure.
- One person or team is responsible for sending CVE / vulnerability to affected people (SysOps, DevOps, developers, etc.).
- GitHub tools
GitHub provides guidelines and tools for securing code hosted on the platform. See the GitHub documentation for more information.
GitHub provides Dependabot to automatically identify vulnerabilities in dependencies.
- Eclipse Steady is a free, open source tool that scans for vulnerabilities in Java and Python projects and helps developers mitigate them.
- OWASP dependance-check: an open source vulnerability scanner.
- OSS Review Toolkit: An open source orchestrator capable of collecting security advisories for used dependencies from configured vulnerability data services.
In the Tools section, I would add Semgrep or Qodana.
Of course, another thorny issue is the management of Software dependencies. Supply chain security is all the rage right now. We looked at the implications as well as mitigation options in “Does Sigstore Really Secure the Supply Chain?” The Linux Foundation’s response to supply chain attacks:
To build useful software, we do not reinvent the wheel but we base ourselves on work already done and delivered in the form of libraries. The problem is that even a poor open source project can have loads of such dependencies which themselves depend on others, forming a long chain. This is not a problem in itself, unless some malicious code or a security vulnerability finds its way anywhere in this chain.
The manual has a good list of tools, resources and tips. At a glance, he recommends:
- Perform regular audits on dependencies and intellectual property requirements to mitigate legal risks. Ideally, integrate dependency management into the continuous integration process so that issues (new dependency, license mismatch) are identified and corrected as soon as possible.
- Keep track of dependency vulnerabilities, keep users and developers informed.
- Inform people of the risks associated with the wrong license.
- Provide a simple solution for projects to configure license checking on their code base.
- Communicate its importance and help projects add it to their CI systems.
- Set up a visible KPI for the risks related to dependency.
The first version of the GGI manual was published in October 2021. Further iterations are planned to improve the content and better articulate the implementation methodology.
Open Source Guides for Managing Open Source Software Projects
EU Bug Bounty – Software Security as a Civil Law
Does Sigstore Really Secure the Supply Chain?
Track open source vulnerabilities with Google’s OSV
or send your comment to: [email protected]