DJ Schleen: 

Remember the X-Files television show? Dana Scully was one of the main characters – a brilliant FBI agent who worked on unsolved cases involving paranormal phenomena. Often skeptical of the supernatural, she was always willing to keep an open mind, and she was also a great role model. 

She inspired many women in Technology, one of them being Lauren Hanford. Scully’s inspiration led Lauren into the field of Criminal Justice and Chemistry, and then she made a pivot into Computer Science, and Design. The catalyst being a desire to make doing homework easier.  

It’s funny how technology always finds us. 

Lauren has been a part of the open source community for years, and has a massive understanding of the space.

Recently, she brought the TACOS framework (Trusted Attestation and Compliance for Open Source) to the community to help assess the secure development practices of open source software. It’s a perfect companion to a software bill of materials. 

…and the name? It’s a nod to GUAC and to SLSA.  

Welcome back, to daBOM

Hey everyone. Welcome back to daBOM. I’m here with Lauren Hanford from Tidelift. Lauren tell us a little bit about yourself and how are you involved in Software Bill of Materials and SBOMs.

Lauren Hanford: 

My name’s Lauren Hanford, as you said. My day job right now is Vice President of Product at Tidelift. I’m responsible for leading product and design team efforts. Tidelift as a model is really focused on open source. As you are well aware, SBOMs come up when we talk about open source.

DJ Schleen: 

When did you get involved in technology in general? 

Lauren Hanford: 

My entry into technology in general, like many women my age probably started first and foremost with the agent Dana Scully. I was very inspired by the X-Files and started my college journey in criminal justice and chemistry.

I started tinkering around in Excel to make my homework go by faster. A professor recognized that as some software engineering promise. So I ended up moving into a different university, and a different degree, and finished up computer science at that point. Which as it turns out, was much harder than writing macros in Excel, but I got through it. 

A really funny side story there is one of my founders at Tidelift was actually in the same computer science program at the same time, but we didn’t know each other. While I was in that program, I did a minor in design studies and actually ended up working as a developer for a while and then went back into school for design. My career has been a real blend of technology and product and design ever since, all of that coming from a real user-centered, research grounded place. 

 I’m really fortunate to be able to get to do all of those things today. I get to do a lot of research with open source maintainers. I get to spend a lot of time talking to enterprise open source users and understanding their needs, and then work with my incredible team to design and build solutions.

DJ Schleen: 

You’re on the forefront of the user experience or how people interact with data surrounding SBOMs as they come from the open source community. What’s the biggest challenge that you face when talking with these folks about software build materials, inventory management, and the whole supply chain problem?

Lauren Hanford: 

I would say on the consumer side, right? The downstream consumers, both of open source and the folks who are in this new era of SBOM and accountability. Some of their biggest challenges are generating them and generating them, consistently across their entire application portfolio.

The tool set for generating these things is maturing rapidly, day over day. But this idea that you need to now be accountable and responsible for knowing where each one of your application teams is at and bringing that into a centralized view is a big challenge. Being able to do meaningful things with that data at that point is I would say another challenge.

On the maintainer side, I don’t think there’s as much of a challenge. By and large maintainers are not paying a ton of attention to these kinds of moments. The way that they think about managing dependencies or any challenges around that is very different from the enterprise. 

By and large, our data has shown that open source maintainers are not generally aware of any of the Executive Order, the NIST SSDF, scorecards or even SLSA. The majority of the maintainers I work with day in and day out have self-selected into an intentional software supply chain, so they’re going to tend to have more awareness. 

DJ Schleen: 

What are people doing with SBOMs? What kind of data are you extracting to help the community

Lauren Hanford:

A lot of what I’m working on these days, you could think of as SBOM enrichments. At this point, it’s generally going to be a best practice that you do need a way to centralize SBOMs into a single view. Any administrator is going to need to have at their fingertips, where are my different teams on this journey? 

But what I’m really interested in providing with the TACOS framework is what I would call SBOM enrichments. It’s starting with that index of packages that you’re using. That’s going to be both direct and transitive packages. Then it’s taking a look at what are the different secure development practices that went into building out that open source at that moment in time. In other words, you can create a record of the practices that were in place when that SBOM was committed by your application team. 

 You mentioned TACOS. What is TACOS? 

TACOS stands for the Trusted Attestation and Compliance for Open Source Framework. We worked really hard to get it to fit into that acronym in order to play well with GUAC and SLSA already out in the space.

