Skip to main content

Policy Concepts

We’re often asked by customers and employees why we built Lifecycle as a policy engine. Wouldn’t it be simpler to just scan for security violations? It would, but it would be less useful than a comprehensive risk management tool like Lifecycle.

Understanding which open source components you’re using, the risk from those components, and determining an acceptable level of risk for your organization is vital to building a reliable software development process. Sonatype Lifecycle makes risk management simple by allowing your organization to define and automatically enforce specific policies for open-source components. This approach is flexible enough to fit in any software development process, scalable, and empowers developers to make decisions about components.

In this guide, we’ll discuss why Lifecycle’s ability to automatically enforce policies in a context-sensitive way is an effective method of managing risk in any organization.

Establishing Risk Tolerance and Aligning Expectations

One key goal in DevSecOps transformations is getting security and development to communicate and set clear expectations. As part of these conversations, every organization needs to define its own risk tolerance and set rules for open-source components. Sonatype Lifecycle can notify users when a policy is violated, automating communication across an organization.

Another goal with DevSecOps workflows is to shift security left or move security concerns earlier into the development cycle. Automating policy enforcement tells developers early on if a component violates any constraints. This makes developers seek policy exceptions when a risky component is necessary. Security teams are also able to spend more time assessing and investigating exceptions instead of catching routine violations.

Picking Better Components

Choosing software components is a challenge. Software developers primarily select OSS components with functionality in mind, there are many components to choose from and the potential risks from a component are not obvious. The npm registry hosts over 1.3 million components and roughly 40% of those components contain some form of security vulnerability. And security vulnerabilities are only one kind of risk. Focusing solely on the potential security risks opens your business to other problems, like legal challenges or maintainability issues.

At Sonatype we break risk down into four major categories:

  • Security risks - Risk that your software can be exploited in ways that are harmful to the business or customers.

  • License risks - Legal risk from open source license obligations. An example is the GPL license which requires public disclosure of source code.

  • Quality risks - Risk from low-quality components. We use a variety of metrics to assess quality including age and popularity.

  • Other risks - This is a catch-all category for any other kind of risk, usually related to organizational priorities. One example is ownership of a component.

Keep in mind that risk factors have nothing to do with the function of the component, which is the main focus for developers. Assessing component risk requires an understanding of legal risks, cybersecurity risks, and a myriad of other factors. Developers should not be expected to be experts in all of these areas.

Getting subject matter experts to assess every component is also not viable. The 2021 State of Software Supply Chain report indicates that the average application contains more than 100 components—many of which are transitive dependencies. Transitive dependencies are brought into an application by other components, dramatically increasing both the number of components in an application and the potential for unacceptable risk. In order to effectively manage OSS components, Lifecycle lets the security, legal, and architecture experts develop a set of rules for how to handle different types of risk and enforce these rules automatically.

A Policy-Based Approach

On our website and our learning materials, we describe Sonatype Lifecycle as a “Policy Engine.” Let’s talk about what a policy is and how Lifecycle turns them into powerful tools.

Put simply, a policy is a rule for how to act when certain constraints are met. In Lifecycle, a policy tells Lifecycle what to do when an aspect of a component meets a specified condition. Some example conditions are the component’s age, CVSS score of a discovered vulnerability, or the obligations from the component’s license. Policies can be scoped into a set of application categories, allowing organizations to create policies for specific situations. This allows experts to set policies related to their area of expertise without worrying about interfering with another group’s priorities.

Sonatype Lifecycle can also be configured to take a few different actions when it detects a violation during a scan. It can warn the user, block/fail the build, or just record this information in a report. Each Lifecycle policy is also assigned a threat score. This allows teams to compare the relative risk of a violation even if they are in different domains, such as comparing the severity of a legal policy violation with a security violation. Individual policies are simple rules, but a large collection of simple rules create nuanced criteria for assessing and handling components.

By default, Lifecycle comes with a set of reference policies designed to meet most customers' governance requirements. The reference policies act as a base template for organizations and can be customized to meet your specific needs. These reference policies let teams begin managing components with Lifecycle before determining exactly how their specific organization wants to govern components.

Putting it in Context

Lifecycle enforces each policy differently based on the context of the application and violation. Policies can apply to entire companies, specific organizations or groups, or even individual applications. Each application can also be assigned a category that will influence the way Lifecycle evaluates the application. This allows applications and teams to tailor policies to their unique needs.

Additionally, different enforcement rules can apply at different stages of the software development process. This accounts for the individual needs of each team and project. Organizations can set looser restrictions early in their software development lifecycle (SDLC) to foster innovation and discovery while still protecting production applications at release time.

