Open Source Summit Europe 2024

OpenSSF and other organizations such as CNCF have been developing new technologies aiming at improving the security posture of open source and the software supply chain. This panel will give attendees a chance to hear from the very people involved in the development of some of these technologies and learn what's behind names like SLSA, S2C2F, and GUAC, the status of these technologies and how they relate to one another.

Large open-source foundations like the Eclipse Foundation are faced with the challenge of maintaining thousands of repositories for the numerous projects and monitoring that these repositories adhere to certain policies and security guidelines to provide an open, transparent and secure environment for the development of open-source software. We would like to present our approach to tackle these challenges: a system where our projects as hosted on GitHub have their configuration stored as code in a repository itself, and project members can request changes to this configuration by opening a pull request, and once approved, changes get applied automatically. With this approach it is possible to make the current infrastructure of a project transparent to everyone involved, highlight items that should be addressed to adhere to certain policies and empower teams to improve and secure their repositories more easily. In this talk we would also like to outline what we have learned while rolling out this service to projects at the Eclipse Foundation and how such an approach can help to increase collaboration in your community as members are able to learn from each other.

The ambiguity surrounding terminology and general uncertainty amplifies the end-of-life/end-of-support problem: What is end-of-life? How is end-of-life different from end-of-support? How does this affect supply chain and operational security? This presentation will begin with an overview of the EOL/EOS problem and suggest definitions for key terms to the discussion. Creating shared terminology can support the community in facilitating discussions around EOL/EOS and generating solutions. This presentation will map the EOL/EOS problem to other ongoing discussions including software naming and versioning, acknowledging that this is not a new problem and it is unlikely there is one singular solution. The presentation will also include discussion of the potential role of existing software transparency and supply chain security efforts, such as SBOM, VEX, and CSAF, may play in managing EOL/EOS. We will highlight the OpenEoX efforts from the OASIS community seeking to develop an open source, standardized method to ascertain the EOL/EOS status of products, as well as other ongoing policy efforts. The presentation will close with time for feedback on the presentation and discussion.

For several years now we’ve heard the mantra of shifting left to move security as early as possible in the development process. The aim is to enable developers to understand and produce secure code right away. The primary method to support developers is to enhance their IDE with extensions which can identify security issues, highlight insecure code practices and handle integration with external services. VSCode is one of the most popular IDEs with a flourishing community of extensions for data manipulation, theming, programmatic language features and additional debugging functionality. There is a great deal of trust placed in these extensions so what would happen if an extension turned against you? This talk explores the supply chain risks associated with VSCode extensions, what is required to get an extension included in the marketplace and how simply we hand over control to an unknown third party. We will demonstrate what an adversary can achieve with a malicious extension and how it represents a future red team target from enumeration, persistence and execution.Lastly we’ll offer advice on how to prevent common attack paths.

Open source dependencies pose the most serious threat for all software. Software Composition Analysis (SCA) tools can help understand the risk profile using data collected about known vulnerabilities. But what about the unknown ones? The Alpha-Omega project, sponsored by Amazon, Google and Microsoft, has been challenged with the tasks of scouring the most popular Open Source libraries in order to “clean the beach” to make it safe for everyone. But the beach is huge and how can this project be performed at scale? In this talk, Michael Winser, Alpha-Omega co-founder, and Dr. Munawar Hafiz, CEO of OpenRefactory, will discuss the progress that Alpha-Omega has made in scanning and repairing thousands of Open Source libraries. They will describe the scaling challenges, the data handling and storage challenges and how the information is made available to the end users.

A package’s permissions and capabilities constrain its blast radius if compromised. Analysing and restricting these permissions can thwart potential attack vectors, such as we have recently seen with inserting malicious code into programs via third-party libraries, sometimes by gaining commit access to an existing trusted package.
Security vulnerabilities can also be caused by excessive but well-intended privileges in packages that have unintended scope. Visibility into package permissions can help motivate the principle of least privilege within the ecosystem and increase scrutiny on dangerous capabilities.

Capslock is a CLI tool for analysing Go package imports that works on a callpath-level to look at only the capabilities accessible by the caller (instead of just looking at package imports). This ensures that the signals provided aren’t overly broad or noisy, in order to decrease false positive rates and prevent alert fatigue for users. This model is influenced by mobile phone permissions systems, where users can make decisions on the behaviours that apps require.

Capslock capability results are now available for Go on deps.dev, with support for more languages in development.