In the same way that SLSA is giving folks a concrete way to measure what are the different build time practices in place? What are the different security implements along the way? TACOS is giving a broader record actually of, did the project have a security policy in place? Who’s the security contact? Did they have 2FA enabled on the package manager? Did they have 2FA enabled on the source repository. And other pieces of material like that. The data structure is going to interoperate really well with GUAC. I know you had a guest on where you talked through that. GUAC is able to take in all different kinds of metadata and allow customers to really navigate that metadata.

TACOS is a structured format that is about the build practices of the open source maintainer. 

DJ Schleen: 

There’s also a attestation system for TACOS. What are you attesting? 

Lauren Hanford: 

A lot of this information that is in TACOS can only be attested to by the actual maintainer. So knowing if that 2FA was enabled, knowing if a security policy is truly in place and is it right. It’s a little bit of a “yes and” off of some of the OpenSSF scorecard pieces that are taking a scraping automated approach to discovering some of this metadata.

What we’re doing within TACOS is taking a more manual approach. We’re working directly with maintainers and we’re actually incentivizing the collection of that data. The attestation itself is coming from the maintainer themselves, and then we’re able to bundle and normalize that through what would end up being a JSON file that comes out of TACOS.

DJ Schleen: 

Is that JSON file any specific format like CycloneDX or SPDX, or is it a custom TACOS export of JSON? 

Lauren Hanford: 

Right now it’s just a very basic generic JSON format, so it’s custom to TACOS in that sense. But folks can generate them, they can store them, and then you can use the external resources fields in a CycloneDX or in SPDX SBOM to link out to it.

I would say I fit more maybe, in and amongst all the people you’ve talked with, I’m more in the party of wanting SBOM files to be pretty minimal and streamlined. I would prefer to link out to other documents like your VDR, your VEX, TACOS, things like that. 

DJ Schleen: 

On that note, there’s different opinions about whether you have things travel together in one document, a series of documents that are linked out.

You mentioned having it external because you like keeping them small. Where did you find that kind of information? Was that something that you learned over time or was that just dealing with these on a practical basis, or is it like some kind of philosophical or decision behind it? 

Lauren Hanford: 

It’s probably a blend of a lot of that stuff.

 I am bringing a sort of designer mindset to a lot of these things. I prefer to stay very crisp on form and function. What is the utility of the artifact? How do we make that as minimal as possible versus a, kitchen sink type of approach. I don’t have a black turtleneck, but that’s an ethos for me. 

DJ Schleen: 

That’s awesome though, because you’re taking in that background, your educational background of design and actually thinking almost like the developers are going to use this, or the consumers are going to use this in some sort of format. But you’re using your design background and your engineering background to come up with that solution. That’s pretty cool. 

Lauren Hanford:

Yeah. Yeah. I think it makes sense to keep those things more separated. I don’t have tactical proof of this, but it feels to me directionally, like maybe it de-risks having all of that information together. 

And then of course, the lived experience is realities of how large these file sizes can get and what that may mean for storage, et cetera. Then thinking about it from the practical standpoint, with the maintainers that I work with, where can they add the most value? Does it need to be bundled up in a giant document, or can we think of those pieces as more disparate? Your VEX would be a really good example of that. 

DJ Schleen: 

So tell me a bit about VEX. How do you see the VEX space going and collecting that data? It’s a little bit manual. There may be some automation opportunities in the future, but they might not be there yet.

Lauren Hanford: 

In some ways it feels like a very new concept. In other ways, I know a lot of folks have been working diligently and delivered some really interesting ideas. 

I’m tending to take that more manual view right now. I think that software producer is the person who’s going to be putting in that manual effort, and the downstream consumers of that, whether you’re a commercial third party tool, you want your downstream consumers to be able to get that really manual automated experience. 

For me, working directly with these maintainers, I become the centralized software distributor role where it’s my job to ensure that I’m doing the work to get the manual information that’s right, and then I’m doing the work on the other side to ensure that it’s an automated, frictionless experience for the end consumer, and that it’s showing up in the right place for the right person, in the right format. Because that’s going to be different if you are a compliance office versus a developer that just needs to push to prod and get the thing. You’ve got a different set of circumstances there. 

DJ Schleen: 

How are you dealing with that range of consumer, with having different consumers with different needs or different use cases? Do you define use cases for each consumer and then work towards those? 

Lauren Hanford: 

I think of it as a very use case, based approach. One use case may be we’ve got a goal internally where we do need to reduce the number of vulnerabilities in our code base. You’re going to leverage centralizing SBOMs, looking for patterns to identify risk that’s showing up more frequently for an organization, and giving tactical, actionable information to take care of that. 

