Microsoft open sources Salus software bill of materials (SBOM) generation tool | Hacker News Reader

Microsoft open sources Salus software bill of materials (SBOM) generation tool

devblogs.microsoft.com

181 pointsgjvc31 comments

> Do HN got a recommendation for other CLI based SBOM generators?

Try ORT https://github.com/oss-review-toolkit/ort (full disclosure I am one of its maintainers and also the lead of the SPDX Defects/Security Profile).

If people have questions on SBOMs, comparing SCA/SBOM tools or ORT - feel free to reach out to me https://github.com/tsteenbe/

ORT plug below ;-)

ORT is much more than a SBOM generator though, it's a cli/library that enables you to safely use, integrate, modify and redistribute third party software including FOSS.

You can use ORT to:

1. Generate CycloneDX or SPDX SBOMs for your software project

2. Automate your FOSS policy using Policy as Code to do licensing, security vulnerabilities and engineering standards checks for your software project and its dependencies

3. Correct found invalid or missing package metadata (licensing, source location, etc.) and license findings in the sources of your software project and its dependencies

4. Overwrite scanner license findings in the sources of your software project and its dependencies

5. Mark files, directories or or package manager scopes as not included in your software project or dependency released artifacts - use it to make clear that license findings in build scripts, documentation or tests in a package sources do not apply to the release (binary) artifact

6. Create a source code archive for your software project, including its dependencies to comply with certain license or have your own copy as nothing on the internet is forever

ORT is being built by Open Source Program Offices from Bosch, EPAM, HERE and others for several years who got frustrated with the state of SCA/SBOM tools not being able to support license compliance properly and the 30+ build tools you can find in a lot of large organizations.

To get started with ORT on your local machine I recommend using https://github.com/oss-review-toolkit/orthw/.

This looks very interesting, there is definitely need for SBOM generators that can handle multiple languages.

Do HN got a recommendation for other CLI based SBOM generators?

Dependency Track is too resource intensive for a small scale company, I just need a simple CLI based SBOM generator that can handle C++ (conan), Python and Go.

The one I have used is https://github.com/anchore/syft

Debian is my SBOM.

100% of your deps are Debian packages?

Yep, if they aren't then we add them to Debian. For those who aren't yet Debian members, you can do something similar but publish to your own repo instead.

What language are you programming in? Just thinking about how this would work if you are using say React.

Lots of different ones, Perl, Python, C, C++ being the main ones. I think there is JavaScript but I don't work on those parts. Looks like node-react is available in Debian now.

https://packages.debian.org/sid/node-react

Alright, cool. It's a bit confusing to me to create a dependency from your programming language dependency system to the operating system. But whatever works for you.

Wouldn't it be tedious to repackage libraries in Debian format? Why not use cpan or similar directly? Or a local artifact server already supporting existing package formats.

Dependencies across different language ecosystems exist (for eg Python stuff often depends on JavaScript stuff for documentation, or C libraries for faster machine code), it is convenient to encode them all in one package manager format. Repackaging ecosystem libraries is pretty much automated these days but still exposes you to the internals of each library since you need to do QA on everything to get it up to Debian standards first. Once things are in Debian you get an entire community of QA too, checking for new build failures due to changes in other packages, notifying you of new security issues etc.

https://wiki.debian.org/AutomaticPackagingTools

I guess I understand it's basically an inventory? Maybe someone could chime in with what teams are expected to do with an SBOM. Do you do something with the output, or is it just an audit checkbox?

The idea is that users of software or products containing software can understand the components in it and make informed decisions on what to do.

The classic example is an MRI machine at a hospital. You hear about a bug in the Java Spring library that must be patched asap. You need to do a complete inventory of everything in the hospital running software to decide if it is vulnerable or not.

When you get to the MRI machine: what OS does it run? Is it using Java and the affected component? Is the component an affected version?

Asking the manufacturer for everything for every security vulnerability is not scalable and may not result in accurate answers. By giving the consumer more info they are more empowered to act and make intelligent decesions.

Oh, so it's a security lookup tool, and I imagine you'd want a web and search interface on top of it.

I've seen a project https://backstage.io/ of which one if its features does something similar to what you're describing.

It's not really a security tool per-se, in that it isn't designed exclusively for security use. Its purpose is to concisely and completely communicate what software components make up a project/system. You can use that information for security/licensing/regulation compliance/etc.

