Software Bill of Materials With Barak Brudo

Transcript

Mandi Walls: Welcome to Page It to the Limit, a podcast where we explore what it takes to run software in production successfully. We cover leading practices used in the software industry to improve the system reliability and the lives of the people supporting those systems. I’m your host, Mandi Walls. Find me @lnkchk on Twitter. All right, welcome back. This week I have with me Barak Brudo. Tell us a bit about yourself and what you do, and we’re going to get into SBOMs today.

Barak Brudo: Sure. Well, like you said, my name is Barak Brudo, I am the DevRel for a company called Scribe Security. It’s a small security startup from Israel dealing with securing the software supply chain. A relatively new realm in cyber security, but not any less important because of it. I have a history of working as a developer. I worked as an ERP developer and then as a full stack developer. I came to Scribe for an interview as a developer. They heard me speak, they saw that I was articulate, I guess, and asked me, “Have you ever considered a career as a DevRel?” And I said, “No, because I don’t know what that is.” So they sent me the requirements. It sounded interesting. Oddly enough, I have a degree in education in art, so I’m well suited for teaching, explaining. It’s also something I enjoy doing. I just decided not to take a career as a teacher because I wanted to be able to feed my family. And so here I am, as a developer advocate, the explainer extraordinaire. It’s my job to explain complicated things simply.

Mandi Walls: Awesome. Welcome to the world of DevRel.

Barak Brudo: Thank you.

Mandi Walls: Many of us fall into that path for a similar reason. Let’s talk about software bill of materials. For folks who aren’t sure what’s going on there, may have heard it in the news, may have not heard about it at all, what’s the basic starting point for them?

Barak Brudo: The software bill of materials, if you remove the word software, it’s just bill of materials. If you say, “Bill of materials,” most people would envision a list of things. Like here’s a big truck, it’s full of things. I want to offload that truck, and here’s a list of all the stuff that’s in there so that when I offload that truck, you know what you’re getting. So just add the word software back into the mix, and it’s essentially the same thing. It’s a list of ingredients, both files, packages, everything that is in a software artifact. It also has a lots of other information, like version numbers, relative paths of everything, relationship between files and packages. It’s a very comprehensive, essentially, window into what is this software artifact containing? Extremely useful. The easiest comparison that I can give is the same as looking at a food packet in the supermarket. You turn it around, you can see all the ingredients. It’s extremely useful because that way you know if you’re allergic to anything, if it contains something that you might not agree with, either on a legal basis or on a biological basis of some sort.

Mandi Walls: Sure.

Barak Brudo: And again, the simple fact is that a lot of people, when they think about, “Ooh, it tells me everything in it, so it’s actually a secret recipe.” No, it’s not a secret recipe. Same as you can’t really recreate a food item from the supermarket in your kitchen by reading the ingredients, you can’t really recreate a software artifact by seeing what’s in it. The easiest example I can give is a very, very well-known file called index.HTML. Almost every piece of software would have a version of this file somewhere, or pack adjacent, or stuff like that. Lots of softwares have that file, and that file will be listed in a software bill of materials. It wouldn’t tell you what’s in there. It would just tell you this file is there. So you wouldn’t be able to recreate a software or code. It’ll just be a very useful tool for you to be able to tell if a certain problematic package or a version of a package is in that software that you’re about to get or about to deliver to somebody else.

Mandi Walls: So this is something that’s come into the news in the past couple of years, right? As far as like-

Barak Brudo: Yep.

Mandi Walls: … something that is become, I’d say, increasingly apparent that is needed maybe for more things as a result of breaches and other problems that have occurred in software vendors. So when we talk about software supply chain, and we talk about how all this stuff fits together, what does that actually mean for folks that might be building these things?

