This proposal has been approved and the Eclipse Apoapsis project has been created.
Visit the project page for the latest information and development.

Eclipse Apoapsis

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Diversity and agility are high values in the Software community. Diversity and agility in Software Development processes and tools are a challenge for automation, though.

Accurate Software Composition Analysis is an important capability to keep transparency throughout the Software Lifecycle and is the base for the fulfillment of important non-functional requirements in the business context (e.g. Software Bill of Material SBOM-creation, Vulnerability Tracking, License compliance etc.). With the growing development speed and the need for CI/CD in combination with a growing number of regulations for devices with digital elements, scalable automated solutions are needed - especially in the modern automotive supply chains.

To handle automation with both aspects - accurate Software Composition Analysis and heterogeneous agile environments -  the Abstraction Layer for Software Composition Analysis (ALSCA) of the Eclipse Apoapsis Project plays an important role. Software Composition Analysis may look very different depending on the development context. An embedded Linux image requires different methods than a cloud service developed using package manager technologies. Nevertheless in any case there is the need to identify the components, for each component the respective source code and available metadata needs to be acquired and license obligations need to be analyzed. And on top of it, ideally the process is reproducibly documented for the audit trail. In a first step, the abstraction layer describes those steps and document the necessary interfaces between them on a generic level.  

The ORT-server provides a corresponding reference implementation for automating Software Composition Analysis for configurable setups at scale using available Open Source Tools. 

Scope

The Eclipse Apoapsis project provides a process and reference implementation for large-scale recursive dependency resolution and analysis, based on the OSS Review Toolkit software.

The "OSS Review Toolkit" is an open source tool hosted in the Linux Foundation that allows recursive dependency resolution, thus the ORT-server allows you to build your own recursive dependency resolution service based on it as a potential core of your Open Source Component Management process. 

The ORT-server is implemented in Kotlin and shall consist of a scalable backend providing an API and user/permission/role management, and software inventory management. 

A web frontend provides an Admin view and a Management view. For the authentication it shall integrate in existing solutions, but will not be part of the initial contribution. The project is open for proposals and contributions concerning the UI.

The guidance for the Open Source Component Management process consists of a generic architecture description, usage blueprints, a concept of the abstraction layer and a collection of use cases. It shall enable you to quickly match your organization's needs to the available solutions and jump start your process definition by providing templates.

Why Here?

As the Eclipse Foundation is also investigating to use the OSS Review Toolkit as base for the Open Source Management workflow and shares the challenge to run repository scans at scale, the Eclipse Apoapsis project's ORT-server may also be direclty adopted, provide important feedback to the project team for further improvements and help to establish a sustainable community.

Project Scheduling

Initial contribution expected until march 2024

Future Work

"Functionality":

- in the next twelve to eighteen months we plan to have a first stable version of the documentation (architecture, blueprints, use cases)

"Activities to grow the community":

- Presentation and discussion of the project in diverse events

- Alignment with the other communities ORT, OpenChain Automation Workgroup and all linked Open Source Tools, DoubleOpen, Aliens4Friends, OSADL, ...

Description

Eclipse Apoapsis consolidates the requirements from the tooling side (e.g. fast scan times, configuration as code,...) on the one hand and the requirements from the institutionalized operation side in medium to large organizations on the other hand (e.g. user access, role concept, organization specific structures, ...). Concerning concepts and wording it is based on the capability map created by the Open Chain Automation Workgroup in the context of Open Source Management (https://github.com/Open-Source-Compliance/Sharing-creates-value/tree/master/Tooling-Landscape/CapabilityMap). It is planned to incrementally work out the API-specification bottom-up starting from the reference implementation in the course of the project. Additionally it is intended to collect Blueprints (e.g. central pipeline, decentral SBOM generation with centralized metadata analysis, semi-automated analysis with central metadatabase, ...) and use cases (e.g. security vulnerability monitoring, identification of TOP100 used components in the organization, as a ... I want to... so that ...) that address generic problemspaces observed in the community , which can be used by interested parties to easily match their own problem space (birds of a feather) and map to a potential solution concept.

In an initial phase, the Eclipse Apoapsis project's ORT-server provides a concrete solution for a blueprint, where central Software Composition Analysis pipelines are used at scale while covering a large range of project setups (e.g. from Mobile Apps using Cocoapods to Cloud Services using Java/Maven) and configurable extent of analysis (e.g. from mere SBOM-creation to full-blast Dependency Analysis including Vulnerabilities and Copyright/License reports). To achieve this, the Eclipse Apoapsis project's ORT-server is based on the OSS Review Toolkit and makes use of its integration APIs for dependency analysis, license scanning, vulnerability databases, rule engine, and report generation. The Eclipse Apoapsis project itself concentrates on the server functionality including user and role management and the necessary APIs.

Necessary API harmonizations are indirectly worked-out in close collaboration with the original authors of the respective upstream-projects (e.g. ORT's technical steering committee).

The OpenChain Automation Workgroup developed a capability map in the context of Open Source Management (https://github.com/Open-Source-Compliance/Sharing-creates-value/tree/master/Tooling-Landscape/CapabilityMap). Within this Workgroup the OSS Review Toolkit provides a reference implementation for Open Source Management Automation and will be part of the first blueprint for the server setup.

It is planned to incrementally work out additional server-setups to support further blueprints in the course of the project.

 

Initial Contribution

Initial contribution will be

A) code-repository with the reference implementation of the ORT-Server

Third party dependencies:

- OSS Review Toolkit

- KeyCloak

- PostgreSQL

- Kubernetes

- Message Bus (e.g. Rabbit MQ or ActiveMQ)

- Log Aggregator (e.g. Loki)

 

B) repository with markdown-files describing the general concept, a first documentation increment including use cases, blueprints and providing the skeleton for working out the API-specification

Source Repository Type

BTW, I believe this should probably be listed as a related project to https://projects.eclipse.org/projects/technology.steady (and vice versa), as the vulnerability advisor of ORT could be extended to make use of it. This could also breathe some new life into Eclipse Steady development, which seems to have stalled a bit.