Welcome to the Compliance for Charity blog

To re-iterate the mantra we have become accustomed to in the past few months; We live in strange times, and we are all affected in one way or the other by the pandemic and the effects it has on our society, businesses, and our private life.

While I have had the privilege and good fortune of living in a country with moderate constraints to daily life and being in a business that has been only moderately impacted by the effects of lockdowns and other restrictions, I see many around me that are in a much worse situation, and I wanted to do something about it.

I figured that most of my peers in my industry are probably as well off as I am, and there are probably hundreds of worthy initiatives around the globe that deserves support and that can help people in need.

This is why we started the “Compliance for Charity” blog, and I invite you all to be a part of it. The promise of the blog is the idea of open source compliance and security practitioners sharing knowledge in the field, and for each contributed blog post our company FossID will donate 500 USD to a charity chosen by the contributor.

With this first post I would like to raise awareness about Médecins Sans Frontières Sweden and the work they do in humanitarian crises and armed conflicts.

Do you have an idea for a topic and want to support a charity of your choice? Then, fill in the post submission form found here! We anticipate content primarily in relation to open source compliance, open source security, Software Composition Analysis (SCA), tools and toolchains, policy enforcement, license evolution, the recent ISO/IEC 5230:2020 etc.

Accepted blog posts are initially at the discretion of the team at FossID managing this effort, but if we see interest we will open up to a wider circle where you can be part of the review board. Likewise, if you are interested in becoming a sponsor this can be explored further down the road. The idea of the Compliance for Charity blog is to embrace the open source mentality and the setup is meant to be collaborative and recognizable.

Oh, and what about knowledge? Shouldn’t I be the first to share an insight into open source compliance? Of course! Here goes:

Good Open Source Compliance Practices Enable Innovation

I recently found out that the European Commission devised an open source software strategy for the next few years. The strategy is quite extensive and stipulates several areas and milestones for the European Union to build new, innovative digital solutions that support common policies and activities, and work towards technological sovereignty. I knew that open source is ubiquitous in the private sector, but I was glad to read that the principles of incremental innovation and sharing of knowledge and skills also made it to the public sector and that the goals were described so clearly and insightful.

The guiding principles in the European Commission strategy were as clear as those of any modern software company, and can surely be adopted by anyone seeking to develop software today:

• Think open – Open source solutions will be preferred when equivalent in functionality, total cost, and cyber security.
• Transform – Harness the working principles of open source; innovate and co-create, share and reuse, and build user-centric, data-driven public services.
• Share – Share code and enable incidental contributions to related open source projects.
• Contribute – Strive to be an active member of the diverse open source ecosystem.
• Secure – Make sure the code used and code shared is free from vulnerabilities by applying continuous security testing.
• Stay in control – Promote open standards and specifications that are implemented and distributed in open source.

To me, it is also clear that open source compliance is a common denominator in all activities surrounding software development, and a catalyst for innovation when implemented properly through appropriate processes, automation, and knowledge. Let me expand my thinking by touching upon five areas that I find particularly interesting:

• Compliance as a safety net for innovation
• Friction-less supply chains
• Freedom to re-use code of all sizes,
• Software inventory and Confidentiality, and
• Automation.

Compliance as a safety net for innovation

The open source is probably expanding more now than it has ever done before. Last time I checked I estimated the GitHub growth alone at one new open source project every second(!) – and that is just adding to the already existing 100+ million projects out there. Sure, I hear you, many of those are forks, but still, the growth is phenomenal.

From a compliance perspective it is a daunting task to build a Bill of Materials of accuracy with such a vast amount of projects to relate to. And it puts pressure on tools solutions (both open source and commercial) to provide comprehensive coverage, and being able to provide accurate identifications and provenance for all open source software so that it can be treated correctly, having license obligations honored, etc.

The value of that coverage is that it provides a safety net to use and adopt more open source, and to innovate more freely and much safer.

Friction-less supply chains

Not long ago, compliance was something companies managed internally, but now it affects the whole supply chain. Supplier code likely introduces open source software with licenses that their customers need to adhere to, and sometimes that same software also introduces security vulnerabilities that need to be addressed. In order to build trust and reduce friction in the supply chain it is of great help to introduce standardized processes and universal evidence of conformity and security. The OpenChain process and its recent ISO certification is an important step in standardizing the compliance of the entire supplier base.

Freedom to re-use code of all sizes

Re-use of code drives innovation and time to market. When building your system, you might start off with a set of whole open source software components, and as you go along you might only need component subsets, maybe just a few files. Even further down the line you might need to implement very specific functionality or solve the way that a particular instruction is written, in which case you might just drop a few lines of code into your solution. Those lines of code might originate from within an open source project someplace, or a question answered in a user contribution forum like StackOverflow.

Regardless of the size of the open source code that you introduce into your system, they all have licenses attached to them. To fully embrace the benefits of open source it is essential to give your developers the freedom to re-use code, but that requires tools that are able to find and identify open source code of all sizes.

Software inventory and confidentiality

Assuming that you are on top of your compliance game, you have policies and processes in place, and you have an accurate and up-to-date software inventory. Your inventory is your greatest asset, but it is also a possible attack vector. Not seldomly are various governments responsible for cyber-attacks, which means that the attacks are probably well funded and have specific purposes to disrupt business and society.

Knowing the exact component version of your open source components can expose you to risk and potential breach, and that is a reason I have seen recently of customers in sensitive businesses choosing to conduct their entire compliance effort within their premises and never sending any data outside of it, be it source code, binaries, or even cryptographic hashes even on secure channels.

Confidentiality is also extremely important in audit situations in mergers and acquisitions type of situations. The requirements reach extreme levels when publicly traded companies are acquired, so the capability of not exposing the source code in the technical due diligence is a top priority.

Automation

Speed of development is everything these days. You cannot lose business momentum by bottlenecks in your development pipeline and the biggest hurdle is human intervention. All aspects of development should be automated as far as possible, and your compliance effort is no exception.

Real-time compliance is like a safety net where developers can innovate and use any open source software they find useful and only be interrupted when there is a compliance of security issue identified.

That is all, friends. I hope you had a pleasant read, and I hope you join me and submit a blog post for a charity of your choice!

Oskar