Barak Brudo: Well, the idea of the software supply chain is, well, both complicated and simple. It can mean a lot of different things, so in the interest of being clear, I’ll explain what it means when I say it. Most code currently in production everywhere on the planet is composed by of a large degree of open source. That means that most people don’t want to reinvent the wheel, they don’t want to write everything. And if they need a function or a library, they’ll just go online, find something that works, download it, either they improve on it, change it, or just use it as is. Now, if you take that same idea into its logical conclusion, you use open source packages. When the people who write open source write their code, they also use open source packages, and so on and so forth down the line. That means that when you incorporate something into your code, even if you could theoretically go and see what they’ve used, at some point, you lose visibility. I mean, go down 5, 6, 10 levels, and there’s no realistic way, or at least there’s no realistically easy way, to dig into all of that code and see all the dependencies, especially because software is a very dynamic thing, it constantly changes. So when I say software supply chain, what I mean is that this is essentially, let’s call it, the endless chain of progressively interconnected dependencies that ends up being inside your code. When other people say software supply chain, they also mean in addition to this, all other softwares that happen to be inside a certain network. For example, the SolarWinds incident started with an HR software. It wasn’t part of, let’s call it, the software that was delivered from various companies. But because that software was inside their network, it found a way to infiltrate, exfiltrate, various other things through a back door. So that is additional, let’s call it, openings for vulnerabilities. But for this discussion, when I say the software supply chain, I mean that endless or almost endless list of progressively further away dependencies of open source. You can’t really get a good visibility without something like an SBOM. The SBOM not only tells you everything that’s in the software. It also tells you the relationship between everything. Dependency is one type of relationship. It’s also the easiest to explain. But there’s lots of other types of relationships, especially if you’re considering that the software was built from files. So a certain file in that final artifact might be a log file. It might be the result of a test. It there’s lots of other variations of the relationships between various files and libraries in a certain piece of software. So the more information you have, the more information you can give to a reseller, a user, the better suited they are to make their own security decisions. The worst thing is getting that piece of software as a black box. There’s lots of examples of people who got that black box, trusted the vendor, and eventually found out that they were legacy code, there were vulnerabilities. Nobody ever bothered to fix it because the code works, so why mess with it? So unless somebody’s actually held accountable, responsible, nothing will get done. When you’re making people commit to a software bill of materials along with the deliverable, when everything is visible, people are more inclined to make sure that everything is at least updated to the last stable version in terms of open source and other such components of software.

Mandi Walls: Okay. You mentioned the SolarWinds breach from a couple of years ago.

Barak Brudo: Right. End of 2020.

Mandi Walls: End of 2020. Oh. Man, it feels like forever ago, right?

Barak Brudo: Yeah, it does.

Mandi Walls: So with that one-

Barak Brudo: And it’s been a long couple of years.

Mandi Walls: And it really has. With that one, you mentioned that they had come in through another system and then infiltrated into… What? The build process, I think, was where that went, right?

Barak Brudo: In SolarWinds, yeah. They infiltrated the build server and added a few lines of code into the final product.

Mandi Walls: Yeah.

Barak Brudo: Because it was already in the build server, nobody noticed. The code went out as an update already signed with the company’s certificate, so everything looked kosher. Because that company has been at work for years, nobody was checking constant updates. I mean, you constantly get updates. You’re not going to check every single one. So the update went out as per usual, and that backdoor was installed in a lot of different systems, including nine different federal agencies. Which prompted, in 2021, the Biden administration to release an executive order, which later was followed by NIST’s SSDF, the Secure Software Development Framework. And essentially, this whole thing, the executive order and the SSDF means that the federal government is definitely putting a push on improving the nation’s cyber-security, and both the executive order and the SSDF mentioned the SBOM by name. So the federal government at least sees the SBOM as an important ingredient in making sure that software is at least visible, if not secure. And again, visibility is the first step in making sure something is secure.

Mandi Walls: Looking back at SolarWinds, if we had had an SBOM of that, what’s the functionality there? Are we looking at check sums of all those files? Are we looking for some other piece of… What’s the underlying mechanism that would tip people off that something is wrong?

Barak Brudo: Well, that’s actually going more into the territory of what Scribe is doing.

Mandi Walls: Right.

Barak Brudo: Because Scribe is using the SBOM to create an integrity report.

Mandi Walls: Okay.

Barak Brudo: The SBOM includes hashes of files. So it doesn’t actually need to look at code, it just creates hashes of files. Scribe essentially. Uses SBOM at the beginning of the pipeline, at the end of the pipeline, with the final image. We compare the two. If the hashes are different, files have been modified. And once you sign those SBOMs making them into attestations, they can’t be modified. That means you have basically an ironclad piece of evidence that everything is as it should be. If SolarWinds, in this example, would’ve used such a system, it would’ve immediately told them that what they sent out was not what they intended to, that something was different. Now, again, Scribe in this instance, and we’re not the only company that’s digging into this new niche Scribe, in this instance, wouldn’t tell them necessarily how it got done or why, and it wouldn’t even tell them where in the file the different part was it would just tell them, “Ah, this file is different. Red flag. There’s a problem. Better check and better look into this.”

