My book, which I’ve been working on for three years, is now available on Amazon, both in the US and internationally; it is also available with some other international distributors. The Kindle version costs $9.99 while the paperback version costs $25.00 (the content is the same in both versions)[i]. Since the paperback version is printed on demand at the Amazon printing facility closest to you, it is always "in stock" and will be shipped by the next day.
SBOM (Software Bill of Materials) and VEX (Vulnerability Exploitability eXchange) are machine-readable documents that allow organizations that use software (i.e., just about every organization on the planet) to learn about the most important source of risk in the software they use: the third-party components that make up about 90 percent of the code in most software products in use today.
Why is it important to learn about third-party components? Even though your organization may be satisfied that your software suppliers follow secure development practices in writing their own code, that code only accounts for about 10 percent of the product. To learn about vulnerabilities (and other risks) in the other 90 percent of the product, you need to have current SBOM and VEX documents.
However, this is where the problem comes in: Software suppliers are already producing SBOMs in large volume to manage vulnerabilities in products they’re developing, but very few suppliers provide an updated SBOM to their customers with each new version of their product (this is essential. You'll learn why by reading the book).
Is this because the suppliers are trying to hide problems in the components? That may be true for a small number of them, but most suppliers I’ve talked to say the reason why they’re not providing SBOMs to their customers is that the customers aren’t asking for them. Meanwhile, the customers aren’t asking for SBOMs because, among other reasons, they don’t have low cost, commercially supported tools or services to utilize them.
How can we break this logjam, so that software users will be able to learn about risks in the software they use and work with their suppliers to reduce these risks? That’s the primary concern of this book. While there’s no magic fix for the problems, a workable fix for the most important use case - daily tracking of exploitable component vulnerabilities in software used by the organization - will likely be testable by the second half of 2024. The book closes with a discussion of the OWASP SBOM Forum's idea (perhaps "plan" is too strong a word at this point) to start testing this in a large proof of concept this year.
In writing the book, I kept in mind that, while some readers might already be familiar with every concept discussed in the book, others may have no more than a basic understanding of software security. Rather than focus on one audience or the other, I've identified chapters that the latter folks can safely skip (i.e., without losing the general thread of the book), with the word "Advanced" in the chapter title. You can always return later to review those chapters. See "How to 'shorten' this book" in the Preface.
I hope you’ll read the book and leave your comments on the Amazon page or LinkedIn. I’d also appreciate hearing your comments myself, whether good or bad (believe it or not, I like the bad comments as much as the good ones, as long as they point to something I can change). Just drop me an email at tom@tomalrich.com.
Note: You don’t have to own a Kindle device to read the Kindle version of this book. You can download the free Kindle viewer for iOS, Android, Mac or PC here.
[i] The price will appear in your local currency in most cases. In some currencies, like Indian Rupees, the local price is lower than the US price, in US dollar terms.
No comments:
Post a Comment