Getting Started

Welcome to Sonatype Lifecycle! This page gives you an overview of your journey to install, configure, and use Lifecycle. These getting started pages are checklists along your DevSecOps journey. 

Adding Lifecycle into your development pipelines is part of your DevSecOps transformation where you will empower your developers to manage risk from open source earlier in the development process. 

Adopting Sonatype Lifecycle has three parts:

  • integrating Sonatype Lifecycle in your software development lifecycle (SDLC)
  • setting meaningful expectations while prioritizing the discovered risk
  • empowering developers to remediate violations while protecting them against new risk

Depending on the complexity of your SDLC, expect the process to take the first few weeks to deploy Lifecycle by integrating scanning into the build pipeline.  You should then make an effort to socialize expectations to your development teams.  Consider starting with a pilot team with a few priority applications to work through challenges before attempting a larger rollout.

In the lists below, we will overview the steps and goals to get started with Sonatype Lifecycle. 

Note that some items in these lists have multiple options to achieve the same outcome. 

Each section assumes you've completed the previous sections. 

Lifecycle UI Tour

For local demos see our Quickstart Guides section. 

Phase 1: Installation & Configuration

Prepare for Product Adoption

Like any DevSecOps transformations, getting value requires you to set clear expectations and get buy-in from all stakeholders participating in the process. Project champions who design, articulate, and follow a rollout plan are more successful. This plan should identify milestones, timeframes, and all responsible stakeholders. 

Key Action Items

See Preparing for Lifecycle page for full checklist.

Installation

This section outlines the steps for your initial Sonatype Lifecycle installation in a production environment. For local demos, check out our Quick Start. 

Key Action Items

  • Provision your hardware - Defining the necessary infrastructure to run Sonatype Lifecycle.
  • Run the Service  - Start Sonatype Lifecycle software.
  • Initialize Lifecycle - Add your license and connection to external resources

Architecture Diagrams

 

For High Availability Diagrams see our High Availability Documentation.

See the Installation Checklist page for full checklist.

System Configuration

The next step is to configure global settings in Lifecycle and set up system maintenance tasks. 

Key Action Items 

  • Set up Notifications - Configure email notifications, Jira integrations, and other tools to notify you about new policy violations.
  • Configure User Access - Set up single sign-on and/or LDAP for user access.
  • Schedule System Maintenance - Establish backup, restore, clean-up, and upgrade plan.

See Configuration Checklist page for full checklist.

Application & Policy Configuration

This section instructs you on how to modify the Sonatype Reference Policy set to meet your organization's risk standards. It's likely that different applications and teams will have different acceptable levels for risk. 

Key Action Items

  • Catalog your applications - Map out the applications you want to scan with Sonatype Lifecycle.
  • Define appropriate Categories - Group your applications into categories based on acceptable risk levels and user access.
  • Adjust your policies - Change the policies for your lifecycle Organizations for that groups acceptable level of risk. 
  • Set up proprietary components - Sonatype won't have information on components developed by your teams. This lets you tell Lifecycle which components you've developed to remove noise from your scan results.  
  • Ensure that your license threat groups are appropriate - Adjust your License threat groups to suit your organizations legal standards. Note: this will need to be done in conjunction with your legal team.  
  • Enhance your policies using labels - Set up labels to help identify, track and remediate components causing policy violations.
  • Test scan in sandbox organization/application - Scan an application in your Sandbox Organization to ensure the software is set up correctly.
  • Legacy application policy waivers - Decide on a strategy for dealing with the policy violations already present in your application. 

Phase 2: Reviewing & Assessing Risk

The second part of getting started with Sonatype Lifecycle is to onboard your applications and understand your open source risk. While you assess your open source risk, you should create a process for addressing risk. Many steps in this part will require a joint decision from product development, application security, and your legal teams. 

Key Action Items

  • Set up reference wiki - This wiki will be your reference for future applications, teams, and developers. It allows you to document and communicate your decisions. 
  • Select Pilot Applications - Select applications to create a repeatable onboarding process. We recommend picking applications from high-performing teams that use languages common in your organization.

Application Onboarding

