How security & license compliance cultures can coexist for open-source software management

Much about contemporary culture plays up clashes between opposites. Examples ranging from the innocuous (coffee vs tea) to the contentions political and social debates, each has a role in how we perceive others. Going to extremes becomes all too easy. Meeting in the middle has its advantages.

In the world of software, one such clash is around the cultures surrounding open-source software (OSS) use and development. There are possibly two cultures at play: one that is security-focused and another that makes license compliance more of a priority. But both security and license compliance play important roles in building and delivering quality software products while minimizing the risk and compliance issues that are inherent in OSS use.

The use of open-source continues to be on the rise. The benefits of leveraging this third-party software include lower-cost solutions, increased productivity, and faster time to market. As reported in the 2021 State of Open Source License Compliance, OSS and its vulnerabilities can introduce significant security, intellectual property (IP), or legal compliance risks, as well as tainted corporate reputations if not managed appropriately and efficiently at scale. 

Concurrently, development teams are being asked to create and update software faster than ever before. Analysts report that there is a marked increase of developers who are releasing applications monthly or more frequently—from 27 percent in 2018 to 41 percent in 2020. This trend is further bolstered by many organizations choosing to push their solutions to the cloud where release cycles are measured in minutes and hours, rather than the traditional months or quarters. With such scale and speed comes the need for examination and efficiencies.

More than one school of thought exists about how to manage open-source software. Fortunately, these approaches aren’t mutually exclusive. In fact, the best approach is to consider how all stakeholders can work with and support each other, delivering quality products, innovation, and customer success.

Is your organization primarily vulnerability-centric? Or compliance-centric?  

Organizations that have a vulnerability- or security-centric culture tend to look at open-source software as a security issue. This requires an ongoing process of patching and making sure that you’re on the latest version. The result: these organizations are always looking back—not forward—and are investing significant resources in the process. If a security culture is focused on stopping development, it can become unworkable—quickly. Instead, a security culture that’s also focused on the product and future successes can be more effective.

On the other hand, organizations that have a compliance-centric culture recognize that remediation is much more complex than meeting open-source obligations in the first place. These organizations tend to emphasize the need to manage and fix all compliance and IP risks. It’s an “If we find it, we must fix it” culture. This leads to some complexity in their processes, but with a forward-looking approach to mitigating issues and protecting the organization in the present and downstream.

One of the most effective ways to create a unified approach to managing open-source software is to bring developers into the process of making security decisions early in the process. Expanding left and getting buy-in from developers early—even at the design stages, during component selection—can help ensure that the right questions and considerations are being made early enough to deploy OSS effectively and securely. This helps manage security and compliance issues, alike while protecting IP. It can also help prevent frantic remediation efforts or even litigation.

Typically, IP compliance issues are more complex to remediate, as you cannot upgrade your way out of a licensing compliance issue. You either need to use an alternate component or perhaps reach out to the developer to negotiate an alternative licensing option.

 Best practices 

Security leaders can spearhead efforts to create a unified culture. Having all stakeholders on board with organizational efforts can identify open-source software and its vulnerabilities, streamline remediation issues, ensure compliance, and implement standard policies for both inbound and outbound OSS. Consider the following best practices: 

  • Train staff about open-source ethics: Most developers aren’t sure what’s expected of them when it comes to working with open-source. Generally speaking, their training doesn’t cover OSS ethics and license compliance. Proving education about best practices can reduce friction between engineering and compliance teams 
  • Understand where the industry is headed: Open Chain, the “International Standard for Open Source Compliance” provides commonly accepted standards for establishing open-source programs at organizations as well as general open-source use. Adhering to these can help streamline a range of business initiatives, including contracts, mergers & acquisitions (M&A), and underwriting. 
  • Incorporate Software Composition Analysis (SCA): Identify and record all of the open-source software components in a codebase through this automated process, which can reduce manual processes and their inefficiencies. SCA can reduce the time required for discovering compliance issues, providing developers with the information needed to identify and proactively remedy issues, and freeing up development teams to invest their time on the most challenging issues, rather than having to backtrack and fix issues that could have been identified automatically. SCA can be incorporated into multiple phases of the software development process depending on the organizations’ needs and procedures. 
  • Rely on an accurate Software Bill of Materials (SBOM):  An SBOM shows the makeup (including subcomponents and dependencies) of your software; it also showcases licenses and security vulnerabilities. A complete, accurate, up-to-date SBOM can inform governance and compliance initiatives while supporting effective responses to vulnerabilities. Organizations that are part of a software supply chain can utilize the SBOM as a compliance artifact that establishes trust between their own software suppliers and their end customers. 
  • Maintain a standard repository of vetted third-party components: Organizational approaches here vary widely. It’s a bit like the Wild West, right now, but getting organized can create great efficiencies. Do you have a repository? Only one? Or has company growth resulted in multiple repositories? Do you track which artifacts are used in which applications? Could you quickly identify exposures to newly reported security vulnerabilities across your organization? 

Automation of security is increasingly important, allowing teams to accomplish more with fewer resources, reserving the most focused efforts for those that need manual work. A united front, rather than a clashing culture, can help software suppliers safely rely on open-source software.

Alex Rybak, Director of Product Management, Revenera

Source link