Software Supply Chain

5C — Continuous Code Compliance Control Center

Modern software products routinely include over 10,000 packages. Smaller teams often do not have the bandwidth to evaluate everything for cybersecurity and CRA compliance, and do not have the budget or resources for proprietary tools or complicated processes. Continuous Code Compliance Control Center (5C) is a new DejaCode and AboutCode app that will provide an accessible overview dashboard, necessary for teams to focus on critical cybersecurity and compliance issues, and track security and compliance at scale with less effort. 5C will continuously monitor and aggregate events, from AboutCode tools and other FOSS tools integrated in AboutCode, to provide a visual compliance observability.

The goals are to provide key features such as: actionable insights, shareable across stakeholders, drill-down from summary to investigate issue details and on-demand workflows for teams to resolve issues. 5C will facilitate proactive risk management with aggregated data and "Key Compliance Indicators", using a set of predefined and customizable rules for policies and thresholds to trigger alerting and reporting noncompliance and cybersecurity issues as events when needed. 5C plans to deliver the top layer for a FOSS solution to simplify meeting complex regulatory requirements and cybersecurity technical data management for effective and efficient automated compliance operations, across engineering, security, legal, and business teams.

Read more about 5C, Code Genetics, PurlValidator, FOSS Code Supply Chain Assurance II.

FOSS Code Supply Chain Assurance — Mitigate attacks through software dependencies

It is of the utmost importance to ensure that FOSS packages from public repositories have not been tampered with by malicious actors. This type of compromise is described as an open source "supply chain attack" and these have been increasing significantly. This project is building a new system (which is FOSS itself) to help verify the integrity of deployed code packages and validate their origin with external data sources, with the potential to mitigate attacks on open source packages supply chains such as: detecting if a package in use is matching verified code by matching source and binaries exactly and approximately. Or detecting abnormal code changes that may be signs of malicious modifications and possible attacks on a package.

The key components of this open code and data solution are a Package and File Fingerprints Database, a Code Similarity and Changes Detection Engine, utilities to detect possibly malicious changes in upstream projects, and integration in build system(s). While existing approaches may require a tight control of the whole code supply chain, the approach of this project is designed for practical usage with limited changes to a build and CI/CD pipeline.

Read more about FOSS Code Supply Chain Assurance.

Free Software Vulnerability Database — A resource to aggregate software updates

"Using Components with Known Vulnerabilities" is one of the OWASP Top 10 Most Critical Web Application Security Risks. Identifying such vulnerable components is currently hindered by data structure and tools that are (1) designed primarily for commercial/proprietary software components and (2) too dependent on the National Vulnerability Database (from US Dept. of Commerce). With the explosion of Free and Open Source Software (FOSS) usage over the last decade we need a new approach in order to efficiently identify security vulnerabilities in FOSS components that are the basis of every modern software system and applications. And that approach should be based on open data and FOSS tools. The goal of this project is create new FOSS tools to aggregate software component vulnerability data from multiple sources, organize that data with a new standard package identifier (Package URL or PURL) and automate the search for FOSS component security vulnerabilities. The expected benefits are to contribute to the improved security of software applications with open tools and data available freely to everyone and to lessen the dependence on a single foreign governmental data source or a few foreign commercial data providers.

Read more about Free Software Vulnerability Database, Enhance the vulnerability database.

T-Rust - In Rust we Trust — Scan, review, curate and fix metadata of Rust crates

crates.io hosts over 160 thousand Rust packages that have been downloaded over 90 billion times. The origin metadata and licensing documentation for Rust crates is declared by the authors as part of the metadata, but can be misleading or incorrect. Accurate origin and license metadata for Rust crates is essential to safely automate the friction-free consumption of Rust packages in the software supply chain of safety-critical applications.

T-Rust intends to fix this problem in multiple steps: it will scan, review, curate and fix the metadata of the most popular crates. This data will be released as open data, working with the Rust community to provide the data as part of the crates.io API, cross-check and report code borrowing and reuse between crates. Subsequently an AboutCode toolchain will be deployed as a service for all crates authors to review, validate and enrich metadata. The outcome should be be that crates.io packages are shared with better, more accurate origin and license metadata at creation time. And that the increased level of trust in Rust crates will make it easier to consume more Rust packages safely.

Read more about T-Rust - In Rust we Trust, Rust crate auditing and source correspondence checks.

UEFI Capsule Update for coreboot with EDK II — Implement more robust firmware updates in coreboot

UEFI capsule update is an industry-standard approach widely supported by hardware vendors, providing a secure method for delivering firmware updates. By adopting capsule update methods, the project aims to simplify the update process and enhance the user experience, providing a more reliable approach compared to complex flashrom-based updates, which are still common in the open-source firmware distributions based on coreboot. Due to security measures, OS-level access to firmware is intentionally restricted, which in turn makes it increasingly challenging to apply firmware updates from the operating system. This limitation poses difficulties in utilizing traditional flashrom-based methods for firmware updates. The expected outcomes of the project include enhanced firmware update capabilities, a simplified user experience, heightened security, and enhanced compatibility, all achieved by seamlessly integrating with fwupd, a popular firmware update management tool for Linux systems.

