Open Source Summit Europe 2022

For the past two years, the Kubernetes Release Engineering Team (a subproject of SIG Release) has been hard at work hardening the Kubernetes supply chain, aiming to make it SLSA Level 3 compliant by the time Kubernetes 1.25 is released. The road to level 3 has produced a complete suite of open source projects that constitute the fundamental building blocks of a secure supply chain. And now, other projects and companies can leverage the Kubernetes release toolset to secure their chains! Guided by the CNCF Security TAG Best Practices whitepaper, the Release Engineering team built a set of tools that allow anyone to: - Building and publishing SBOMs (Software Bill of Materials) - Securely releasing staged images and artifacts - Signing and verifying container images and binaries leveraging Sigstore's transparency log, CA, and public infrastructure - Generating SLSA attestations of each step in a release pipeline All release tooling was designed from the get-go to be completely general-purpose and the talk will feature how other projects beyond K8s itself are using them in their releases. To finish the talk, Adolfo will demo a reference implementation of a SLSA-compliant pipeline using the K8s Release Engineering tools which any project can use to build its release process.

As we start to pay more attention to software supply chains (thank you, SBOM!), an old problem has resurfaced with a vengeance: how do we identify a particular piece of software? The software world - and the US government - has a goal for automation and easy mapping from a software dependency list to lists of known badness (vulnerabilities, potential malicious back doors, less optimal development practices, etc.). However, this requires a common namespace and shared identifiers for software. The current challenge is not that lack of naming standards, it is that we have several, and there are large gaps between them. This talk will describe the challenges presented regarding software identifiers as we try to secure the software supply chain. We’ll review existing solutions (CPE! PURL! Device identifiers! Hashes!), potential risks, and lay out a collaborative patch to addressing this over time and how the open source community can help and get involved.

The potential of SBOMs to track vulnerabilities is widely recognized. Open source tools capable of creating SBOMs exist in abundance. However, many of these tools are inventorying software post-build, which relies on heuristics and can result in missing build and dependency metadata which limits the compliance and security benefits of an SBOM. Software is modular in nature - each component has its lifecycle and our SBOM creation and management should represent the modular nature of the whole. What if instead of relying on post-build tools we utilized a sum-of-parts approach to create component level Micro-SBOMs that could be stitched together to create one high-level SBOM? We refer to the process of taking one or more Micro-SBOMs describing some component of the same top level software and transforming them into a single SBOM as "composing". Instead of asking SBOM consumers to open hundreds of fragmented Micro-SBOMs, we’re working on a tool that can do the composing for us. In this talk we will share details on why post-build scanning isn’t sufficient for producing accurate SBOM, discuss operationalisation of SBOMs and motivate the need for more modular SBOM composition. We will demo our proof-of-concept SPDX SBOM composition tool and invite your feedback and collaboration.

Modern software is built with hundreds if not thousands of dependencies and transitive dependencies. Knowing not only what these dependencies are but exactly what parts of the dependencies are used in your software is a daunting task. Should a security vulnerability be found in particular file of a particular version of a dependency, how do you know whether your software uses that part? Enter GitBOM. GitBOM is an Open Source, minimialist scheme for build tools to 1) Build a compact artifact tree, tracking every source code file (including from dependencies) incorporated into each built artifact and 2) Embed a unique, content-addressable reference for that artifact tree into the artifact at build time. GitBOM is designed to construct verifiable artifact trees across languages, environments, and packaging formats with zero developer effort. While GitBOM is not itself an SBOM, it is compatible with and augments SBOMs. Come to this talk not only to learn about GitBOM (and how you can become involved!) but also to see how this build scheme can be implemented across languages and ecosystems. You will leave understanding how GitBOM can improve the security of your whole software supply chain.

SBOM has received significant attention due to recent incidents. Therefore, you can find many related tools and resources for generating it. However, detecting information about software running in an operating environment remains an unresolved problem. Although Apache patched the Log4Shell vulnerability last year, many applications and systems are still vulnerable. It becomes more challenging to detect and fix when an application embeds a vulnerable software component buried in long dependency chains. In this talk, Inhyeok Jang finds out how to determine whether vulnerable software is running on your systems and applications. In particular, he uses eBPF to detect which version of the software of interest, such as Log4j and Spring Core, from the running system without an initial configuration for each application. To this end, he will show what information needs to be obtained from the kernel when executing the java application. He also introduces how to process the data collected from the Linux kernel in the userspace to find out Java Archive information such as title and version. Using the implemented runtime java component detector, he verifies whether the vulnerable version of the component is used in the container images in a public repository and talks about the result.