Another use case could be something that looks more like, we want to reduce technical lag where our code base is very old and so we’re looking for a pattern of many multiple majors behind, et cetera.

When you have the kind of enrichments in place that TACOS offers, then you can start to see things like, this package or this graph is starting to look zombified. And many open source packages are not going to have an official practice of declaring something end of life. But you can look for different kinds of signals that start to show you this emerging zombie status.

 You could use that to take a more proactive approach to risk management. You can layer that on to where do CVEs exist to get a better and better picture of where to spend time. Ultimately, all of the challenges in software supply chain security really do come down to scale and uncertainty.

 SBOMs are a really great first step into navigating both of those challenges 

DJ Schleen: 

Patrick Debois recommended that I read this book called Code is a Crime Scene. If we treat our SBOMs like a crime scene, we can actually look at heat maps and see where the biggest problems are and then that starts honing where you address issues. How do we move security left and how do we move the decisions for the right components the best version that has the least vulnerabilities. And then go down to instead of 20 versions of Log4j, you have two. 

Lauren Hanford: 

Another use case too, you could use that same data and that same process to also see, there’s something really critical, some infrastructure where we’re relying on, it’s looking sketchy. Let’s send some of our development resources out to shore up this project. This may be something that it’s really important for us to contribute to. 

DJ Schleen: 

You talk about infrastructure, how does that fit into build systems? Are you doing some kind of iBOM, hBOM? Is Software Billing of Materials the only kind of artifact or that you’re looking at? 

Lauren Hanford: 

I’m just looking at software BOMs today, so nothing at that infrastructure level. I would say, for me it’s really more about trying to shift the conversation out in industry to really think about open source as critical infrastructure, which is why I’m using that word. It’s not that I’m delivering an iBOM. There could be something out in the future where there is a more specific format of a BOM that is talking about development practices. 

That was what was really interesting to me about the NIST SSDF when I really started deep diving it.

DJ Schleen: 

When we talk about the industry in general, how are you seeing the effects of Executive Order 14028, this information that you need to share out to the federal government? 

Lauren Hanford: 

There’s definitely a lot of… anxiety feels like too strong of a word. There’s almost a reaction of unbelievability in some sense. I do think that directionally it’s right, we need it, but it does feel like it’s going from zero to a hundred really fast. That’s been hard for people. When I’m thinking about this from that user experience place, I recognize that it can feel really overwhelming.

I thought something that was really pragmatic about the memorandums that came out, putting the teeth behind the secure software development framework, it seemed like a pretty practical approach to me. It was recognizing, I felt like a lot of the things that folks are already doing or they’re on some journey with it. Because it’s broader than “just” (air quotes here), generating an SBOM, which in and of itself is challenging. it takes not just tooling or time, it takes organizational will, it takes coordination across a lot of different teams potentially. You’re competing for time with a lot of different initiatives that are native to the business.

 I’m excited to see the maturing of the tools in the space. There are a lot of ways to do this now that are getting easier and easier. You’ve had other guests who talked about being able to reach out to others in industry who are further along in their journey and to learn. That’s something I really love about working in this domain in particular, is how much people work in public and how much you can learn from what other people have done before you, where I hope it becomes easier and more of the norm. It’s got to become more of the norm at this point. 

DJ Schleen: 

When you’re talking about generating an SBOM do you think it’s almost like a commodity now. There’s so many tools that can do this. Do you see any gaps with tooling right now generating these things? 

Lauren Hanford: 

I do tend to think that it’s a commodity at this point.

I don’t want to be flippant when I say that because I know that the organizational will around it can be challenging. But there are really great, wonderful, free tools at this point to get started. 

Where the bigger gap is right now in the tool space is that, “Okay, now what?” 

We need to be able to centralize the view of what we’re seeing in our software. We need to know what actions to take, all actions can’t be equal. They can’t be prioritized the same. That opens up different tool sets around prioritization and those sorts of things. 

DJ Schleen: 

Have you seen any challenges with the formats with each other 

Lauren Hanford: 

I haven’t personally witnessed any of that because of the sort of robust research and frankly, manual effort that I’m working with in my day to day. But yeah, the need to come to some kind of consensus on these things feels critical. CISA and others are trying to get there, right? They’re doing the work to do that. 

You and I spoke last week briefly, and you had said the, “Oh no, the no assertion nightmare!”, when I was showing you some of the TACOS reports. 

