How Security and License Compliance Cultures Can Coexist for Open Source Software Management



Much of contemporary culture stages clashes between opposites. From the trivial (coffee vs tea) to political and social debates, each has a role in how we perceive others. Going to extremes is becoming too easy. Getting together in the middle has its advantages.

In the software world, one such conflict relates to the cultures surrounding the use and development of open source software (OSS). There may be two cultures at play: one that is focused on security and one that makes license compliance a priority. But security and license compliance play an important role in the creation and delivery of quality software products while minimizing the risks and compliance issues inherent in the use of open source software.

The use of open source continues to increase. The benefits of leveraging this third-party software include lower cost solutions, increased productivity, and faster time to market. As noted in the 2021 Open Source Licensing Compliance Report, OSS and its vulnerabilities may introduce significant security, intellectual property (IP) or legal compliance risks, as well as tainted corporate reputations if they are not managed appropriately and effectively on a large scale.

At the same time, development teams are being asked to build and update software faster than ever. Analysts report that there is a marked increase in the number of developers releasing apps monthly or more frequently, from 27% in 2018 to 41% in 2020. This trend is further reinforced by many organizations choosing to push their solutions. to the cloud where release cycles are measured in minutes and hours, rather than traditional months or quarters. With such scale and speed comes the need for scrutiny and efficiency.

There is more than one school of thought on how to deal with open source software. Fortunately, these approaches are not mutually exclusive. In fact, the best approach is to consider how all stakeholders can work together and support each other, delivering quality products, innovation and customer success.

Is your organization primarily focused on vulnerability? Or focused on compliance?

Organizations with a culture of vulnerability or security tend to view open source software as a security issue. This requires an ongoing process of patching and verifying that you have the latest version. The result: These organizations always look back, not forward, and invest significant resources in the process. If a safety culture focuses on stopping development, it can become impractical, quickly. Instead, a safety culture that also focuses on the product and future successes can be more effective.

On the other hand, organizations with a culture of compliance 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 correct all compliance and IP risks. It’s a “If we find it, we have to fix it” culture. This leads to some complexity in their processes, but with a forward-looking approach to mitigate problems and protect 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 involve developers in the process of making security decisions early in the process. Left-expanding and early developer buy-in, even at the design stage, when selecting components, can help ensure that the right questions and considerations are asked early enough to deploy OSS efficiently and securely. This helps manage security and compliance issues, while protecting intellectual property. It can also help prevent frantic remedial efforts or even litigation.

Typically, IP compliance issues are more complex to resolve because you cannot get out of a license compliance issue. You must either use another component or contact the developer to negotiate an alternative licensing option.

Best practices

Security officials can spearhead efforts to create a unified culture. Involving all stakeholders in organizational efforts can identify open source software and its vulnerabilities, streamline resolution issues, ensure compliance, and implement standard policies for inbound and outbound OSSs. Consider the following best practices:

  • Train staff in open source ethics: Most developers don’t know exactly what is expected of them when it comes to working with open source. Generally speaking, their training does not cover free software ethics and license compliance. Demonstrate that best practice training can reduce friction between engineering and compliance teams
  • Understand where the industry is heading: Open Chain, the “international standard for open source compliance” provides commonly accepted standards for the establishment of open source programs in organizations as well as the general use of open source . Adhering to these can help streamline a range of business initiatives, including contracts, mergers and acquisitions (M&A) and underwriting.
  • Embed Software Composition Analysis (SCA): Identify and register all open source software components in a code base through this automated process, which can reduce manual processes and their inefficiencies. SCA can reduce the time it takes to uncover compliance issues, provide developers with the information they need to proactively identify and resolve issues, and free up development teams to invest their time on the most difficult issues, rather than having to go back and fix any issues that might have been identified automatically. SCA can be integrated into several phases of the software development process depending on the needs and procedures of the organization.
  • Trust a precise software nomenclature (SBOM): an SBOM shows the composition (including subcomponents and dependencies) of your software; it also presents licenses and security vulnerabilities. A complete, accurate and 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 use SBOM as a compliance artifact that builds trust between their own software vendors and end customers.
  • Maintain a standard repository of approved 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 the growth of the company resulted in multiple repositories? Do you track which artifacts are used in which applications? Could you quickly identify exposures to newly reported security vulnerabilities in your organization?

Security automation is increasingly important, allowing teams to accomplish more with fewer resources, reserving the most focused efforts for those who need manual labor. A united front, rather than a culture of conflict, can help software vendors safely rely on open source software.

Alex Rybak, Director of Product Management, Will come back



Comments are closed.