Lifecycle breaks the SDLC into the following stages for policy enforcement:

  • Proxy - Available with Sonatype Repository Firewall. The Proxy stage enforces policy when components enter your repository manager.

  • Develop - Snapshot builds for applications currently in development. This stage is primarily used in conjunction with our IDE tools.

  • Source - Scans the application source code from a Source Control Management (SCM) system such as GitHub.

  • Build - Typically used with build tools and CI Plugins for regularly compiled applications.

  • Stage release - Applications pending release, such as release candidates.

  • Release - Used when an Application is ready to be shipped to customers or deployed.

  • Operate - Integration with deployment tools or CLI scripts, as well as ongoing assessment for applications in production.

This context-sensitive approach lets organizations tailor Lifecycle to fit their unique software development process by enforcing policies where and when they want. Another benefit is that customers can incrementally adjust their policies to accept less risk as they become more familiar with Lifecycle, and the hygiene of their applications improves. At the beginning of a team’s integration with Lifecycle, existing applications can be given amnesty for policy violations, preventing a needless interruption in the workflow.

Scaling your business with Automated Enforcement

Automating enforcement simplifies decision-making in an organization and reduces complexity. Less time needs to be spent assessing the open source used in each application, allowing teams to focus on violations critical to the organization. This helps an organization grow. Another benefit is that developers are aware of the potential for violations when selecting components. This approach to automatic, targeted policy enforcement creates a comprehensive risk management approach that can fit any organization.

Lifecycle turns context-sensitive policy into a solution that can scale to any organization’s size by automating policy enforcement. The solution acts as the compliance officer and no individual needs to know every policy. The software will automatically scan applications throughout the development process and apply policy rules. Rather than hoping developers make good cybersecurity and legal decisions, developers are solely responsible for picking the best component for the needs of the project.

Automatic enforcement means a conversation or intervention is only required for policy exceptions. If a team needs a component that violates the set policies, they can request a waiver. This saves time and shifts risk management earlier in the development process by requiring teams to discuss components with policy violations earlier.

Conquering Risk with a Holistic Solution

Lifecycle manages risk by automatically enforcing many simple rules in a context-sensitive way. Developers are empowered to make decisions and are solely responsible for the function of a component. Security and legal risk are managed automatically, allowing teams to focus on cases when an exception is needed. This results in a flexible and scalable approach to governing open-source software components, letting companies spend more energy building their products.

License Policy Governance

This document provides information to represent open-source license governance concerns implemented through the IQ Server Reference Policy. The initial sections contain license terminology used throughout the Product. The additional questions are intended to be answered by an organization’s legal representation to establish the guidelines for policy creation and license review resolution.

License Terminology

Product

Sonatype IQ Server

OSS

Open Source Software

Application Composition Report

A report generated by the Product that organizes OSS components into License Threat Groups to conduct a license-related risk analysis of those components.

License Threat Group (LTG)

A group of OSS licenses is categorized based on the severity of risk associated with those licenses when analyzing OSS components.

Banned License - LTG

A license determined to be not allowed for use within the application.

Copyleft License - LTG

A license that makes an OSS component free to use but requires all modified and extended versions of the program to be provided for free as well and requires that anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it. The most well-known free software license that uses strong copyleft is the GNU General Public License

Non-Standard License - LTG

An OSS license that includes non-standard licensing terms, often unique to the OSS component. An example of a Non-Standard License is the “Beerware” license, which strongly encourages users of the software to buy the author a beer should they happen to meet in person.

Weak Copyleft License - LTG

A license that allows the software to link to the OSS components governed by it while permitting redistribution without the legal requirement that the linking software is distributed under the license; provided that any changes to the OSS components governed by the license become subject to the copyleft provisions thereof.

Weak Copyleft Licenses allow programs of any license to be compiled and linked against the OSS components governed by a Weak Copyleft License and then redistributed without any re-licensing required.

Liberal (Permissive) License - LTG

A class of licenses with minimal requirements about how the software can be redistributed, therefore making no guarantee that future generations of the software will remain free. Like Copyleft Licenses, Liberal Licenses offer freedom in terms of how the software can be used, studied, and privately modified but, unlike Copyleft Licenses, Liberal Licenses permit someone to distribute the software to restrict access to the modified source code.

POM File (Maven)

Project manifest information is stored in a pom.xml file used for configuring and building Maven projects using OSS. POM stands for Project Object Model.

Declared License

The license that the developer of the component has identified within the source code or on the OSS project website.

Observed License

The licenses that have been observed during Sonatype’s research.

Effective License

The effective license displays license information based on one of two scenarios. In cases where multiple licenses are found, including any that are observed, these will all be included as effective. If a license is selected, or overridden, then that license will be considered effective.

