Source Control Integration Best Practices

Many Source Control Management (SCM) Systems set rate limits on requests per user. Connecting each access token to 500 applications or fewer ensures that Lifecycle can connect to your SCM system to provide you with scan results and source control feedback.

Sonatype Lifecycle includes JGit, a Java implementation of Git, in its application files. The native version of Git allows Lifecycle to take advantage of the Shallow Clone and Sparse Checkout features. These improve performance by only downloading relevant files for Source Control Scans. This is especially noticeable during Easy SCM Onboarding.

Easy SCM Onboarding is a quick way to create and organize Lifecycle Applications from your SCM system. Creating applications with this tool gives you an Instant Risk Profile and a Continuous Risk Profile with no additional configuration. This is a good way to get basic insights into your open-source risk while getting started with Sonatype Lifecycle.

Applications created through Easy SCM Onboarding can provide feedback in your source control system with status checks, Pull Request (PR) comments, and automated pull requests. PR Comments and Automated PRs can be enabled or disabled in the SCM configuration. This allows you to make informed choices right away.

The Instant Risk Profile is a tool for establishing a baseline level of risk. The scan results from a Source Control System are often inferior to a full application scan. The Instant Risk Profile is a great way to get immediate results and help you identify risk in critical applications while integrating Lifecycle into your Build Pipeline, but it is not a substitution for an application scan that includes all the build artifacts.

Source Control Integration with Sonatype Lifecycle is most effective as a complement to full application scans. Adding Lifecycle to critical application's build pipelines can give you more precise scan results and give you tools to prevent critical vulnerabilities from entering production. You will still receive Pull Request feedback. The build scans will be used in place of the default branch scans when assessing new pull requests.

Pull Request feedback should be used to give developers early warning about new policy violations. Sonatype LIfecycle will only indicate new violations in Pull Requests. When possible it will target the specific line of code introducing the policy violation. This gives development teams a warning right where they work. Addressing policy violations before they enter the default branch for the application can reduce technical debt and keep applications secure.

Using Lifecycle's SCM feature to prevent merges will frustrate developers because they're typically not ready to take remediation actions or ask for a waiver at that point in development. As a general rule, we recommend warning about violations early and breaking builds as late as possible.