Unpacking Open Source Compliance

Any organization using open source software, which is basically all organizations, needs a solid understanding of what is meant by open source compliance. Why? Because by proactively adhering to both internal and external compliance requirements, organizations can improve their security posture and establish a sturdy foundation for safeguarding their IT infrastructure and data.

In this blog, we’ll go over both internal compliance and external compliance as it relates to open source software. 

What Is Open Source Compliance?

Open source compliance refers to adherence to policies related to the use of open source software. These policies may be internal and enforced by an organization's IT security team, or externally mandated by an outside source.  

While in general IT compliance refers to adherence of organizations to software development and operation best practices, it can also cover policies, privacy, laws, and security. In the case of the use and creation of open source software, there are four major areas relevant to compliance:

1. Open source license compliance    
2. Availability of support for open source software    
3. Open source security    
4. Release lifecycle of open source software

Although open source software is free and available to anyone, it is highly recommended for organizations to follow internal and external compliance guidance. Failure to comply with the recommendations or controls may result in security risks, breach of software contracts, or even copyright infringement. Open source compliance tools and automation technologies can make it easier to meet, maintain, and enforce compliance with open source software policies. 

Open Source License Compliance

To legally and ethically use open source software, organizations must follow the terms and conditions outlined in the relevant open source licenses. While these licenses give users permission to use, modify, and distribute the open source software freely, there are specific obligations that must be met to remain compliant. Common open source licenses include the GNU General Public License (GPL), Apache License, MIT License, and others. 

Non-compliance with open source licenses can have serious repercussions, from lawsuits and damage to the open source community's trust to potential restrictions on an organization's future use of open source software. By proactively adhering to open source license compliance, organizations can continue to leverage the benefits of open source software while respecting the rights and requirements set forth by the licenses.

Related blog >>How Does Open Source Licensing Work?

Internal Open Source Compliance

Every IT organization defines its own policies that lay out specific criteria required for all their software and hardware infrastructure, development, and operation. Internal open source compliance typically starts with open source license compliance explained above and then can expand into different requirements, like mandating all open source software to be on the latest versions and/or having external technical support.

The most common internal open source compliance requirements include:

• Having all software on latest minor version of the current release
• Not allowing end-of-life (EOL) software in production environments
• Requiring formal technical support for all software or external commercial technical support
• Ongoing monitoring of appropriate licensing in place for all open source components 
• Mandatory security scans to identify vulnerabilities

Why Open Source Compliance Matters

In this on-demand webinar, learn about external open source compliance regulations as well as how to create robust internal compliance policies to protect your business from liability and security breaches. 

External Open Source Compliance

External open source compliance refers to the regulations and industry standards imposed on organizations by external sources. The purpose of these obligations is to ensure security, privacy, and safety. Adhering to external compliance requirements builds trust with employees, business partners, and customers by demonstrating a well-organized approach to all IT infrastructure, including OSS usage and lifecycle management.

Organizations are sometimes subject to compliance assessments carried out by external entities, such as regulatory agencies, third-party auditors, and current or prospective partners, to evaluate the organization's adherence to these external compliance requirements.

The following external IT regulations cover many areas of oversight and compliance as they relate to open source software. Having one or more of these external regulations in place goes a long way toward secured use of open source software.

CIS Controls 2.2 and 16.4

The CIS Controls consist of best practices created to enhance organizations' security posture and provide protection against cyber threats. Among these controls, two specific sections address open source software-related considerations: 

CIS Control 2.2 focuses on Inventory and Control of Software Assets. It recommends creating and maintaining an inventory of all software, including open source software, as well as authorized and unauthorized software that is installed on all systems in the organization's infrastructure. This control emphasizes the importance of maintaining a comprehensive and up-to-date inventory, or software bill of materials (SBOM). SBOMs help organizations monitor and manage their software assets, identify potential security risks, keep track of open source licenses, and improve overall security and compliance.

Similarly, CIS Control 16.4 recommends creating and managing an updated inventory or SBOM of third-party components used in development. This inventory must show any risks that each third-party component could pose. It recommends generating the SBOM at least monthly to identify any changes or updates to these components and validate that the component is still supported. This control impacts open source software that has reached end-of-life or end-of-support, which means no more updates or releases and increased risk of unpatched security vulnerabilities.

ISO/IEC 27001

This international standard for information security management systems (ISMS) outlines the necessary requirements for compliance. In the context of open source software, the standard provides specific controls that organizations can implement to effectively manage the associated risks, thereby ensuring the security and integrity of OSS within the framework of their overall ISMS.

Control A.12.6.1 - Management of Technical Vulnerabilities: This control involves establishing and maintaining processes to manage security vulnerabilities. For open source and unsupported software, organizations should be particularly vigilant about identifying and mitigating vulnerabilities.

Control A.12.6.2 - Restrictions on Software Installation: This control focuses on ensuring that only authorized and approved software is installed on information systems. For open source and unsupported software, organizations should have clear policies and procedures to prevent the installation of such software without proper risk assessment and approval.

Control A.14.2.1 - Secure Development Policy: This control emphasizes the importance of having a secure development policy in place. Organizations should apply this control to the development of custom software, including open source components, to ensure that security best practices are followed, and vulnerabilities are minimized.

Control A.18.1.3 - Acceptable Use of Assets: This control helps ensure that open source software is used only for legitimate and authorized purposes, reducing the risk of unauthorized installations or usage.

