Open Source Security and Compliance (Internal & External)
Worried about passing an IT compliance audit? In this video, learn about how to meet open source security and compliance requirements, with examples of internal compliance policies and external compliance regulations that may apply to your organization.
This video is from the webinar, “Open Source Security and Compliance: What Organizations Need to Know” that took place on March 23, 2023. It features Javier Perez, Chief OSS Evangelist and Senior Director of Product Management at Perforce Software.
Watch the complete webinar here: https://ter.li/xc2d7h
- -
About OpenLogic by Perforce:
OpenLogic offers end-to-end enterprise support for organizations using open source software in their infrastructure. With support for over 400 open source packages, guaranteed SLAs, and direct access to highly experienced Enterprise Architects, OpenLogic customers benefit from 24x7 ticket-based technical support, professional services, and training.
Follow OpenLogic on LinkedIn, Twitter, and don’t forget to subscribe to our YouTube channel for more videos on all things open source!
Transcript (lightly edited for clarity):
Now, within your organization, you think, well, what about the compliance part? There are two pieces: internal compliance and external compliance. Internal compliance is something many organizations have – the IT team has policies and rules that you have to comply with. That's what we're referring to when we say internal compliance.
A couple of examples that relate to Open Source security. One, there might be a requirement to be on the latest release, have installed the latest updates and patches, which of course will address vulnerabilities.So you stay compliant if you are on the latest versions of latest releases. That sounds easy, right? I mean, of course it's easier said than done. Many organizations are establishing this type of policy because it makes all the sense on the world to be on the latest versions. Now, some of you might think, well, look, I mean in reality it's really much harder to do an upgrade -- you have to test and you don't want to touch your production application. I know. It's not that easy, but obviously the recommendation is to test in pre-production. Make sure everything works, focus on that. And at the end of the day, your organization, and your software, will be safer.
Another internal compliance policy could be to not be on end-of-life software, not have any end-of-life software.So make sure that you can check that box as well. Another aspect is having external technical support. Some internal compliance policies require formal technical support for all software. And that makes sense and will help you with security. Not only security, but also the expertise aspect. Having the support from other professionals in areas that you might not know. And again, because it's open source and it’s growing so much, there's so much to learn, there's so much that we don't know.
Finally, having the appropriate Open Source licensing. That's when you are publishing, especially when you're publishing or commercializing software. You want to make sure that all your components have the proper licensing.
Now with external regulation compliance, I left a little bit more text because I wanted you to read the actual exact sentences from these regulations. For example, the PSI-DSS requirement, which is for credit card transactions and things like that. There's specific mention of vendor-supplied security patches. To be in compliance, you have to apply the security patches.
Another is the CIS controls, the CIS benchmarks and the CIS controls. There are a couple of things to notice there. 2.2 and 16.4 mention you can only be on currently supported software and that components must still are supported, meaning they're not end of life. So going back to what I was mentioning earlier, these policies highlight the risks associated with unsupported software. Again, unsupported software meaning either it's open source that no one is supporting, officially supporting, commercially supporting, or it's end-of-life in the project, no one is supporting that.
The FedRAMP policy for the US Federal Government mentions components that are no longer available for the developer, again, relating to end-of-life, older versions of the software. And there's a HIPAA security rule that talks about protection against malicious software and includes updated patches in all systems. So in this case, compliance is about making sure that you are up to date on patches.
Here's one more example: the ISO, which is also called the Open Chain Standard about OSS compliance. It talks about proper open source licensing. Also it says that you should have documented processes to handle open source software, verification via a Software Bill of Materials, and promote engagement and collaboration with open source communities and open source projects.