SBOM and dependency management

This repository contains the documentation and tools for the SBOM and dependency management process.

Contents:

• Work plan
• Affected repositories

Work plan

Objective 1: Inventory of EOL distributions

1. Implement a GitHub Action for NS8, based on a common action to generate and upload the SBOM. Chosen engine to generate the SBOM: Syft The action must upload the SBOM:

   • in the repository release as an attachment in JSON and SARIF format
   • in the repository dependency graph

   Use syft to generate the SBOM. Allow targeting both directories (for NethSecurity and UIs) or a container image.

   Create 2 separate actions: one for generating the SBOM, and one for uploading and analyzing.

2. Implement a scraper as a GitHub Action that reads EOL information from an SBOM. For each EOL distribution, create an issue with the information. For each non-EOL distribution, create an issue reporting the end-of-support date using the Endoflife API. Evaluate integrating the issues within a project.

Objective 2: Rationalization of dependencies

Use Renovate for dependency management, while Dependabot only for alerts (without automatic pull requests). To do:

1. Configure Dependabot in a homogeneous way for all repositories
2. Create a configuration file for Renovate that can be inherited by all NS8 repositories Default behavior:
   • if there are no tests, automatically merge patch versions, no automatic merge for minor and major versions
   • if there are tests, automatically merge all versions (to be implemented as an override on individual projects)
3. Create a common configuration file for Renovate for all non-NS8 projects, such as UIs

To be done by: March 14

Objective 3: Integration with the development cycle

Define internal governance for EOL and dependencies, balancing political and technical aspects. The governance must be able to:

1. Coordinate work, allocating time for managing vulnerabilities and EOL
2. Provide guidelines on choices to be made in case of EOL or vulnerabilities
3. Decide on timing and methods of communication about vulnerabilities and updates
4. Define guidelines for choosing distributions when creating a container

Objective 4: Security tools

Create a tool that analyzes CVEs of the base distribution of NS8 and NethSecurity. This tool should also be available to the community.

In the case of NS8, the tool must analyze the installed images. In the case of NethSecurity, the tool must analyze the installed packages.

This work can begin after completing objectives 1 and 2.

Objective 5: Portal for consulting information

Create a portal, or use an existing portal, for consulting security and EOL information. With the portal, it should be possible to respond to support requests such as:

• Is product x in EOL?
• Is product x vulnerable to CVE y?

Possible candidates:

• Sbomify
• dependency track

Affected repositories

NS8

Main repositories:

• Core
• Samba
• Traefik
• Mail
• WebTop
• eJabberd
• IMAPSync
• CrowdSec
• NethSecurity Controller
• LDAP Proxy
• User Manager
• Loki
• Nextcloud
• Mattermost
• Netdata
• Dnsmasq
• Piler
• OpenLDAP

Main repositories, not container-based:

• UI Library
• Images

Low priority applications:

• Prometheus
• Webserver
• PostgreSQL
• MariaDB
• Roundcube Mail
• Node Exporter
• Grafana

Applications with very low priority:

• SOGo
• WordPress
• DokuWiki
• Collabora
• Passbolt
• MinIO
• Kickstart
• Porthos

NethVoice

Container-based:

• NethVoice proxy
• NethVoice

Not container-based:

• NethCTI Server
• NethVoice CTI
• NethVoice Report
• Phone Island
• Tancredi
• Contatta
• AstProxy
• Falconieri

NethSecurity

Not container-based:

• Core
• Controller
• UI
• Library

Extra services, not container-based:

• Parceler
• Icaro

Other projects

• Windmill
• Legacy Backupd (private)
• Yomi Proxy (private)