Policy Concepts

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.

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:

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. 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.

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, the 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 creates 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.

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 protecting production applications at release time.

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

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.

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.

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 risks 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.