The OSS Good Governance Handbook is designed as a guide for businesses that encourages the appropriate use of open source software as well as protecting businesses from technical, legal, and IP threats.
The manual is the brainchild of the new Open Source Program Office (OSPO) alliance, a coalition of leading European open source non-profit organisations, including OW2, Eclipse Foundation, OpenForum Europe and Foundation for Public Code, with the mission to develop awareness of free software and promote its structured and professional management by companies and administrations.
There are two perspectives on managing an open source software project; one is that of the manager/maintainer/contributor and the other that of the company that depends on it. I covered the first aspect in “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 contributing to open source projects.
The flip side is taking the software out of the hands of manufacturers and using it in an enterprise environment, which often requires integrating it with other software, especially libraries. Of course, a company can also play the role of contributor by giving back to the project and the wider community.
We all know how ubiquitous oss software is in every environment, be it home, work or business. It’s so ubiquitous that it has infiltrated the collective mindset 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 publicly available whenever that there are potential benefits for citizens, businesses or other public services. And for good reason, since a study has shown that:
investing in open source generates on average four times higher 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 are tech-savvy people. who understand 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 EU Pirate Party MEP Julia Reda, who started the project thinking enough was enough after serious vulnerabilities were discovered in key infrastructure components like OpenSSL. This prompted her to involve the European Commission in its contribution to Internet security. More about this in “EU Bug Bounty – Software Security as a Civil Right”.
So, having established how beneficial free software is to society, let’s look at it in the context of a business. A company must implement professional management and juggle a lot of baggage when adopting open source software, especially when compiling code that has a mixture of dependencies. The OSS good governance manual has classified these activities into:
Trust activities
Manage legal compliance
Manage software vulnerabilities
Manage software dependencies
Manage key indicators
Run code reviews
Cultural activities
Promoting open source development best practices
Contribute to open source projects
Belong to the open source community
HR point of view
Upstream first
Mobilization activities
Participate in open source projects
Support open source communities
Engage with open source vendors
Publicly affirm the use of open source
Open source procurement policy
Strategic activities
Establish an enterprise open source governance strategy
Level C awareness
Open source and digital sovereignty
Open source at the service of innovation
Open source at the service of digital transformation
keeping in mind the following requirements:
All types of organizations are covered: from SMEs to large companies and non-profit organisations, from local authorities (eg city councils) to large institutions (eg European or governmental institutions). The framework provides the building blocks for a strategy and guidance for carrying it out, but how activities are carried out depends entirely on the context of the program and is up to the program manager.
No assumptions are made about the level of technical knowledge within the organization or business area. For example, some organizations will have to set up a complete training course, while others may simply offer ad-hoc material to the teams.
Each activity sheet is divided into the following sections:
- The description
- Opportunity assessment
- Progress assessment
- Tools
- Recommendations
- Resources
As a practical example of what each stub includes, let’s give a small sample of the Manage Software Vulnerabilities activity.
The description
A code is only as secure as its least secure part. Recent cases (eg heartbleed1, equifax2) have demonstrated the importance of checking for vulnerabilities in parts of the code that are not directly developed by the entity. The consequences of exposures range from data leaks (with huge reputational impact) to ransomware attacks and the unavailability of business-threatening services.
Opportunity assessment
Any company that uses software should monitor its vulnerabilities in:
- its infrastructure (e.g. Cloud infrastructure, network infrastructure, data stores),
- its business applications (HR tools, CRM, management of internal and customer data),
- its internal code: for example the company’s website, internal development projects, etc. , and
- all direct and indirect software and service dependencies.
The ROI of vulnerabilities is little known until something serious happens. Consider the consequences of a major data breach or service unavailability to estimate the true cost of vulnerabilities.
Progress assessment
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 can monitor the current risk status in a dedicated dashboard.
The following checkpoints demonstrate the progress of this activity:
- Activity is covered when all internal software and services are assessed and monitored for known vulnerabilities.
- The activity is covered when a dedicated tool and process is implemented in the software production chain to avoid the introduction of problems into day-to-day development routines.
- A person or team is responsible for assessing CVE risk/vulnerability versus exposure.
- A person or team is responsible for sending CVE/vulnerability to relevant people (SysOps, DevOps, developers, etc.).
Tools
- GitHub Tools
GitHub provides guidelines and tools for securing code hosted on the platform. See the GitHub docs for more info.
GitHub provides Dependabot to automatically identify vulnerabilities in dependencies. - Eclipse Steady is a free, open-source tool that scans Java and Python projects for vulnerabilities and helps developers mitigate them.
- OWASP Dependency Checker: An open source vulnerability scanner.
- OSS Review Toolkit: an open-source orchestrator capable of collecting security reviews 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 the means of mitigation 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 rely on the work already done which is grouped in the form of libraries. The problem is that even a mediocre open source project can have such dependencies which themselves depend on others, forming a long chain. This is not a problem in itself, unless malicious code or a security vulnerability is found anywhere in this chain.
The manual has a good list of tools, resources, and tips. At a glance, he recommends:
- Perform regular audits of IP dependencies and requirements to mitigate legal risk. Ideally, integrate dependency management into the continuous integration process so that issues (new dependency, license incompatibility) are identified and fixed as soon as possible.
- Keep track of dependency related vulnerabilities, keep users and developers informed.
- Educate people about the risks associated with poor licensing.
- Provide a simple solution for projects to implement license verification on their code base.
- Communicate its importance and help projects add it to their CI systems.
- Set up a visible KPI for dependency risks.
The first version of the GGI Handbook was published in October 2021. Further iterations are planned to improve the content and better articulate the implementation methodology.
More information
Open Source Good Governance Handbook
Related Articles
Open Source Guides for Managing Open Source Software Projects
EU Bug Bounty – Software security as a civil right
Does Sigstore really secure the supply chain?
Track open source vulnerabilities with Google’s OSV
To be informed of new articles on I Programmer, subscribe to our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook Where LinkedIn.
comments
or send your comment to: comments@i-programmer.info
