Table of contents
- Establishing Risk Tolerance and Aligning Expectations
- Picking Better Components
- A Policy Based Approach
- Putting it in Context
- Scaling your business with Automated Enforcement
- Conquering Risk with a Holistic Solution
- Additional Resources
We’re often asked by customers and employees alike why we built Nexus 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 are vital to building a reliable software development process. Nexus 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 we think Lifecycle’s ability to automatically enforce policies in a context-sensitive way is an effective method to 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. 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 risk - Legal risk from open source license obligations. An example is the GPL licence which requires public disclosure of source code.
- Quality risk - Risk from low quality components. We use a variety of metrics to assess quality including age and popularity.
- Other risk - 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 can’t possibly be expected to be experts in all of these areas.
Getting subject matter experts to assess every component is also not viable. The 2020 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 Nexus 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 in certain 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 to 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.
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 violations 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 Nexus Firewall. 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 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 (see Grandfathering capability) 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 that 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.