Read more about UEFI Capsule Update for coreboot with EDK II.

Automated clearing of source code files — More efficient retrieval of security and license compliance contextual information

A common task for companies is to clear software source code files for legal or security reasons before they can be used by the software developers. The clearing process is tool driven, using tools such as code clone detectors/snippet matchers, license scanners and security scanners. Typically the clearning process starts from 0 for each new file that is analyzed and the fact that open source software is changed incrementally most of the time, and the software being scanned will likely be nearly identical to previously seen software, is not used. For a (large) subset of files it is possible to use this characteristic to (semi-)automate this process. When scanning a new file, first find a closest file in a set of known files, compute the difference to the known file, checking where the difference in the file is and use rules to determine what action to take depending on where the difference in the file is.

When scanning source code people are typically looking at the file as a whole as an individual unit but never at the lifecycle of the file: how much was changed and where was it changed. For license compliance it makes no sense to rescan files if the header where the license text is found has not been changed and earlier conclusions can be copied. For security it doesn't matter if only comments are changed but no code. This project tries to tackle this by finding out a little bit more about finding a closest match to the code (is there already a file that is close enough), determine the structure of the file (what is comments, what is code) and then comparing the two files to see where changes were made. Depending on the scenario (license compliance or security) different actions can subsequently be taken by the user.

Read more about Automated clearing of source code files.

Build Transparency (Trustix) — Towards a decentralized supply chain for software

When we install a program, we usually trust downloaded software binaries. But how do we know that we aren't installing something malicious? Typically, we have confidence in those binaries because we get them from a trusted provider. But if the provider itself is compromised, the binaries can be anything. This makes individual providers a single point of failure in a software supply chain. Trustix is a tool that compares build outputs across a group of providers - it decentralized trust. Multiple providers independently build the software, each in their own isolated environment, and then can vouch for the content of binaries that are the outcome of reproducible builds - while non-reproducible builds can be automatically detected. This is the first step towards an entirely decentralized software supply chain that can securely distribute software without any central corruptible entity.

Read more about Build Transparency (Trustix).

C/C++ Package Registry — Common registry for software written in C/C++

Much of the internet and many devices run on C/C++ code. There are many build and packaging systems for C/C++, but without a common registry, it is difficult to discover, catalog, and identify C/C++ packages used in products, devices, and apps.

The C/C++ Package Registry resolves this by creating an open and distributed registry of C/C++ packages keyed by Package-URL (PURL), with associated metadata, but neutral towards any build system. It will also maintain open source tools to discover and detect C/C++ code commonly vendored and patched in software codebases. This will be combined with a database of known security vulnerabilities that affect these C/C++ packages, also keyed by PURL.

This enables C/C++ software teams to more efficiently and reliably manage and automate their C/C++ software supply chain and vulnerability management operations. Using open data and open source code, the C/C++ Package Registry strengthens security postures and helps teams meet regulatory compliance requirements. Our goal is to develop the foundational data formats, build the core infrastructure for collecting and indexing C/C++ packages, and create comprehensive documentation that will nurture and sustain a thriving community around this initiative.

Read more about C/C++ Package Registry.

CRAVEX 2 Code Reachability — Do vulnerable dependencies actually impacts security or not?

CRAVEX makes it easier for any organization to efficiently comply with the emerging CRA. CRAVEX collects, tracks, and triages FOSS package vulnerabilities, determines their exploitability in a portfolio of software products and projects, and provides reporting with SBOMs and VEX statements to share with stakeholders.

CRAVEX 2 enables CRAVEX users to triage vulnerabilities faster and more efficiently with automation and more accurate vulnerability data. An integrated, rule-based system automatically filters or reranks the vulnerabilities in the context of the managed application, system or device. This will integrate the emerging SSVC scoring for decision trees-driven automation. Vulnerable code "reachability" determines if the code impacted by a CVE is present, used, and exploitable. It will integrate and extend the features of NGI0-funded and FOSS projects, such as BANG.

With increased automation and more accurate data, CRAVEX 2 further facilitates CRAVEX users' ability to efficiently manage vulnerabilities towards CRA compliance.

Read more about CRAVEX 2 Code Reachability.

CRAVEX integration — Integrated vulnerability exploitability management

CRAVEX makes it easier for any organization to efficiently comply with the emerging CRA. The solution is based on the AboutCode stack of open source tools, but no solution is an island.

This project integrates CRAVEX with other tools to better orchestrate software supply chain and compliance automation, including: packaging for Linux distributions to maximize the ease of deployment, business systems to create tailored SBOMs and VEX, other FOSS SCA tools to accommodate different software stacks, CI/CD pipelines with scripts and workflows to improve usability, and container cluster analysis to allow users to point to a Kubernetes cluster to collect and scan all the images, and then detect vulnerabilities.

The CRAVEX Integration project orchestrates the different tools critical for practical and efficient software supply chain management and compliance automation processes.

Read more about CRAVEX integration.

DeviceCode — Structured technical information about consumer devices

