Professional Open Source Software Management
Written by Nikos Vaggalis   
Thursday, 16 December 2021

The OSS Good Governance Handbook is intended as guide for enterprises that fosters proper use of open source software as well as safeguarding businesses from technical, legal and IP threats.

ospo

The handbook is the brain child of the newly formed Open Source Program Office (OSPO) alliance, a coalition of leading European open source non-profit organizations including OW2, Eclipse Foundation, OpenForum Europe, and Foundation for Public Code, with the mission to grow awareness for open source software and promote its structured and professional management by companies and administrations.

ospo2

There are two perspectives on managing an open source software project; one is that of manager/maintainer/contributor and the other that of the enterprise relying on it. I've covered the first aspect in "The Open Source Guides To Managing Open Source Software Projects" which looks at another handbook, a set of guides by Github detailing the ins and outs of launching, managing, maintaining and contributing to open source projects.

The other side of the coin is taking the software out of the hands of the makers and using it in an enterprise environment, which frequently requires integrating it with other software, especially libraries. Of course, an enterprise can play the role of the contributor too by giving back to the project and the wider community.

We all know how ubiquitous oss software is in every environment, be it at home, work or in enterprise settings. It's so pervasive that has infiltrated the collective mindset so much that the European Commission has just announced that it adopts new rules that will enable its software solutions to be open sourced and publicly accessible whenever there are potential benefits for citizens, companies or other public services. And with good reason as a study has shown that:

the investment in open source leads on average to four times higher returns to the EU economy.

The EU Commission's love with open source goes further back than the recent initiative, when it had kickstarted a state-sponsored bug bounty that showed that amongst the 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 Julia Reda MEP of the EU Pirate Party, who started the project thinking that enough is enough after severe vulnerabilities were discovered in key infrastructure components like OpenSSL. This prompted her to involve the EU Commission in contributing to the security of the Internet. More on that in "EU Bug Bounty - Software Security as a Civil Right".

So after establishing how beneficial is OSS to society, let's look into it from an enterprise setting. An enterprise has to implement professional management and juggle a lot of baggage when adopting open source software, especially when compiling code that features a mix of dependencies. The OSS Good Governance Handbook has categorized those activities into:

Trust activities
Manage legal compliance
Manage software vulnerabilities
Manage software dependencies
Manage key indicators
Run code reviews

Culture gactivities
Promote open source development best practices
Contribute to open source projects
Belong to the open source community
HR perspective
Upstream first

Engagement activities
Engage with open source projects
Support open source communities
Engage with open source vendors
Publicly assert use of open source
Open source procurement policy

Strategy activities
Setup a strategy for corporate open source governance
C-Level awareness
Open source and digital sovereignty
Open source enabling innovation
Open source enabling digital transformation

with the following requirements in mind:

Any type of organisation is covered: from SMEs to large companies and not-for-profit organisations, from local authorities (e. g. town councils) to large institutions (e. g. European or governmental institutions). The framework provides building blocks for a strategy and hints for its realisation, but how the activities are executed depends entirely on the program’s context and is up to the program manager.

No assumption is made about the level of technical knowledge within the organisation or the domain of activity. For example, some organisations will need to set up a complete training curriculum, while others might simply propose ad-hoc material to the teams.

Each activity stub is split into the following sections: 

  • Description
  • Opportunity Assessment
  • Progress Assessment
  • Tools
  • Recommendations
  • Resources 

As an hands-on example of what each stub includes, let's provide a trimmed down sample of the Manage software vulnerabilities activity.

Description
One’s code is as secure as its least secure part. Recent cases (e. g. heartbleed1, equifax2) have demonstrated the importance of checking vulnerabilities in parts of the code that are not directly developed by the entity. Consequences of exposures range from data leaks (with tremendous reputational impact) to ransomware attacks and business-threatening unavailability of services.

Opportunity Assessment
Any company that uses software has to watch its vulnerabilities in: 

  • its infrastructure (e. g. Cloud infrastructure, network infrastructure, data stores),
  • its business applications (HR, CRM tools, internal and customers-related data management),
  • its in-house code: e. g. the company’s website, internal development projects, etc. , and
  • all direct and indirect software and services dependencies.

The ROI of vulnerabilities is little known until something bad happens. One has to consider the consequences of a major data breach or unavailability of services 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 for developers to rely on. Vulnerabilities assessment is a standard part of the continuous integration process, and people are able to monitor the current state of risk in a dedicated dashboard.

The following verification points demonstrate progress in this Activity: 

  • Activity is covered when all in-house software and services are assessed and monitored for known vulnerabilities.
  • Activity is covered when a dedicated tool and process is implemented in the software production chain to prevent the introduction of issues in the daily development routines.
  • A person or team is responsible for evaluating CVE/vulnerability risk against exposure.
  • A person or team is responsible for dispatching CVE/vulnerability to concerned people (SysOps, DevOps, developers, etc). 

Tools 

  • GitHub tools
    GitHub provides guidelines and tools to secure code hosted on the platform. See GitHub docs for more information.
    GitHub provides Dependabot to identify vulnerabilities in dependencies automatically.
  • Eclipse Steady is a free, open source tool that analyses Java and Python projects for vulnerabilities and helps developers mitigate them.
  • OWASP dependency-check: an open source vulnerability scanner.
  • OSS Review Toolkit: an open source orchestrator able to collect security advisories for used dependencies from configured vulnerability data services.

Under the Tools section I would add Semgrep or Qodana

Of course another thorny issue is managing the Software Dependencies. Supply chain security is all the rage right now. We've taken a look at the implications as well as the ways of mitigation in "Does Sigstore Really Secure The Supply Chain?" the Linux Foundation's answer to supply chain attacks:

To build useful software we don't reinvent the wheel but we base on work already done coming bundled in the form of libraries. The problem is that even a mediocre open source project can have loads of such dependencies which themselves depend on others, forming a lengthy chain. Not a problem per se unless malicious code or security vulnerability finds its way anywhere in this chain.

The handbook' has a good list of tools, resources and guidance. At a glance it recommends: 

  • Conduct regular audits about the dependencies and IP requirements to mitigate legal risks. Ideally, integrate dependencies management in the Continuous integration process so that issues (new dependency, licence incompatibility) are identified and fixed as soon as possible.
  • Keep track of dependency-related vulnerabilities, keep users and developers informed.
  • Inform people about the risks associated with wrong licencing.
  • Propose an easy solution for projects to set up licence checking on their codebase.
  • Communicate on its importance and help projects to add it to their CI systems.
  • Set up a visible KPI for dependency-related risks. 

The first release of the GGI Handbook was published in October 2021. Other iterations are planned to improve the content and better articulate the implementation methodology.

 opso1

More Information

 Open Source Good Governance Handbook

Related Articles

The Open Source Guides To 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 about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Banner


Apache Iceberg Rust Released
09/09/2024

Apache has released version 0.3 of Iceberg-rust, an official Rust implementation of the Iceberg high-performance format for huge analytic tables.



Apache Updates Wicket
03/10/2024

Apache Wicket has been updated to version 10.2, following the major release of Wicket 10 earlier this year. The open source Java web framework is now built on top of Java 17, and has a new module test [ ... ]


More News

kotlin book

 

Comments




or email your comment to: comments@i-programmer.info

 

Last Updated ( Thursday, 16 December 2021 )