The TACOS report, if you’re thinking of that as an enrichment, and an enrichment that’s really intended to show what was happening all along the software development lifecycle when this open source was built. There are going to be some no assertions there right now because you have to get that information directly from the maintainer. 

The space my head is in the day-to-day is thinking, this idea of no assertions could actually be beneficial right now because it’s showing that for the 70 to 90% of software being built with open source, how much is really unknown. We’ve got to do a better job with knowing and making good choices about the commercial software releases that eventually affect you and I and other downstream consumers and our data. 

DJ Schleen: 

As someone who’s involved in product development around Software Bill of Materials and systems that can support them, what do you say to people who are like, why do I need one? Let’s start with from a security perspective. What would you say to a security organization in that respect? Why do they need one? 

Lauren Hanford: 

For a security organization, it’s really mission critical to have an SBOM mapped to every application under your purview. And be able to react with agility when a Log4Shell moment happens. You do not have time to waste to figure out where in your organization these vulnerable releases of Log4j are coming in, to ensure that the application teams who have the capability, they’re working on the project and can get on the right upgrade paths, that they have the information they need. 

Then you need to be able to go back as a security leader and verify that you got all of it. It does come back to that crime scene idea. 

That’s the most key piece for a security organization. There’s a lot of proactive type benefits to an SBOM butI security folks are really belabored with the rise of how many CVEs we’re dealing with and really filtering through what’s noise, what is really critical.

Something that gets the level of attention of Log4Shell, it’s obvious. This is something that we need, it’s priority one. But what do you do with that messy middle of everything that may not be as clear cut as that? Eventually we will get to a place where more proactive approaches become a core part of the security job.

But right now, I think in some ways that more proactive piece is showing up in the software delivery manager, more the DevSecOps role. 

If their job is really to shore up efficiency and using development time effectively, the more that they can look at a reactive risk posture that’s coming from CVEs in a more proactive risk posture where things are starting to look sketchy, the better that they’re going to be able to make use of that developer time. 

DJ Schleen: 

What these can do for us is enable decisions because it’s the data that we have, and especially when you enrich that data and add more information to it, we’re really going to start seeing different techniques and approaches to the application of security left in the developer space and even along that build system or build process. And then the artifacts at rest, and of course when we ship our software to a consumer, chances are they’re going to start asking for SBOMs, even though they dunno what to do with them. 

Lauren Hanford: 

It is, it’s decision making, it’s the triaging risk, it’s, going out and improving your risk. It’s creating more predictability and having more control over your future. When you can see that there’s a project you really depend on, you’re not going to move away from it, it would be useful to know if that project has shown signal where they’re opting in and want to be a part of your software supply chain.

When I think about Log4Shell specifically, I can’t help but think that we as an industry are really taking it for granted in this moment that the maintainers are going to continue to respond to security research and to issue fixed releases.

 I know that’s been generally something that we can count on. But it matters to take that more proactive look and see is this a project that’s going to be responsive to security. 

DJ Schleen: 

Maybe it was the State of the Software Supply Chain that said that people are still using the vulnerable version of Log4Shell. Maybe they don’t know that they are. Software Bill of Materials may help elevate that on a, not just a singular repository, but on the whole enterprise, and I think that’s what we’re trying to talk about. 

 It’s easy to do SCA on one repository. Software Bill of Materials isn’t SCA, but getting that inventory of components across and then running that whole thing through a vulnerability scanner is going to help you get some visibility in that whole crime scene type of idea.

Lauren Hanford: 

One of the really key things that inspired TACOS was seeing the few examples that were bubbling up where compliance teams or security teams were reaching out directly to open source maintainers and saying, “I need you to attest that you are not using vulnerable releases of Log4j”. That is just not realistic that we can continue to expect that. Or that we ever should have expected that. 

TACOS is a way to give maintainers the capacity to begin that kind of attestation. I think it will be an enriching artifact as we move ahead. 

DJ Schleen: 

For more information for our listeners on TACOS, it’s github.com/tacosframework, all one word. Definitely something to check out. 

 Lauren, one last question. If there’s one thing you’d like to see SBOMs do for the industry or for humanity in general that’s not there right now, what would that be? 

Lauren Hanford: 

I want to see an intentional software supply chain where maintainers who are producing open source, who want to be paid for the secure work they do, that goes into that, that they have a way to get paid. Reliably, recurring, commensurate income with the work that they’re doing to keep their packages developed in a secure way. That’s what I want to see.