Open source management and policy compliance demo

Does your organization rely heavily on open source software but struggle with a lack of visibility regarding package usage across the organization? 

Are your development teams downloading packages that have not been evaluated against organizational risk parameters, adding concerns about open source security risks? 

Watch this demo to learn how through Tidelift's software bill of materials (SBOMs) functionality, organizations can build a centralized inventory of all open source components being used across the organization. With our tooling, organizations are able to implement open source usage and management standards consistently, across all of their development teams, ensuring developers are only using approved open source components that follow secure software development practices.

TRANSCRIPT

Hello, my name is Larry Copeland and I'm a Solutions Architect here at Tidelift. Today I'm going to show you one of the ways you can upload an existing software bill of materials, or SBOM, into Tidelift, surfacing valuable package metadata for direct and transitive open source dependencies.

Tidelift provides the ability to upload package manifests and lockfiles for package managers such as NPM, but it can also work with popular CycloneDX and SPDX SBOM formats. This can be handy if you're already generating one of these formats as part of your software pipeline.

I'm going to go ahead and upload a CycloneDX SBOM using the Tidelift API.

I have my CycloneDX JSON SBOM and my working directory. In this example, I'm going to use curl, specifying the content type using the Tidelift API key as an environment variable, along with specifying my organization, the repository, and the branch. I navigate into the Tidelift web UI. Underneath the project for the SBOM which I uploaded, I can see that it's already been processed, and inventoried. In Tidelift, the project has a one-to-one relationship with either an application or repository. If I look at my software bill of materials, I can see that it's already providing information about the packages that are being used: the name, the versioning, the license, as well as whether or not the package is a direct or transitive dependency, and if the dependency scope is a development or runtime dependency.

One of the nice things about Tidelift's ability to parse existing manifests like CycloneDX is that I also have the ability to see the dependency graph in the form of dependency chains. Tidelift provides a way to ascertain where a package was brought into your supply chain by the package managers. This can be used to form a more tactical approach on how to mitigate potential issues that arise for a direct or transitive dependency that's in use by your application. 

Tidelift can parse existing software bills of materials, or SBOMs, such as those in CycloneDX or SPDX format. But we are also able to generate them based off of manifests and lockfiles for common package managers like RubyGems.

In this example, I'm going to show you how to set up repeatable SBOM generation using the Tidelift command line interface (CLI) and a continuous integration environment. Today, I'll be using Bitbucket Cloud Pipelines. I've already configured a sample Ruby repository, and added a Ruby Gem file along with the lockfile. I've also already configured the pipeline settings within the repository to be enabled and I've added the Tidelift API key as a sensitive variable. In order to start using Pipelines with the Tidelift CLI, I need to add a BitBucket Pipelines YAML file. I'll do this now. Most likely, you already have one of these files that holds your configuration if you're using the pipeline's feature. What I'm doing now is I'm adding a step, which includes downloading the Tidelift API, making the executable, and running a process that we call an alignment. This is Tidelift's language for using the manifest and lockfiles, creating a software bill of materials and streaming it into the Tidelift application. I'll save my settings now. I'm gonna commit my changes to my repository.

If I navigate back into BitBucket Pipelines, I should be able to see that the process has already kicked off. The pipeline runner is executing all the steps that had been defined in the YAML file, I can see that a successful Tidelift alignment has been performed. The output has provided me a revision number, which I can then correlate with other automation tooling.

I'm going to navigate over into the Tidelift application. I'm viewing the project that matches the repository of that is already configured in Pipelines. A project in Tidelift has a roughly one-to-one relationship with either an application or repository. you can see that the alignment has been created and inventoried and tied left. If I drill into the bill of materials, I can surface important metadata about the packages used, my application package names, their versions, the license being used, whether or not the package source is transitive or direct, or the scope is a development dependency or a runtime dependency.

Whether you upload existing SBOMs or generate them with Tidelift, one of the benefits is that Tidelift's catalog feature provides centralized visibility into which open source packages are used across your applications. I've added some applications to Tidelift's projects and my instance. This allows me to store and manage SBOMs for my applications. I'm also able to see which packages are being used, the version, the license, dependency chains--which are useful to help understand how a package was brought into your SBOMs, and I can filter on scope and source.

Because all the packages found in SBOMs are also added to my catalog automatically, I can gain a centralized view of all the open source and use of my organization. I'm going to navigate into my default catalog to view this list. In a catalog, I can filter by platform and search by package name. When I select a package, I can view package metadata, version guidance, as well as vulnerability information.

The vulnerabilities page displays CVEs, severity scores, which releases are affected,  and because releases are catalog centrally, it shows which of my projects are impacted. This visibility is useful when you're trying to ascertain how widespread the impact of a specific vulnerability is across your organization.

The package page also includes our quality checks, which highlight security and development practices that can be used to assess a package's enterprise readiness.

The project usage page will again let me know where the package is being used, which releases are in use, and whether the release is approved for use in my catalog based on the open source policy configured for the catalog.

I've just walked through how Tidelift provides a centralized inventory, creating visibility of all the open source being used. Now I'm going to talk about how to configure an open source policy in Tidelift. Again, at the catalog level, I'm going to navigate into my catalog standards page. Standards are where you can set the type of checks packages will be evaluated against in a catalog. Tidelift provides an evolving collection of standards that check packages in your catalog for security, licensing, and maintenance related issues. The default behavior of a standard is to automatically deny a package in the catalog if it violates one of the configured standards. This way I can set the policy I want to let the catalog decisioning be automatic.

For each of the standards, I can change the default behavior from deny to allow while still recording the violations for reporting purposes. Looking at the vulnerabilities configuration, I set critically severe CVEs to create a task. I'm going to see what critical violations are in my catalog and impacting my projects. On the task page, I can filter by standard scope, group and project. If I select the task to review, I can create a violation override, as well as review a recommendation for how to handle the violation. Recommendation information will be propagated to the project level. I'm also able to report on my catalogue wide open source usage, with reports designed for further visibility and action. All this information is available both in the Tidelift web UI and API.

This concludes my presentation. If you'd like to learn more about how Tidelift can help your organization, please schedule a demo at tidelift.com.