OpenChain ISO/IEC 5230:2020

Based on the Linux Foundation’s OpenChain project, OpenChain ISO/IEC 5230:2020 is the international standard for open source license compliance. The standard was published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) in late 2020. It identifies key places to have license compliance processes, how to assign roles and responsibilities, how to ensure sustainability of the processes, and documentation. It also recommends the generation of SBOMs.

Organizations that meet the requirements of the standard can self-certify, or become certified via an accredited certification body after successfully completing an audit. You can review your compliance status by completing OpenChain's online questionnaire. 

OpenChain ISO/IEC DIS 18974

OpenChain ISO/IEC DIS 18974 Security Assurance Specification is an industry standard for open source security. It outlines and defines the essential requirements of a robust security assurance program concerning the use of open source software. It specifically focuses on the establishment of internal policies related to open source security, the periodic updating of security policies, and the use of various tools for software security testing.

You have the option to adopt OpenChain ISO/IEC DIS 18974 through self-certification at your convenience or by collaborating with a service provider for an independent assessment or third-party certification. Again, OpenChain makes it easy to check your compliance with an online questionnaire.

PCI DSS Requirement 6

Payment Card Industry Data Security Standard (PCI DSS) Requirement 6 pertains to the development and maintenance of secure systems and applications within an organization's environment. It outlines specific measures and practices that businesses handling credit card data must implement to ensure the security of their software and systems. For open source software, the requirements are the same, including identifying vulnerabilities, implementing security patches, and other security actions. 

PCI DSS Requirement 6 is divided into sub-requirements, including:

• Develop Secure Applications: Identify and address security vulnerabilities in the applications by conducting security assessments, such as code reviews, and application security testing for both proprietary and open source software.    
   
• Identify and Address Common Vulnerabilities: Identify and address common security vulnerabilities in both proprietary and open source software, such as those listed in the OWASP (Open Web Application Security Project) Top 10 and high-severity CVEs.

SOC 2 Common Criteria 7.1

Service Organization Control 2 (SOC 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). It assesses the security, availability, processing integrity, confidentiality, and privacy of a service provider's systems and processes. 

SOC 2 CC 7.1 requires that organizations use detection and monitoring procedures to recognize changes to configurations that result in the introduction of new vulnerabilities. All OSS most be monitored and scanned periodically to identify vulnerabilities or misconfigurations, and then remediated by applying the necessary updates or patches. Organizations also should put procedures in place to identify the introduction of unknown or unauthorized components.

NIST 800-53 and FedRAMP

NIST 800-53 is a comprehensive catalog of security controls and guidelines developed by the National Institute of Standards and Technology (NIST). It provides a wide range of security controls that organizations can use to protect their information systems and data. 

The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring of cloud service providers (CSPs). FedRAMP builds upon the security controls and requirements outlined in NIST 800-53.

Relevant controls for open source software in NIST 800-53 include:

• SA-12 (Supply Chain Protection): Requires organizations to safeguard against supply chain threats to the information system, its components, or information system services by employing safeguards, such as open source security scans and SBOMs.    
   
• SA-22 (Unsupported System Components): Mandates replacing information system and open source components when support is no longer available from the respective developer, open source community, vendor, or manufacturer. If the unsupported component is needed for a business-critical operation, the organization must provide justification and obtain documented approval for its continued use.    
   
• RA-5 (Vulnerability Management and Scanning): Involves scanning for vulnerabilities in software components that are not specifically defined by the organization, including open source software.

Sarbanes-Oxley Cybersecurity Compliance

The Sarbanes-Oxley Act (SOX) is a U.S. federal law designed to enhance corporate accountability and transparency. While the Act primarily focuses on financial reporting and accounting practices, it includes cybersecurity requirements relevant to open source software. SOX cybersecurity compliance generally refers to a public company implementing strong internal control processes over the IT infrastructure and applications that house the financial information, including all open source software used in financial systems.

SOX emphasizes the significance of having comprehensive policies and procedures concerning cybersecurity risks and incidents. Organizations subject to SOX should be mindful of the risks and compliance considerations related to open source software and maintain effective internal controls and ensure the integrity of financial reporting.

Final Thoughts

Don’t wait until you are facing an IT audit to learn whether or not your organization is compliant. Attaining internal and external open source compliance offers a multitude of advantages, including improved information security, optimized operations, and a reduction in incidents, resulting in a more security-conscious organization. Open source compliance also enables organizations to elevate their level of open source software maturity — which means greater stability, engagement, security, and support, thereby contributing to a more robust and trustworthy technology ecosystem. 

EOL Software In Your Stack?  
Stay Compliant with LTS from OpenLogic

If you need more time to perform a migration or upgrade, long-term support from OpenLogic can extend your runway while protecting your systems from CVEs. We offer extended LTS packages for CentOS, AngularJS, and Bootstrap. Talk to an expert today to get started.

Talk to an expert 

Additional Resources

• Webinar - Open Source Security and Compliance
• Blog - Debunking Open Source Security Myths
• Blog - Understanding CVEs and CVSS Scores
• Blog - What Is the Securing Open Source Software Act? 
• Blog - 10 Reasons Why Companies Choose OpenLogic for OSS Support
• Video - Risks of Ignoring EOL
• Video - Open Source Security