Open-source policy templates

[cclements]

Dear ISC^2 Colleagues,

I've been tasked with creating a policy that governs the adoption, use, and contribution to open-source projects, libraries, and software.  I started with NIST and CSF to find their recommendations but haven't found much more than "the organization devises an open-source policy".

I've identified some concerns.  Firstly, what are your suggestions?  Did I miss something? Secondly, do you have a template or actual policy you can share that will serve as a jumping off point?

1. License (which open-source licenses shall we permit).
2. Sanctioning process - establish a process by which open-source projects, code, libraries, or software is reviewed and "sanctioned for use".  The result shall be a curated repository of projects or packages, or perhaps a list?
   1. Favor popular projects.
   2. Observe the patch frequency.
   3. Observe response to vulnerabilities.
3. Mandatory SCA for projects using third party (open source) libraries,
4. Create a process by which a security lead is informed of vulnerabilities in a sanctioned project.
5. Manual code review (this may not be practical.
6. Create a policy addressing contribution to open-source projects.  Consider the protection of the company's IP. 

Thanks!

Chris

[Steve-Wilme]

If you need it to scale, you'd need a tools to scan repos and follow dependencies, because manual code review won't scale.  You'll also need tooling to enable response to a critical vulnerability found in your code and any third party products that you use.  Google log4j and you'll find that library is in so many things.

[JoePete]

I'm curious, why the distinction of open-source software? Shouldn't the concerns regarding adoption, use, and contribution apply to all software? The licensing model is a bit of a red herring.

I'll give you a case in point that speaks to your last bullet. Many years ago I was working on a project with a large consultancy on the adoption of new enterprise-wide software for HR and financials. As part of the implementation, we collaboratively developed some code to work with this third-party proprietary software, but we never resolved who owned it (or really thought about it); we were just trying to get the job done. Had we a policy (like you are looking at), it would have been helpful, but the licensing wouldn't have mattered. I think if you go into any business today, you will find a range of licensing. I would encourage you to zoom out one level and think in terms of "enterprise software," not just open-source.

[Caute_cautim]

@cclements   See my posting under Tech Talk, you may find the website and links useful to you quest.

There are contacts there as well, who you can reach out too and ask further questions.

Check out:  https://openssf.org/resources/guides/

Regards

Caute_Cautim

[cclements]

Thank you for your response. I am still pondering your first question, why open-source software is any different than, COTS for instance.  Beyond there being no neck to choke, I am not sure.

As to the question about licenses, it was more about under which license the open-source software as released and what that obligates us, as an organization, to. 

Chris

[cclements]

Thanks for the reply. I will certainly check out this link.

Chris

[denbesten]

I would defer the "contribution to...." part to the HR/Legal departments since that aspect is more about of use-of company time and Intellectual Property; whereas the others belong in our corner because they are more of an IT-based risk-management discussion.

I am a big fan of white-listing software (or manufacturers or versions, depending on your paranoia level).   From a "policy" perspective you might focus on "eligible for vendor (or 3rd party) support" instead of "current or prior version".

We also have our legal department review all licenses, open-source or otherwise as part of our onboarding process.   One good thing about open-source its habit of reusing licenses (bsd, gpl, etc) which tends to to reduce the cost/time for review.

[Caute_cautim]

@denbestenYes, we do the same regularly.

Regards

Caute_Cautim

[Steve-Wilme]

You might also find that in many companies there is a dedicated SAM (Software Asset Management) team who could take on responsibility for compliance with license terms, audits etc. rather than push this responsibility to legal counsel. 

[Caute_cautim]

@cclements   Check out the explanations on the differences between open-source types, this may help you understand.   Within my organisation we have to undergo mandatory annual certification, on a regular basis.

https://snyk.io/learn/open-source-licenses/

Regards

Caute_Cautim