Self-Service SBOMs

I actually found that callout quite useful. I've often had to send SBOMs to lawyers, auditors etc. and typically in Excel.

Isn’t that saying the opposite of what you’re concerned about? It sounds like Microsoft has added support to Excel for the industry-standard format SPDX files which many tools, including GitHub, generate but is acknowledging that Google has not yet done so. Since both tools are proprietary I’d much prefer that they use standard formats like SPDX. SBOMs are the kind of thing large organizations ask for - note the U.S. executive order linked – and that means lots of non-technical people are going to be exposed to them.

You know that Microsoft would love this outcome and will gladly use the need for regulatory compliance as a mechanism to push for it.

As much as that's always a possibility, there's so much competition in this space that Github is just entering into that I don't see it happening anytime soon. The angle for Microsoft here is they're probably going to charge enterprise GH customers a severe premium to avail of this - it will only be freely available to users who aren't the primary target audience.

They note that you can upload SBOMs to GitHub, which makes sense given how many places have their own build infrastructure and may not be able or comfortable posting all of their dependencies.

Could you describe its defects in more detail?

What does "understand dependencies" mean to you? What kinds of things would help you understand dependencies better?

It's a step (and I guess for many, a coping strategy).

Getting a BOM about people you don't know/trust lets you know who you don't know/trust: known unknowns. At the very least it present a quantifiable risk profile that you can use to push for disengaging from untrusted dependencies. At best, it's a stepping stone to start building relationships.

The first step in solving the trust problem is solving the identity problem. At the very least, once you've got cryptographic identities for entities involved in your supply chain, you can use a TOFU policy and check whenever an identity changes.

Simple operations like rotating a key shouldn't trigger any security warnings, as long as they new key is signed by the old one, and even adding new people to a team should happen seamlessly if (a majority of) the existing team members approve that new identity being added.

Of course it doesn't solve key compromise, or someone selling their keys to someone else, but with long-lived (even pseudonymous) identities, it becomes possible to reason about the trust level of packages just based on how long an identity has been used without being compromised.

No system is perfect, and there's still a long way to go, but the existing systems make the remaining problems more tractable, and already increase the cost for attackers, which should reduce attacks.

This is targeted at public sector and other enterprise customers. It doesn't need to actually solve the problem. It just needs to clear the hurdle of giving the people who work at these companies a way to look like they got something done. Bonus points when it does so in terms (like "bill of materials") that they're already familiar with.

Would you rather have a receipt for something you buy or to take someone's word on it if anything goes wrong?

One useful thing you can do with an SBOM is quickly check whether your dependencies carry any known vulnerabilities. That kind of thing can be harder than you'd think to track, especially across large organizations with many projects.

Or maybe you do trust it, but you want to verify. Centrally collected SBOMs are useful to match against CVE’s and other vulnerability sources to quickly identify affected codebases.

I admit I don't know a lot about these systems, but aren't they trying to solve a different problem? Aren't they trying to solve visibility?

Once you know a vulnerability exists in a particular version of a particular piece of software, you need a way to go from there, through dependencies, to builds, and then to deployments. You can't push fixes to all the right places without knowing what those places are.

In other words, you need to correctly and completely answer questions like, "Oh, CVE-YYYY-NNNNN was just announced. What's the list of every binary on every machine of every platform we have in every environment (production, corporate network, employee cell phones) that needs a fix?"

You can do it manually, but that's basically asking for failure because you'll miss things. Also it's tedious.

I assume it's in comparison to on-prem repositories that are available through the Github Enterprise product.

That is the "Light High Contrast" theme that you can set on GitHub under Settings -> Appearance.

> scanning source code: it will generate also lot of false positive and a need to manually edit (ammend/correct) the SBOM

Can you give any examples of this? I’ve never seen a tool like this report a true-false positive but based on your mention of embedded tools I’m guessing you might be referring to something like a build dependency which is completely optimized out such as a debugging feature on a production build? In such cases I would be inclined to either prepare separate SBOMs or otherwise indicate when something is present but not reachable. My concern about editing the files is that these are intended in a somewhat legalistic context and if something blew up it’s not hard to imagine someone’s lawyer using those changes to argue that you were aware of a problem and tried to cover it up. Even if you could defend your policy, that’s not a conversation anyone wants to have.

There are actually more "types" of SBOMs than the two you mention. I don't think CISA has published the corresponding table yet, but depending on the point in the software lifecycle that you are, you can create "Design", "Source", "Build", "Deploy", or "Analysis" SBOMs -- and they are all for different use cases,