Mandi Walls: Mm-hmm. Okay.

Barak Brudo: Because, again, the idea behind Scribe and other companies that are dealing with integrity verification is just to make sure that what the company intended to ship out is exactly what they shipped out, that any problems or mistakes are their sole responsibility and that nobody unbeknownst to them has interfered in what they intended to ship out.

Mandi Walls: Okay. Cool. And you mentioned the SSDF and that NIST is involved. So we’re looking at then industry-wide requirements, or [inaudible 00:12:03]-

Barak Brudo: It’s a new framework, a new best practices-

Mandi Walls: Yeah.

Barak Brudo: … system. Yes. The interesting thing about this system, unlike other regulations where you have a law and you have auditors, this one was essentially, it’s aimed at the pockets of people.

Mandi Walls: Okay.

Barak Brudo: What the executive order said that after a year, which has already passed. Because the executive order came out in May of 2021, we’re way past May of 2022, and the OMB has already instructed federal agencies to start immediately following the SSDF. So at this point, if you’re a company that wants to sell to the federal government and you’re not compliant with the SSDF, they won’t sign a contract with you.

Mandi Walls: Okay.

Barak Brudo: Which is very simple. So if you want to sell to the federal government, you need to show that you’re compliant. Now, the beautiful thing about this is because we’re talking about software supply chain, because we’re talking about very complex systems that are built on top of other systems. Let’s say that you are a very, very big security contractor, you make airplanes. And disregarding the hardware, airplanes include a lot of software, and that software is being aggregated from lots of different vendors. So if you need to be compliant, if you need to show SBOMs and other pieces of evidence to the federal government, obviously you’re going to request them from your vendors. And of course, they’re aggregating as well, so they’re going to ask them from their vendors. And eventually, because everybody wants to be on, let’s call it, the nice list of the government, everybody wants to at least have the potential capability to sell to the government, or to sell to somebody who sells to the government, eventually, and hopefully not in too long of a timeframe, the SBOM and other pieces of evidence along those lines will be commonplace. It makes a lot of sense. It’s not too complicated to implement. It increases visibility and trust in a drastic manner all across the board. So the only reasons not to implement them is if you’re trying to hide something. I think at least. That’s my opinion, yeah.

Mandi Walls: OK. That’s a bold statement.

Barak Brudo: I know. I know.

Mandi Walls: So are you starting to see this come into the rest of the private market? Like it’s one thing to sell to the, at least the federal government in the US. Is there also comparable legislation in the EU? That’s another pretty big margin.

Barak Brudo: Well, no. Because like I said, the beautiful thing here is that the software supply chain is not limited-

Mandi Walls: Yeah.

Barak Brudo: … by, let’s call it, terrestrial borders.

Mandi Walls: Mm-hmm.

Barak Brudo: The imaginative airplane that we’re composing needs software from Africa, from Israel, I don’t know, from Germany, then that’s where it’s going to go get its software. And if that seller of an airplane needs to show in SBOM, it’s going to request that SBOM from everybody. He doesn’t care, or it doesn’t care where you are located. It needs that SBOM. So the software supply chain and the trickling down of requirements is going to be global. There’s no doubt about it if you want to be able to sell to the federal government. And like I said, who doesn’t? No matter where you’re located, those requirements are going to become a best practice standard, and they’re going to be implemented globally, doesn’t matter where the requirement is initiated, in this case-

Mandi Walls: Okay.

Barak Brudo: … United States.

Mandi Walls: All right. Excellent. It feels like we’re in a good direction with that.

Barak Brudo: Mm-hmm.

Mandi Walls: Because outside of the other stuff that sometimes falls apart, right? Like I formerly worked at a company that shipped a lot of open source software. And with that, you also have licensing concerns for some customers about the GPL, and how that works, and we have our own discussions internally about how that impacts the software that we build, and all of those kinds of things also come into it. So I feel like at least some people were already thinking about how you put this together, what it does, where you place it, all… It’s like the logistics of it on some sides like this. But and maybe Scribe helps with this, right? Like the logistics, or like the implementation of making sure you have all these pieces, and what does it do? Is it then something that you require a customer to run? I’m not sure what the government requirements are going to be, that they’re going to get this list and then be able to audit it against the piece of software [inaudible 00:16:23]-

