SBOM all the things

[davelab6]

There was a USA Cybersecurity Executive Order issued in 2021 that requires each software package supplied to the USA federal government to have a "Software Bill Of Materials" (SBOM):

(j) 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.

In order to enable the maximum distribution of libre fonts, I'd like to include a SBOM for each font family in the Google Fonts collection, with provenance and production details and signed with COSE Sign1; I wonder if we can finally make use of the DSIG table for real.

I'm assigning @simoncozens to start, and suggest to start with Noto CJK since that is one of the more difficult situations, since we don't build it ourselves, and its probably the most valuable font project we operate; and then integrate this into builder2 and the repo template.

[PeterConstable]

FYI: https://www.cisa.gov/sites/default/files/2024-07/SBOM%20FAQ%202024.pdf.

FWIW, Microsoft has adopted the Linux Foundation’s SPDX standard (ISO/IEC 5962) for SBOMs.

[simoncozens]

This may turn out to be quite easy...

[PeterConstable]

Nice find. But is that at the appropriate granularity? That seems to export one SBOM encompassing an entire repo.

[simoncozens]

Most of the GF font projects are one font per repo, so yes, that will work in most cases. I'll do something custom for Noto CJK because of the supplier/originator split.

[davelab6]

Simon noted offline,

DSIG is specified to use a PKCS#7 signature, and it is specified to be a signed hash of the font binary. It doesn't help us for SBOMing.

[anthrotype]

sorry if my question sounds stupid but.. I'm trying to wrap my head around how exactly such a "SBOM" may help the users of a font file with determining "whether they are at potential risk of a newly discovered vulnerability"? A font is not like an application that may be assembled from a bunch of existing software components. Yes, we use various applications in turn made up of various components to build font files, but these do not become part of the actual font, do they? It's more like "this app was compiled with Xcode 15.4" -- is that all this is about? What risks are we talking about exactly? Why would knowing details of its "supply chain" mitigate security or compliance risks? These are genuine questions.

[hepwori]

@anthrotype one short answer is that although much of the industry's focus today is on SBOMs as enablers of automated vulnerability management across complex software supply chains, there are a bunch of other uses. This NTIA document is a decent round-up of many of them.

I definitely agree that font files are on the very edges of SBOM applicability (and arguably outside those edges in today's common SBOM discourse), but having metadata describing the lineage of binary files in a software distribution is a generally useful capability for operability of the distribution.

[PeterConstable]

Wrt DSIG, for Microsoft’s purposes, I’m still getting clarification from our SDL experts as to whether DSIG will meet MS’s requirements in relation to the current security goals, but it’s sounding like probably not.

[PeterConstable]

Most of the GF font projects are one font per repo

Can you point me at one such repo. I'd like to export the sbom and confirm with Microsoft's SDL people whether that meets their current requirements.

[davelab6]

https://github.com/googlefonts/science-gothic was updated recently

https://github.com/JulietaUla/Montserrat/ has often been used as a reference