This project is about reusing crowdsourced technical data about devices. This data is useful for researchers and tinkerers, but it is typically not the data that vendors are willing to give, let alone under a license that allows reuse. Think of: chipset information, serial port layout & speeds, amount of memory, and so on. Several groups of people have collected this data in several places (mostly wikis) under an open data license, but they are hard to reuse by other projects that could be interested in this data. The goal of "DeviceCode" is to collect this information, rework it into a format that is easy to reuse by other projects without having to resort to Wiki scraping, and also clean up the data (as humans make data entry mistakes and put useful data in places where it shouldn't be), cross-correlate different sources and automatically enrich the data where possible.

Read more about DeviceCode.

Maven Heaven — Scan, review, curate and fix metadata of Java packages

The Apache Maven Central repository is the center of the Java development world, where all open source dependencies are fetched from, hosting over 3 million Java packages. Java JAR origin metadata and licensing documentation is declared by the authors as part of a POM metadata, but this can be misleading or incorrect. There are also thousands of copies of Java packages, such as Log4J embedded (or shaded) in other JARs, and these go undetected by most tools. Accurate Java origin and license metadata is essential to safely automate the consumption of Java packages in the software supply chain.

Maven Heaven fixes this problem in multiple steps: it will scan, review, curate and fix the metadata of the most popular Java packages. The data will be released under an open license, and the project will work with the Maven community to provide it as part of the Maven services and repo, allowing to cross-check and report code borrowing and reuse between Java projects. The team will deploy an AboutCode toolchain as a service for all Java authors to review, validate and enrich metadata.

This project is a collaboration between AboutCode and Log4J maintainers to help uncover issues, and help upstream authors fix these issues. It should allow Maven packages to be shared with better, more accurate origin and license metadata, possibly right at creation time. The increased level of trust in Maven Java JARS will make it easier to consume more Java packages safely.

Read more about Maven Heaven.

Nixpkgs Clarity — State of the art automated license detection for Nixpkgs

Nix provides a unique approach to package management and system configuration for more reproducible, declarative, and reliable systems. Nixpkgs is the largest and most up-to-date collection of software packages today, and forms the basis of the NGI Fediversity project. But like other ecosystems, Nix struggles with accurate and consistent license package metadata necessary for frictionless reuse of Nixpkgs in the software supply chain.

For example, Nix's license tracking does not fully align with best practices like SPDX license expressions, using instead a custom list of license IDs, inconsistently referencing SPDX or ScanCode LicenseDB, that can be out of sync with the actual code, or misrepresenting its license. Packagers commonly only look at top declared licenses, ignoring the file-level licenses. The Nixpkgs Clarity project corrects and standardizes Nixpkgs's license metadata to enable efficient, responsible Nixpkgs usage in secured software supply chains.

Read more about Nixpkgs Clarity.

Tracing and rebuilding packages — Improved metadata/provenance for build artifacts

For many end users the smallest unit of software is the "package": a collection of programs and configuration files bundled in a single file, typically shipped as a single archive. Examples are "util-linux", "glibc", "bash", "ffmpeg" and so on.

Open source distributions install packages using their package management systems. The package management system writes the contents of a package to disk when the package is installed or updated and removes the contents if the package is removed. The packages themselves contain metadata maintained by the distribution maintainers. This information includes the name of the package, project URL, description, dependency information and license information, etc.

This granularity can be too coarse. For example, the license information is aggregated at the package level. If there are separate files that are under different licenses, then this will not always be clear from the license information at the package level.

This project will make it more easy to understand by looking at what goes into each individual binary in a package, and assign metadata to the individual binaries instead of to a package. It will do so by tracing the build of a package and recording which files are actually used. By building packages in a minimal (container) environment, capturing the build trace, processing the build trace to see exactly what goes into which binary it becomes much easier to zoom in and answer specific questions such as "what license does this binary have" or "which binaries use vulnerable file X" and combining it with efforts like VulnerableCode and PurlDB.

Read more about Tracing and rebuilding packages.

Trustix — Make build logs available as publicly verifiable, tamper-proof Merkle trees

Software build infrastructure is vastly underestimated in terms of its potential security impact. When we install a computer program, we usually trust downloaded software binaries. But even in the case of open source software: how do we know that we aren't installing something malicious which is different from the source code we are looking at - for instance to put us in a botnet or siphon away cryptocurrencies? Typically, we have confidence in the binaries we install because we get them from a trusted provider. But once the provider itself is compromised, the binaries can be anything. This makes depending on individual providers a single point of failure in a software supply chain. Trustix is a tool that compares build outputs across a group of providers - it decentralizes trust. Multiple providers independently build the software, each in their own isolated environment, and then can vouch for the content of binaries that are the outcome of reproducible builds - while non-reproducible builds can be automatically detected.

In this project the team will work on further enabling trust delegation, by offloading log verification to trusted third parties - heavily inspired by the Delegated Proof of Stake consensus algorithm. It will bring Trustix into the Nix and the Guix ecosystems that are most amenable to Trustix' approach. The ultimate goal is for Trustix to integrate seamlessly into the entirely decentralized software supply chain so we can securely distribute software without any central corruptible entity.

Read more about Trustix.