There are several strategies for bringing your applications into Lifecycle. Each method for importing an application corresponds with a different part of the Software Development Lifecycle. The two main methods of onboarding applications are through your source control management (SCM) system and integrating an application with your continuous integration system. The ultimate goal should be to integrate with your CI/CD pipeline, as this lets you use Lifecycle's automation features. 

Key Action Items

Scanning Applications

This step is where you'll finally begin onboarding your applications. Here you'll set up your pilot applications with Lifecycle and define a process for the rest of your organization to follow. 

Key Action Items

  • Select applications - Identify groups to run a Sonatype Lifecycle Pilot project. These applications should use languages and frameworks common in your organization.
  • Import applications through SCM for initial Scan - Importing an application through SCM gives you immediate insight into the applications risk. Often times the scan is less precise than a scan of the final built application. 
  • Add Lifecycle to the applications' CI/CD Pipeline - Scanning as part of your build process should give you the best results and more tools to automate risk management. 
  • Create Build Templates - Create templates for modifying each application's build process to use Lifecycle. These can be reused for the rest of your applications.
  • Test your templates - Use the templates as you onboard the rest of your pilot applications. This will let you refine and troubleshoot this process before onboarding all your applications.
  • Add templates and onboarding process to your Wiki - Document the tools and processes you've established. 

Assessing Component Risk

As you import the rest of your applications you can Identify the most important violations to remediate. Lifecycle aids in this with policy threat levels. 

Key Action Items

  • Continue onboarding applications - Onboard the rest of your applications. This can be one of the most time intensive steps. 
  • Identify Targets for Remediation - Identify which applications should be addressed first. 
  • Define Service Level Obligations for Remediation - Work with development, application security, and legal to set timelines for development teams to address violations of different severity.  
  • Enable Notifications - Turning on notifications for new policy violations. 
  • Create a Lifecycle Remediation Plan - This is the way your development teams will use Lifecycle to find and address open source risk. 
  • Establish License Violation Workflow - You may need a separate workflow to address components which introduce license risk. 

Phase 3: Removing Risk

Remediating Component Risk

Once your risk has been prioritized, it's time to begin fixing it. The typical strategy for this is to upgrade to versions with less risk whenever possible, then waive non-applicable vulnerabilities, replace components that are vulnerable and cannot be upgraded, and finally accept any necessary risk. 

Key Action Items

  • Upgrade Components - This is the easiest and quickest way to remove policy violations. 
  • Determine if remaining vulnerabilities are exploitable - Often times, vulnerable components can be used in secure ways. If a violation doesn't apply to your application you can accept that risk and review that component regularly until a safer version is released. 
  • Apply time-bound waivers  - Apply time-bound waivers to components with non-exploitable vulnerabilities. 
  • Replace exploitable components no safe upgrade path - If a component is vulnerable and is exploitable, it may need to be substituted with a similar one with less risk. 
  • Accept necessary risk - Apply time-bound policy waivers to violations that cannot be remediated. 

Preventing Risk

Sonatype Lifecycle's automated policy enforcement tools let you keep components with the greatest risk from ever entering production. They're powerful and potentially disruptive. By this point your teams should be adept at remediating policy violations, and you are ready to begin automatically enforcing your policy standards. Policy enforcement can be done at the organization and application level. This enforcement should be introduced gradually. 

Key Action Items

  • Review Enforcement Best Practices
  • Establish criteria for enabling enforcement - Decide when you'll begin enforcing policy violations by breaking builds. 
  • Determine feedback channels - Enabling enforcement can be challenging. Having a way to solicit and respond to feedback will help you successfully turn on policy enforcement. 
  • Set expectations - Be clear about what violations will be blocked and when. Also remind all teams of SLOs and other expectations. 
  • Enable Enforcement for critical violations - Prevent components with known risk from entering production. 
  • Gradually enable enforcement for other policies - Over time enforce more policies to lower the acceptable risk level in your applications.  

Shifting Left

So where do we go from here? With enforcement enabled, it's time to begin making good component decisions and proactive choices earlier in your development process. This is called shifting left. 

Key Action Items

  • Make Intentional Upgrade Decisions
  • Empower Developers to pick better components
  • Configure IDE Plugins
  • Configure Chrome Plugin
  • Leverage Data Insights
  • Use BOM Doctor