There is an open source UI for querying based on SBOM called DependencyTrack (https://dependencytrack.org/). Commercial offerings exist from vendors like TideLift (https://tidelift.com/).

I'm confused. When would I need "https://dependencytrack.org/"? Is it when I've completely lost my marbles and can no longer answer the questions "what does your app run on" and "what are your app's dependencies"? Is the idea that I would then download and install this "dependency tracker", hoping it would give me a list of things I depend on, so that I could inform the end user? What's the use case?

It's less about first-party software and more for third-party off-the-shelf stuff you might run. For first-party stuff SBOMs can definitely feel useless.

The idea is you feed a tool like that all of your SBOMs, and all of the SBOMs from your vendors. Then it'll tell you "these four widgets in your hospital are vulnerable to a newly discovered vulnerability called 'Log4Shell', they need to upgrade Log4j to version 2.17.0"

There's a cottage industry forming to do this sort of thing, mostly in the medical field, but it'll probably spread out.

It's for the end user who purchases a lot of things which include software components to understand the total set of software they're running and be able to ask questions about licensing, vulnerabilities, and establish policies.

A developer (or even administrator of a single computer system) is not the user of something like this, typically.

Here's an example:

A small manufacturing business may have a dozen different machines. Each one has a set of software to control it, running on a computer embedded in the machine. The business also has a website (developed by a contractor), a bunch of software packages purchased from different vendors for accounting, inventory, payroll and scheduling. They probably have some internal home-grown tools too.

1. A new remotely exploitable CVE is announced in a widely-used open source library. Is the company vulnerable to it? Anywhere?

If each one of the pieces of software was delivered with a SBOM along with the actual code, you can use tools like this to look at this globally. It starts to make more sense at the scale of "all the software in the business" is provided by tens to hundreds of different vendors or teams that not only don't communicate with each other but also don't even know that the others exist.

Is lying about your dependencies unheard of, in this scenario?

Before the government SBOM standard that kicked all this off was finalized, I'd asked about this and related items such as reproducible builds. The response I got is that getting honest information out of vendors would be a huge step forward for end customers. Being able to validate that information would require a lot more work. Things like SLSA levels 3+4 (https://slsa.dev/spec/v0.1/levels) go further to prevent lying, at least in situations where all the code can be compiled by third parties.

How does a “small manufacturing business” get notified of this CVE popping up? I don’t think they would even know what a CVE is…

They could sign up for a CTI (Cyber Threat Intelligence) service with a security company. Basically, they send you notifications about CVEs and related stuff.

My client isn't exactly a "small manufacturing business", but they do subscribe to such a service, and they did have the Java issue in a parent process. They have a security guy who's the main one expected to look at these, but he's not the one operating anything directly, so he can't be expected to know every last random lib that's used.

So when the Log4j2 issue came up, for example, he was aware there was "a Java issue" but had no automated way of knowing which systems, if any, were affected.

It's probably a good plan to take a look at the US executive order that spawned this move by MS https://www.whitehouse.gov/briefing-room/presidential-action...

> the term “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.

Just to expand on this a bit: One of the largest fallouts from the Log4Shell vulnerability was that companies realized how hard it was to identify where they had log4j in their infrastructure in the first place.

I've spoken with dozens of companies and it was a very similar story: Writing a detection script and then SSH'ing into every box, applying a Helm chart to scan every running container, putting the script into every CI job... Which takes weeks to months of manual effort to deal with.

And that's not even dealing with the "once you found it, who goes in and patches it?" Which is it's own can of worms.

For context: I helped deal with the fallout of Log4Shell by writing a blog post about it (I gave it that name). Since then, we've been working on an Open Source SBOM database called LunaTrace[0] to help fix what I wrote above.

0: https://github.com/lunasec-io/lunasec/tree/master/lunatrace

Some places require sign-off by legal for every (transitive) dependency. Less draconically, you really ought to have that list so you can check whether you're exposed to any licensing obligations that you don't want and if you are meeting other license terms (e.g. attribution). If the list is hard to create, that's a strong hint you don't know what code you're actually running.

I definitely see the value in having a big list of deps. Just to have an ideal of what’s going stale. Especially in repos with multiple languages.

This is nearly beside the point, but why include SHA-1 as a default hash algorihtm in a greenfield project?

It's not exactly green-field: SPDX is over ten years old now, and browsers only started removing SHA-1 in the last five years.

As other commenters have said, it’s not greenfield, but is there a valid attack vector on a collision here?

https://github.com/anchore/syft is an easier to use alternative. Just point it at a container image, path or archive and it will generate the SBOM for you.

Salus seems to be more flexible - you can also feed the sources and the package manager files into it. I guess the results could be more accurate.

Reply on news.ycombinator.com