logo
Dates

Author


Conferences

Tags

Sort by:  

Authors: Michael Lieberman, Mihai Maruseac
2022-10-27

By now, we’re getting bored of hearing the “am I affected by X vulnerability?” question. However, as supply chain attacks become more sophisticated, answering just this question is insufficient. Instead, we need to think about: “If TravisCI was compromised, which software is affected? With a bad actor in your supply chain, what's the blast radius?” There is a ton of information today in SBOMs, in-toto/SLSA attestations, etc. However, these documents observed individually provide limited information, but when put together and related, super-additively expand the knowledge base of our software supply chain. We built a supply chain knowledge graph tool to help better understand the relationships between artifacts and their metadata/identities. Through this high-fidelity graph, we not only answer the hard questions posed earlier, but also make new discoveries. For example, we found that most build-systems rely not only on obvious dependencies like gcc, but often overlooked projects like libpcre and sed.
Authors: Steve Judd
2022-10-25

tldr - powered by Generative AI

The importance of understanding and assuring the trustworthiness of external dependencies in software applications
  • Modern software components contain a selection of external dependencies whose provenance is unknown
  • Assuring the trustworthiness of dependencies is often ignored by organizations and their engineering teams
  • Efficient, automated pipelines can be used to audit dependencies for vulnerabilities and license obligations, assess them against the organization’s security policies, and ultimately provide the ability to control which dependencies can be used and deployed within the organization
Authors: Ed Warnicke, Aeva Black
2022-06-21

tldr - powered by Generative AI

The presentation discusses the need for simplicity in addressing supply chain security in open source software communities. The speaker proposes the use of a canonical, unique, and immutable identity for software artifacts to simplify the problem space.
  • Software artifacts can be represented as an array of bytes and should have a unique, canonical, and immutable identity
  • Identity should be based on the byte array representation of the artifact
  • File names, locations, and URLs are not suitable for identity
  • Simplifying the problem space requires a change in perspective
  • Focusing on simplicity leads to reliability, performance, and security