Barak Brudo: Currently, the SSDF is extremely generalized-

Mandi Walls: Okay.

Barak Brudo: … because the SSDF is intended for everybody, no matter what industry, or technological stack, or industry they’re implementing it in. So it’s written in a very generalized way, but it includes essentially all of those common sense steps that if you have to think about them make a lot of sense obviously. Like requiring developers to have 2FA and sign their commits.

Mandi Walls: Okay.

Barak Brudo: And requiring that you have at least a plan in place to deal with vulnerabilities or exploits, that you have a plan from the minute that you start designing a product to the end of life of that product. How do you tell people that you have people in your organization that are in charge of this thing? That whatever requirements you decide for yourself, you communicate them clearly to your partners so that they can all be held responsible to the same standards.So if, for example, you say, “No packages with this type of license,” then you can’t receive a piece of software that includes that type of license, and that sort of thing. So it includes a lot of different pieces of advice. For example, the crypto signing various pieces of evidence, automating tests in the CI/CD pipeline, a minimum of human interference so that the more automated the pipeline, the better so that you can essentially sample various tests, make those tests into attestations, sign them. Lots of digital signing on everything so that there’s lots of pieces of evidence. The more evidence the better. And so essentially, what the SSDF says, or actually what the executive order says, you don’t have to show us that you’re compliant. All we ask you to do, because there’s no auditors of any kind.

Mandi Walls: Okay.

Barak Brudo: All we ask you to do is to tell us that you’re compliant. We’ll take your word for it until something happens. If you lie to the government, you say that you’re compliant when you’re not, well, then there’s criminal charges involved and huge fines. We better not catch you lying to us. So essentially, it is still a lot of trust involved. But yeah, most people would not be caught dead lying to the federal government, not if they want to continue doing business with them. So if you’re saying you’re compliant, you better be.

Mandi Walls: Excellent. So is there anything that you think is missing, or any shortcomings on this one? It’s early days.

Barak Brudo: Well, yeah. But there’s a lot of people still working on the standards of SBOM. Because obviously, it’s a work in progress, it’s going to be such a work for a while. Currently, the current standards, the two big ones are CycloneDX and SPDX are backed by the Linux Foundation. And the second one, give a second, it’s the OWASP. I always forget that [inaudible 00:19:05]-

Mandi Walls: Okay. OWASP? Yep.

Barak Brudo: Yeah. Because I don’t want to call them WASP for some reason, so… So yeah, so they’re backed by those two large organizations. Slightly different, they’re both contain lots of information. But both of them still mainly work extremely well for monolithic pieces of software.

Mandi Walls: Okay.

Barak Brudo: The way the SBOM is built, you give it a huge artifact of software. It looks into it, breaks it down into its constituent components and rebuilds this list of all those components and how they’re related. It doesn’t work as well if you’re thinking about really, really disjointed architecture, like microservices, and cloud services, and various other types of services that are interconnected, but not actually linked. Because then, when you try to feed something into an SBOM, you won’t really get anything. I mean, you’ll get lots of different pieces, but instead of getting one SBOM that says, “Here, this is the software. You can look at everything,” you’ll get a pile of them, and you’re not really sure how everything is connected.

Mandi Walls: Yeah.

Barak Brudo: So that’s one of the main shortcomings currently with technology, and people are still working on figuring out how to overcome this shortcoming. But the very nature of composable technologies is that it’s built of lots, numerous, not interconnected pieces which can be reconfigured in various different ways, and that’s part of the issue here. Some of the things you mentioned are already part of the solutions that the SBOM can offer, like license poisoning.

Mandi Walls: Okay.

Barak Brudo: You can, if you can see, all the licenses of all the software inside a piece of software, obviously you’ll be able to immediately check if you’re ingesting something that might make your software into open source unknowingly. For example, having a full list of all the packages and version numbers means that you can easily scan those for known CVEs vulnerabilities. There’s a new exploitation database being built called VEX, again, for the purpose of comparing SBOMs to it so that you can immediately see-

Mandi Walls: Okay.

Barak Brudo: … if you have such a problem. The idea is that the more standardized SBOMs become, the more easily you can share them and make them machine readable, the easier it will be to implement other pieces of comparable technology to then scan those SBOMs and give you insights about them. So like you said, it’s not necessarily early days. I’m considering us to be roughly in the middle of the process.

