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?
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.
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.
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.
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.
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.