Skip to main content

Phase 2 - Reviewing and 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.

  • Set up reference

    This can be a shared doc, wiki, etc.— create a source that 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.

  • Decide on your application import strategy

  • Understand how to get the best scan results for your application

  • Select pilot applications

    This small group of applications should use languages and technology common in your organization and be run by high-performing teams.

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.

  • 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 application's risk. Often 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.

  • 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 that introduce license risk.