Mandi Walls: Okay.

Barak Brudo: But more and more people are becoming aware of this, of the potential benefits. Little old me who doesn’t have too much authority on the matter, but it’s my personal prediction that we’re definitely going to see a massive implementation and adoption of SBOMs across large swaths of industry, especially where people are going to feel the pain. For example, a lot of people have already felt the pain when it comes to medical technology.

Mandi Walls: Sure.

Barak Brudo: Because people find it much more personal to consider vulnerabilities in a piece of technology that’s implanted in their own bodies, like pacemakers or insulin pumps. You don’t want to think about your pacemaker or insulin pump being hacked or suddenly stop working because it has a vulnerability or a legacy system. So there’s a slew of different laws passed by Congress a couple of months ago specifically targeting medical technology. But that sort of thing is just going to, I think, spill over and be implemented in other types of technology. Because the same thing that you can say about medical technology you could probably say about cars.

Mandi Walls: Yeah.

Barak Brudo: Or the energy market. I mean, oil pipelines, gas pipelines, there’s lots of different pieces of technology that are around us that you don’t want to see filled with vulnerabilities just because somebody was careless or not diligent enough in updating packages because, “The code works, so don’t touch it.”

Mandi Walls: Right. Yeah.

Barak Brudo: Increasing visibility is a good thing, like we said.

Mandi Walls: Yeah, definitely, definitely. All right. So one of the other things we always ask folks on the show, and this has been some great information. But what’s a myth that you can debunk for us about SBOMs? So since there’ve been so much in the news, there’s, like we mentioned, all these regulations coming through. What’s something that we can clear up, a misconception of sorts?

Barak Brudo: Well, I mentioned that a bit earlier, but some people are hesitant of employing it because they’re worried about, well, essentially a foreign piece of software or code looking into their system. Looking into their code, who knows what they’ll see? They’re spying on us. What will happen to our precious IP? It’s ours. If other people see it, we lose money. So yeah, like we said, the SBOM, no matter if you’re using a proprietary system or an open source system to generate it, doesn’t look at your code.

Mandi Walls: Yeah.

Barak Brudo: It doesn’t need to. It doesn’t care if you’re writing in Java, or JavaScript, or Go, or Rust, or whatever. It doesn’t look at the code. It just looks at the files and generates a hash based on those files. It doesn’t need to look at the code for that. Unless you name a certain file, “This is my secret recipe.JX” making it into a target for anybody who wants to look into your system, there’s not really too much people will be able to tell other than you’re probably using React, or you’re probably using, I don’t know, an Ubuntu system, because we can probably look at the way the file system works on your software and deduce that probably. But I doubt it’s that much of a secret if you’re working on, I don’t know, Windows or Linux, I guess. So again, it’s, there’s not that much of a secret that is going to come out of an SBOM. Some other things that people are worried about is, again, the issue of connectivity. Because again, the idea of the SBOM is you generate it, you want to share it, or at least other people want you to share it either with resellers, vendors, clients, customers. So if you’re talking about very large organizations are very worried both of their IP and security, a lot of those infrastructures are not even connected to the internet. Because they’re really worried about their security issues, so obviously working in a completely isolated environment is one of the first steps. So in that instance, you can generate those SBOMs internally, keep them, save them, use them for your own purposes. And when it’s time to share them, you can even go over them, scrub whatever it is you don’t want to people to see. For example, I don’t know, you took an open source library off the internet, changed its name, changed its content, but you don’t want anybody to know about it. Remove it from the SBOMB. It won’t be a full SBOM, but-

Mandi Walls: Yeah.

Barak Brudo: … you’re fine. So again, the idea of risking, or oversharing IP, or code, or ingredients, or any sort of dangerous penetration of privacy for organizations is a myth, a dangerous one at that. And the more people know about this technology, I think the easier it will be to adopt it.

Mandi Walls: Yeah. I feel that way, too. As more folks get on board and recognize that it’s something that we need at this point in the industry, that it will smooth things over as it becomes more common practice. So yeah, definitely. But as you’ve been working with this, and we’re all new to this, but what’s one thing that you’ve learned, maybe not just as you’ve been with Scribe, but maybe over the years, something that you could share with our audience that you wish you had known sooner? Like is there anything out there that’s been like, “Oh, man. This has made my life so much easier as I’ve learned how to do software, and run things, and I wish I’d known that before”?

