Create an open source security policy for your organization
Using open source software raises concerns about security and intellectual property. Here's how to make sound decisions and avoid situations you'll regret.
While open source software libraries help development teams quickly roll out new apps, you'll want to be aware of the risks they can introduce. Develop the right policy to reduce the effort required to fix vulnerabilities and to mitigate problems associated with data loss.
"Open source usage fundamentally means that you're incorporating someone else's code into your own product or service," said Tim Mackey, head of software supply chain risk strategy at Synopsys Software Integrity Group.
That code comes with rights and obligations in the form of an open source license, but there are also risks associated with how the software was created, tested and managed. Without a clearly defined policy, using an open source component raises intellectual property and cybersecurity concerns.
An open source policy clarifies uses, workflows and roles to streamline secure software development processes. Henrik Plate, security researcher at Endor Labs, a platform for securing open source software and the software supply chain, explained, "An open source security policy guides developers in regards to selecting, consuming, monitoring, updating and dismissing open source components throughout the software development lifecycle." It represents a structured and systematic approach to open source consumption across an organization, in contrast to ad-hoc and uncoordinated open source consumption by individual organization members. The policy should describe the requirements, rules and conditions regarding open source consumption to ensure various high-level objectives are met.
In addition, a policy provides a set of guiding principles that help organizations meet core business objectives. "It benefits an organization by aligning everyone around these guiding principles and the practices that help enable them," Plate said.
What to include in your open source security policy
An open source policy establishes a framework to help software consumers make decisions across the lifecycle of an open source component's usage. Plate recommends that the policy cover three phases of the open source lifecycle: selection, use and deprecation.
The selection phase needs to consider which types of software should be used. The use considerations should address the total cost of ownership for a software product, such as assessing the need for internal maintenance when a library lacks an active community that might otherwise carry these costs. Companies might also want to ensure that software has been published for at least 90 days before being used. It's also important to define when an open source component should be retired, such as when the community is not addressing known security vulnerabilities.
A good policy can also help manage risks as the use and scope of software change. Prashant Deo, head of security tools and engineering center of excellence within the cybersecurity practice at Tata Consultancy Services, said he often sees cases where at the time of development, the software was planned only for internal use, but then the company decides to commercialize the software to create new business models. This could have intellectual property and security ramifications, making it important to have a policy that regulates the use, modification and distribution of open source software.
Deo recommends that organizations address the following elements in an open source security policy:
- Roles and responsibilities of stakeholders, including IT, application development security, and risk and compliance.
- Continuous monitoring process for vulnerabilities for all open source components and their updates.
- Best practices for software management, including secure source code repository maintenance, secure check-in and check-out, change management and release management.
- Mechanism to track the asset during its entire lifecycle: acquisition, usage, distribution, storage, updates and retirement along with an updated software bill of materials (SBOM).
- Security testing process for open source components, including software composition analysis, for better visibility of potential security challenges across all components.
Prioritizing security and compliance effectively
It's also essential to incorporate controls that enforce policy on every open source component. Ilkka Turunen, field CTO at Sonatype, recommends teams generate an SBOM during the software development lifecycle to catalog which components are present. This SBOM can then be analyzed against the requirements of your policy to identify potentially sensitive use cases and other privacy risks.
Turunen said the top benefit of an open source security policy is that it gives organizations visibility and, thus, the ability to proactively make better choices about what open source is adopted. It also increases the quality of the application, which decreases the amount of technical debt that accrues over time due to an out-of-control maintenance burden of an unmanaged dependency adoption curve.
Teams need to proceed cautiously, however, to ensure they don't introduce new problems for developers or friction into the development process. "As with any cultural change, going from no policy to some policy can be a painful transition," Turunen said. For example, developers don't need a new process to generate countless security alerts when they turn on a new policy enforcement tool. Starting the project with the right intentions and transparent expectations is vital.
Ultimately, creating a policy is about formalizing the decisions individuals and the organization need to make when adopting open source. It's also essential to look for opportunities to automate the process so teams can focus on creating value rather than fixing new problems.
"The organizations that do this well don't spend hours a day on this, but rather build it in as a part of their everyday engineering process. The problem with security vulnerabilities isn't their presence, it's how fast you react to them. Most exploited vulnerabilities are several years old," Turunen said.
George Lawton is a journalist based in London. Over the last 30 years, he has written more than 3,000 stories about computers, communications, knowledge management, business, health and other areas that interest him.
