Open Source Summit (2022 trip report)
I attended the Open Source Summit this week. It was an interesting conference due to the breadth of topics. There were presentations on embedded linux, securing our supply chain, running an OSPO, and more. Coming out of the conference, I got a bunch of important context on two things that we should be focusing on internally: supply chain security and our open source participation.
I’ve been notionally aware of supply chain security for a bit, but given the presence of experts, I was able to get a bunch more details about the tactical aspects to it. At a high level, supply chain security ensures that from the time a developer commits their code on their machine until it’s sitting in production, there’s a record of what we’re doing and assurance that we’re not being duped. It protects us from a variety of insider and outsider threats and seems essential for compliance with legal regulation. I have meetings scheduled with our AppSec team to better understand our security posture here and figure out where we need to shore things up.
The portion of supply chain that I’m particularly interested in is cataloging each application’s transitive dependencies into a software bill of materials (SBOM). An SBOM includes information about an app’s dependencies, their versions, licenses, etc. This data unlocks a lot for us. We can proactively monitor these dependencies for security issues through tools like snyk and anchore, which AppSec is already rolling out. There are established standards for capturing this data and several vendors can ingest them to add additional functionality for us.
We also get a sense of the open source that we’re using. This is important for the OSS program, because we can do automated license compliance checks to ensure that we’re using the software in a way that adheres to our legal requirements.
Once we know what our dependencies are, we can begin to evaluate them for health. Many folks have heard about the log4j vulnerability log4shell. That project was maintained by just one or two folks in their spare time. Are there other projects that are critical for our company (and the overall open source ecosystem) that aren’t being properly invested in? Can or should eBay move away from these? Or fund some of that development with money or developers? These are questions that are important to ask, but we don’t yet have the data to allow us to have productive conversations. SBOMs and data analysis will help here. (Do you want to help w/ the data analysis? Ping me.)
On the OSPO side, I found a bunch of things that we could start doing or improve upon. First, I think it’s worth pointing out that I feel really proud of the stuff we’ve accomplished over the last year. At a high level, we:
- Clearly documented the opensourcing process
- Conducted training for new employees so they know what OSS is and how eBay does it
- Tracked who’s doing open source for eBay and ensure they have the right access
- Streamlined small contributions like bugfixes to upstream repositories
Looking into the second half of the year and into 2023, I think we could also begin to look at what it might mean to have an internal “open source culture” aka “innersourcing”. I know I’ve seen some of our platform teams being overwhelmed with support requests. In an open source world, we’d invest in documentation and asynchronous resolution methods. Our source repositories would make it clear how to get started and folks could just submit pull requests for features they need or bugs they found. I don’t see much of that internally, and I think it would allow us to move faster. The documentation and automation improvements it would require would help everyone.
I also think we’re going to start actively monitoring the health of the open source repositories we have using tools like CHAOSS. This will include ensuring that pull requests are addressed in a timely manner, issues are addressed, etc. If we have a hard time with maintaining our repositories, we can seek additional help internally or choose to publicly archive the project to better communicate the level of support we offer to the community.
All in all, it was a good conference. It generated bucket loads of good ideas and work for us, but I think that work will improve the security posture of the company as well as the likelihood of success for the open source team.
Ping me if you have any questions. :)