Barak Brudo: Well, I guess it’s something I’ve always known, it’s just something that… Well, a lot of people know this. Documentation is key.

Mandi Walls: Yes!

Barak Brudo: The problem with documentation, and that is me speaking both as a developer and as somebody who is now in charge of writing it, is that a lot of documentation is written with a really odd end user in mind. That end user or theoretical end user has huge gaps in information. Some things he knows so well that you don’t even need to mention them because they’re so obvious. And some things he knows absolutely nothing about, so you have to explain it from scratch. And those weird gaps means that going through documentation is often, could be unless it’s written extremely well, a grueling process.

Mandi Walls: Yeah.

Barak Brudo: Over the years, I think that the trend is improving a little bit as more and more people whose job it is to focus solely on documentation are getting into this, and they’re writing it properly, and in both an interesting, engaging way, that the information is properly divided. And if you’re looking for a specific piece of information, you don’t have to read three long pages of background, and concepts, and what this company does. I don’t care. I want to know what this command line does. I want to get to that command line, and I don’t want to have to read the whole thing just to find it. So yeah, when I write documentation, I’m really trying to make it both clear, engaging, and not too cluttered with information. Obviously, you need all the clutter. At some point, you need everything. You need to have a full documentation of all the possible flags that a command or library is able to achieve. But there’s a difference between including the whole thing, just, “Here it is. Here’s everything. Go find it,” and writing a different document that explain things clearly. Like, “Here’s where you start. You just need this line. Ignore everything else. This line will give you the basic. Once you get the basic, if you want to add flags, here, you can start with this flag. Just this one. Then you could maybe add this one. Everything good so far? Okay. Now, we can explain the other concept and maybe show you a few more flags.” You don’t need to give them a hundred flags and say, “Figure it out yourself.”

Mandi Walls: Yeah.

Barak Brudo: So yeah, documentation, and the obtusity of most of it is a real pet peeve of mine.

Mandi Walls: Yeah, I totally understand that. I often find products that I’m like, “Well, you know? I don’t need your company history and all of [inaudible 00:29:11]…” It’s like reading recipe websites, and you have to-

Barak Brudo: Yeah.

Mandi Walls: … read your entire life history before you get to, “Add this much olive oil.” Yeah, just give me the good bits, man. Give me the good bits.

Barak Brudo: In an easy to search-

Mandi Walls: Yes!

Barak Brudo: … indexed document.

Mandi Walls: Indexed. Indexed, yes. Indexes. That’s another. Yeah, we could go all day on all that for sure. Well, so that’s great. We’re the end of our time. Is there anything else that you’d like to leave folks with? We’ll have some links in the documentation, or in the show notes for some of the things that we’ve talked about so folks can follow up if they’re new to all these concepts. Is there anything that you’d like to leave folks with?

Barak Brudo: Well, we talked about pressure from regulation and government to include SBOMs in everything. But I feel like if we can add pressure from consumers-

Mandi Walls: Mm-hmm.

Barak Brudo: … it would definitely increase the pace at the very least. So if you are buying software, even if you’re a big company and you buy software or want to incorporate software, be it open source or something from a big reseller or vendor, doesn’t matter, ask for an SBOM. At some point, they might say, “Fine,” and give you a little bit. At some point, they might say, “No, we’re not giving you.” But the more people ask, the more likely it is that at some point, it will happen. So if you don’t ask, you won’t get it ever. So I think that asking for it is a good first step. And again, if you don’t remember anything from the rest of this talk, remember the acronym SBOM. Look it up, read up on it. It’s useful. It’s I think it will make everybody’s lives, both in security and elsewhere, easier. So I really hope that we’ll see as much adoption as soon as possible.

Mandi Walls: That’s great. Yeah. I hope so, too. Like it makes me feel better that there are folks out there thinking about this, especially after some of these vulnerabilities have come to light. Well, this has been great. There’s a lot of information here. I hope everybody out there learns something. And like I said, there’ll be links in the show notes where you can read up on some of these other components and standards. And in the meantime, we’ll wish everyone out there an uneventful day. That does it for another installment of Page It to the Limit. We’d like to thank our sponsor, PagerDuty, for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes at pageittothelimit.com, and you can reach us on Twitter @pageit2thelimit using the number two. Thank you so much for joining us. And remember, uneventful days are beautiful days.