Multiple Licenses

Licenses derived from different license definitions across multiple files within the component packaging.

Dual Licenses

A situation where the component can be obtained under two different software licenses. Usually one of these licenses is an OSI-approved open-source license and the other is a proprietary license.

No Source

A license value signifies that a particular OSS component has no source code available for analysis, meaning that no license information can be derived from the source code.

No Source License

A license value signifying that there is no Observed License information available in the source code license headers.

Non-Standard License

A license that does not conform to common OSS licenses as cataloged by Sonatype’s data services will require further investigation to identify.

Not Declared

A license value signifying that a Declared License value was neither present in the POM file nor identified from the OSS project website.

Not Provided License

A temporary state during which license information is still contained in the Sonatype data pipeline but has not yet been made available.

Not Supported

Indicates Sonatype or the target ecosystem does not currently support automated license collection for this component format.

License Analysis

The Application Composition Reports provide a point-in-time analysis of the licenses governing open-source software components. Sonatype extracts licenses from files contained within the components' distribution packaging and source code.

License Obligations

OSS licenses are organized into License Threat Groups that identify potential risks based on the license obligations shown below.

License Obligations

Liberal

Weak Copyleft

Copyleft

Commercial

Non- standard

Banned

Permitted Commercial Use

x

x

x

Commercial Use Forbidden

x

Permitted Distribution

x

x

x

Permitted Modification

x

x

x

Modification Forbidden

x

Inclusion of Copyright

x

x

x

Inclusion of License

x

x

x

Inclusion of Notice

x

Existing Liability

x

x

x

Trademark Use

x

x

x

Required Disclosure of Source Code of Modified Components

x

x

Required Disclosure of all Source Code with Distribution

x

Source Code Must be Distributed Along with Web Publication

x

Banned, Commercial, Non-Standard, and Special licenses are not included due to the unique nature of their terms.

Sonatype Special Licenses

The License Threat Group, Sonatype Special Licenses, identifies OSS components that, based on Sonatype data, have license values of No Source, No Source License, Not Declared, and/or Not Provided License. These are components that may need additional remediation when evaluating the Application Composition Reports for the unknown risks they present.

License Risk Matrix

Application Types and Threats

Internal

Distributed

Hosted Internal Employee Access

Hosted External Consumer Access

Liberal

---

---

---

---

Modified Weak Copyleft

---

Low

---

---

Non-Standard

Low

Review

Low

Low

Copyleft

Low

High

Low

Low

No License

Low

High

Low

High

Similar Match

Low

Medium

Low

Medium

Unknown Component

---

High

---

High

Privileged

---

High

---

---

Declared Only

---

---

---

---

Observed Only

---

---

---

---

No License

---

High

---

High

Dual License

---

Review

---

---

License Policy Questions

When reviewing your license governance policy, we recommend documenting and sharing the answers to the following questions. This will set clear expectations for your development teams and preempt having to answer them every time they come up during the remediation process.

  1. Is additional review/approval required?

  2. Does one license take precedence over the other?

  3. Should the most restrictive license be chosen regardless of location?

  1. Is additional review/approval required?

  2. Does one license take precedence over the other?

  3. Should the most restrictive license be chosen regardless of location?

  1. Is additional review/approval required?

  2. Should the most restrictive license be chosen?

  1. (e.g. either CDDL-1.0 or GPL-2.0 with class-path exception)

  2. Is additional review/approval required?

  3. Should the most restrictive license be chosen?

  • If yes, may the component be distributed without additional review/approval?

  1. Acceptable distribution scenarios.

  2. Identifiable similar matches components that contain:

  • If not allowed for commercial use.

  1. List applications or proprietary components in your organization’s environment that will require special approval for access and/or use or separate tracking practices.

  2. Define what “distribution” means for applications that would trigger copyleft license provisions from open source.

  3. Is it acceptable to rely on the Declared License if there is no Observed License data?

    [Yes/No]

  4. Is it acceptable to rely on the Observed License if there is no Declared License data?

    [Yes/No]

  5. Define the process for when the Declared and Observed licenses DO NOT match.

  6. Define the process for when multiple Declared and/or Observed licenses DO NOT match.

  7. Define the process for when multiple Declared and/or Observed Licenses DO match.

  8. Process for consideration of dual-licensed components.

  9. May components without license information be used?

  10. May components identified as Similar Match be used?

    1. Additional code that is not known.

    2. Recompiled authentic code.

    3. Code fixes originate from within your organization.

  11. Define any additional license obligations that should be prohibited.

  12. Define current LTG licenses that should be redefined.