22,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Discover the new cybersecurity landscape of the interconnected software supply chain In Software Transparency: Supply Chain Security in an Era of a Software-Driven Society, a team of veteran information security professionals delivers an expert treatment of software supply chain security. In the book, you'll explore real-world examples and guidance on how to defend your own organization against internal and external attacks. It includes coverage of topics including the history of the software transparency movement, software bills of materials, and high assurance attestations. The authors examine the background of attack vectors that are becoming increasingly vulnerable, like mobile and social networks, retail and banking systems, and infrastructure and defense systems. You'll also discover: * Use cases and practical guidance for both software consumers and suppliers * Discussions of firmware and embedded software, as well as cloud and connected APIs * Strategies for understanding federal and defense software supply chain initiatives related to security An essential resource for cybersecurity and application security professionals, Software Transparency will also be of extraordinary benefit to industrial control system, cloud, and mobile security professionals.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 561
Veröffentlichungsjahr: 2023
Ähnliche
Table of Contents
Cover
Title Page
Foreword
Introduction
What Does This Book Cover?
Who Will Benefit Most from This Book?
Special Features
CHAPTER 1: Background on Software Supply Chain Threats
Incentives for the Attacker
Threat Models
Landmark Case 1: SolarWinds
Landmark Case 2: Log4j
Landmark Case 3: Kaseya
What Can We Learn from These Cases?
Summary
CHAPTER 2: Existing Approaches—Traditional Vendor Risk Management
Assessments
SDL Assessments
Application Security Maturity Models
Application Security Assurance
Hashing and Code Signing
Summary
CHAPTER 3: Vulnerability Databases and Scoring Methodologies
Common Vulnerabilities and Exposures
National Vulnerability Database
Software Identity Formats
Sonatype OSS Index
Open Source Vulnerability Database
Global Security Database
Common Vulnerability Scoring System
Exploit Prediction Scoring System
EPSS Model
EPSS Critiques
CISA's Take
Moving Forward
Summary
CHAPTER 4: Rise of Software Bill of Materials
SBOM in Regulations: Failures and Successes
Industry Efforts: National Labs
SBOM Formats
Moving Forward
Using SBOM with Other Attestations
Summary
CHAPTER 5: Challenges in Software Transparency
Firmware and Embedded Software
Open Source Software and Proprietary Code
User Software
Legacy Software
Secure Transport
Summary
CHAPTER 6: Cloud and Containerization
Shared Responsibility Model
The 4 Cs of Cloud Native Security
Containers
Kubernetes
Serverless Model
SaaSBOM and the Complexity of APIs
Usage in DevOps and DevSecOps
Summary
CHAPTER 7: Existing and Emerging Commercial Guidance
Supply Chain Levels for Software Artifacts
Google Graph for Understanding Artifact Composition
CIS Software Supply Chain Security Guide
CNCF's Software Supply Chain Best Practices
CNCF's Secure Software Factory Reference Architecture
Microsoft's Secure Supply Chain Consumption Framework
S2C2F Practices
S2C2F Implementation Guide
OWASP Software Component Verification Standard
OpenSSF Scorecard
The Path Ahead
Summary
CHAPTER 8: Existing and Emerging Government Guidance
Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
Software Verification
NIST's Secure Software Development Framework
NSAs: Securing the Software Supply Chain Guidance Series
NSA Appendices
Recommended Practices Guide for Suppliers
Recommended Practices Guide for Customers
Summary
CHAPTER 9: Software Transparency in Operational Technology
The Kinetic Effect of Software
Legacy Software Risks
Ladder Logic and Setpoints in Control Systems
ICS Attack Surface
Smart Grid
Summary
CHAPTER 10: Practical Guidance for Suppliers
Vulnerability Disclosure and Response PSIRT
Product Security Incident Response Team (PSIRT)
To Share or Not to Share and How Much Is Too Much?
Copyleft, Licensing Concerns, and “As-Is” Code
Open Source Program Offices
Consistency Across Product Teams
Manual Effort vs. Automation and Accuracy
Summary
CHAPTER 11: Practical Guidance for Consumers
Thinking Broad and Deep
Do I Really Need an SBOM?
What Do I Do with It?
Receiving and Managing SBOMs at Scale
Reducing the Noise
The Divergent Workflow—I Can't Just Apply a Patch?
Summary
CHAPTER 12: Software Transparency Predictions
Emerging Efforts, Regulations, and Requirements
The Power of the U.S. Government Supply Chains to Affect Markets
Acceleration of Supply Chain Attacks
The Increasing Connectedness of Our Digital World
What Comes Next?
Index
Copyright
Dedication
About the Authors
About the Technical Editor
Acknowledgments
End User License Agreement
List of Tables
Chapter 4
Table 4.1: The baseline collection of data fields
Table 4.2: Three SBOM formats
List of Illustrations
Chapter 1
Figure 1.1
Figure 1.2
Figure 1.3
Figure 1.4
Figure 1.5
Figure 1.6
Chapter 2
Figure 2.1
Chapter 3
Figure 3.1
Figure 3.2
Figure 3.3
Figure 3.4
Figure 3.6
Figure 3.7
Figure 3.8
Chapter 4
Figure 4.1
Figure 4.2
Chapter 6
Figure 6.1
Figure 6.2
Figure 6.3
Figure 6.4
Figure 6.5
Chapter 7
Figure 7.1
Figure 7.2
Figure 7.3
Figure 7.4
Figure 7.5
Figure 7.6
Figure 7.7
Figure 7.8
Figure 7.9
Figure 7.10
Figure 7.11
Figure 7.12
Figure 7.13
Chapter 8
Figure 8.1
Figure 8.2
Figure 8.3
Figure 8.4
Figure 8.5
Figure 8.6
Figure 8.7
Figure 8.8
Chapter 9
Figure 9.1
Chapter 10
Figure 10.1
Figure 10.2
Figure 10.3
Chapter 12
Figure 12.1
Figure 12.2
Figure 12.3
Figure 12.4
Guide
Cover
Table of Contents
Title Page
Copyright
Dedication
About the Authors
About the Technical Editor
Acknowledgments
Foreword
Introduction
Begin Reading
Index
End User License Agreement
Pages
iii
xxi
xxii
xxiii
xxiv
xxv
xxvi
xxvii
xxviii
xxix
xxx
xxxi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
283
284
285
286
287
288
289
290
291
292
293
294
295
iv
v
vii
viii
ix
xi
296
Software Transparency
Supply Chain Security in an Era of a Software-Driven Society
Chris Hughes
Tony Turner
Foreword
Many of us will remember December 2021 as a time spent hunched over small travel laptops in relatives' guest rooms, dealing with the Log4j crisis. That vulnerability in an open source Java-logging framework developed by The Apache Software Foundation was scored as severe by both official metrics and software experts. It was not the hardest vulnerability to address, either through patches or other inline mitigations. Yet, the real challenge most organizations faced was location: Where is this darn thing? Buried deep in countless modern applications' supply chains, both producers and users of software simply didn't have a usable roadmap of where to focus.
The hard part of security should be in identifying vulnerabilities and discovering attackers sneaking into our supply chains. Instead, we've discovered that understanding what's in the software we make has required a nontrivial amount of work.
The idea of tracking what goes into software isn't new. Academics have been talking about it since the 1990s. Early idea discussions were happening in disparate corners of the software world in the 2000s. Failure to account for the open source licenses got a number of large companies into serious legal trouble. Collecting and leveraging supplier data formed an integral part of the revolution in heavy industry quality that dates back to the late 1940s, with the Deming and the “Toyota revolution” that inspired the DevSecOps and modern software revolution decades later.
Indeed, it's quite remarkable that we don't have better transparency in our software supply chains. I often use the example of a Twinkie (first advanced by Audra Hatch and Josh Corman) to raise the question of why we have a better understanding of what is in a nonbiodegradable snack than what is in the software that runs in our companies, governments, and critical infrastructure.
As we embark on our journey to understand how to implement software bill of materials (SBOMs), it's useful to take a moment to understand why we didn't have this capacity at the beginning, how we're beginning to make progress, and what the value of this transparency is. There are some less-flattering reasons why few organizations wanted to share, including not wanting to be exposed to the previously mentioned open source license compliance risks. Frankly, many organizations did not want to admit to the scale of technical debt or incur the costs of having to set up the basic internal infrastructure and processes to track their dependency data. Moreover, it should be acknowledged that starting this SBOM journey hasn't been easy—it has required bringing together technical expertise, an understanding of the diverse software ecosystem, and an appreciation of incentives. But a massive amount of progress has been made in the last five years.
The first thing we needed was a shared vision of what an SBOM is. Many experts had a general idea; these were debated and refined from 2018 to 2020 in the open, international, “multistakeholder process” that the National Telecommunications and Information Administration (NTIA) convened. The community defined the basics of an SBOM and laid out its core use cases. We then needed a machine-readable means to convey this information across the supply chain. Fortunately, some across the software world were ahead of us, so we were able to align the Linux Foundation's Software Package Data Exchange (SPDX) and Open Worldwide Application Security Project's (OWASP's) CycloneDX to meet these models.
The next step was creating tools to generate and use this machine-readable data. Great progress has been made across the software world in implementing SBOM generally, with new tools emerging across the ecosystem. We're seeing more sector- and technology-specific tools, because the needs of the industrial control systems (ICSs) and operational technology (OT) firmware world are somewhat different from traditional enterprise software, which, in turn, have unique features and integrations compared to the cloud-native world. Generation tools have begun to mature and new tools emerge all the time to help organizations use this data, both operationally and strategically. (It's been one of the perks of my job, first at the NTIA and now at the Cybersecurity and Infrastructure Security Administration [CISA], to meet with start-ups and open source innovators to find ways to meet real needs across the software marketplace.)
Of course, the third leg of the tripod, along with technology and markets, is government. The U.S. government has focused on securing the supply chain in recent years, but there has been strong interest as well as policy innovations by our partners around the world. SBOMs moved to the main stage of cybersecurity policy in May 2021, when the President's Executive Order (EO) on Improving the Nation's Cybersecurity declared, among other things, that suppliers to the U.S. government will provide the purchaser with an SBOM. As this book goes to press, the final details of those regulations are expected. This goes along with regulations of medical devices in the United States by the Food and Drug Administration (FDA), activity from other U.S. regulators, and proposed regulations emerging around the world.
Because you have this book in your hands or on your screen, you probably don't need to be convinced of the value of transparency across the software supply chain. But you may have to convince others, evangelize across your organization or corner of the software ecosystem, argue for a budget, or convince your suppliers to share data. Despite the usual infosec vendors' hyperbole, the “SB” in SBOM doesn't stand for “silver bullet.” SBOM is a data layer. We are still building the tools and processes to the turn that data into intelligence and, ultimately, into action. Just like a Common Vulnerabilities and Exposures (CVE) identifier doesn't actually fix a vulnerability on your network—and CVEs are now an indispensable part of our global vulnerability ecosystem—so, too, will SBOMs become an integral part of the software security and quality world.
Transparency in the software supply chain aids across the life cycle of software. For those of us who build software, SBOMs are a powerful tool to understand our processes and to ensure that we're not building things that are not secure-by-design or shipping with known risks. For those of us who choose or buy software, why would we use a supplier who doesn't understand what they are delivering? Why would we potentially adopt software that was outdated before its use? For those of us who operate software, without an SBOM, how can we respond to newly identified risks or make plans for systems that are built on end-of-life or end-of-support software? Of course, many of us occupy all three roles. It seems inevitable that more uses of this data will be identified and built as SBOMs become more ubiquitous.
There have been a lot of incredible contributions to the software transparency movement, championing the idea of SBOMs, building tools, and debating vital edge cases. Authors Hughes and Turner do a great job of capturing these advances—including some of their own—and explaining the details and nuances as we go from the idea of SBOM to the practice of SBOM. While I expect practitioners around the world to pick up and use this volume to incredible success for their organizations and their customers, it is my paradoxical wish that this book's critical value is actually short-lived. As more of us start to build and manage our software with the types of interoperable automation the authors so helpfully envision and follow the course they lay out, SBOMs will cease to be new and shiny and become a natural, automated part of how all software is made, sold, and used.
It's then we can turn to the next challenge.
Dr. Allan Friedman
Allan Friedman is Senior Advisor and Strategist at the Cybersecurity and Infrastructure Security Agency. He coordinates the global cross-sector community efforts around software bill of materials (SBOM). He was previously the Director of Cybersecurity Initiatives at NTIA, leading pioneering work on vulnerability disclosure, SBOM, and other security topics. Prior to joining the federal government, Friedman spent over a decade as a noted information security and technology policy scholar at Harvard's Computer Science department, the Brookings Institution, and George Washington University's Engineering School. He is the co-author of the popular text Cybersecurity and Cyberwar: What Everyone Needs to Know, has a C.S. degree from Swarthmore College and a PhD from Harvard University.
Introduction
We are living in a time where software touches every aspect of our society. Software is involved in everything from critical infrastructure, digital commerce, and national security. In fact, as of this writing, the World Economic Forum (WEF) predicts that by the end of 2022, 60 percent of global gross domestic product (GDP) will be tied to digital systems (www3.weforum.org/docs/WEF_Responsible_Digital_Transformation.pdf). However, that same WEF report found that only 45 percent of people trust the technology that powers our modern economies and society. Part of that lack of trust can be traced to many years of notable digital data breaches and a long-standing issue with transparency when it comes to the software supply chain.
Software supply chain attacks are far from a new phenomenon, and concerns about trusting code have origins dating back to Ken Thompson's famous “Reflections on Trusting Trust” paper in 1984, where Thompson discussed the inability to trust code you did not create yourself. While the idea that code consumed from external sources could be untrustworthy or downright malicious, the manifestations of that statement have only been exacerbated in recent years as software supply chain attacks accelerate. Malicious actors, driven by a variety of motives, have realized that rather than targeting a single entity, they can compromise widely used software (whether proprietary or open source) and have a cascading impact across an entire ecosystem of consumers.
As these incidents have accelerated, organizations have increased their efforts to both understand software supply chain challenges, complexities, and incidents, and have implemented security measures to mitigate their associated risks. The Cloud Native Computing Foundation (CNCF) has compiled a catalog (http://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises) of supply chain compromises dating back to 2003. This catalog captures supply chain compromises from a variety of methods, such as exploited developer tooling, developer negligence, malicious maintainers, or even attack chaining (i.e., several compromises chained together to enable an attack).
Before some of the landmark cases discussed in this text, such as SolarWinds, Log4j, and others, the Office of the Director of National Intelligence (ODNI) published a paper (http://dni.gov/files/NCSC/documents/supplychain/20190327-Software-Supply-Chain-Attacks02.pdf) in 2017, calling it a watershed year for software supply chain attacks. The document laid out several significant software supply chain attacks in 2017, which impacted organizations supporting the U.S. government in addition to commercial leaders, several of which originated from nation-state actors. The ODNI paper points out that many software development and distribution channels lack proper security. ODNI also described some malicious actors going upstream due to better cyber hygiene among some organizations. It is often more efficient for malicious actors to go upstream and compromise downstream software consumers at scale, rather than targeting one individual organization. Some software supply chain attacks may be indiscriminate, targeting any consumers, while others may seek out specific upstream software producers knowing who some of their downstream consumers are.
There is no denying that digitally enabled systems have led to unprecedented efficiency, productivity, and innovation. That said, these same digitally connected software-empowered systems have now created levels of systemic risk that are only beginning to be fully understood. It is said that complex interdependencies can heighten systemic risk, and it would be hard to argue that the current state of the software ecosystem and modern digital systems are anything but complex. Malicious actors are realizing the value of targeting the software supply chain as well, with Gartner, an industry leader in technology research, predicting that by 2025, some 45 percent of organizations will experience a software supply chain attack. Some argue that estimate may be low, with organizations such as Sonatype producing a 2022 report (http://sonatype.com/state-of-the-software-supply-chain/introduction) showing a 742 percent annual increase in software supply chain attacks over the past three years.
As notable software supply chain attacks have increased, we have now seen ambitious efforts on behalf of governments as well as private sector organizations. In the United States, the White House issued Executive Order 14028, “Improving the Nation's Cybersecurity” (http://whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity), which has a section dedicated to enhancing software supply chain security. This order includes a section about a common lack of transparency as it relates to software being consumed by organizations, including the federal government.
In this book, we will discuss in more detail relevant software supply chain incidents, industry activities, emerging solutions, as well as the significant challenges that remain when it comes to securing the software supply chain.
Why Is This Critical?
Before we dive into the specifics of software supply chain threats and emerging frameworks and guidance, we should initially discuss why this is such a critical issue that impacts every aspect of modern society. As mentioned previously, digital platforms are quickly on pace to touch over half of the global economic output. Powering those digital platforms and systems is software, much of which is open source software (OSS) components. OSS use is ubiquitous across much of the modern software ecosystem. A recent study (http://synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2022.pdf) found that 97 percent of modern software codebases contain OSS, and not only do they contain OSS, but over half of the codebases are OSS.
OSS is now fundamentally integrated into some of society's most critical infrastructure and systems. Research has shown that over 90 percent of codebases for industries such as transportation, financial services, and manufacturing contain OSS. The same trends exist across industries such as telecommunications and health care as well. In the United States, the Department of Defense (DoD) released a memo titled “Software Development and Open Source Software” (http://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareDev-OpenSource.pdf). The memo, which is part of their broader Software Modernization Strategy (https://dodcio.defense.gov/portals/0/documents/library/softwaredev-opensource.pdf), calls OSS “the bedrock of the software-defined world and is critical in delivering software faster, resiliently, as is key to their software modernization efforts.” The Software Modernization Strategy states that “the ability to securely and rapidly deliver resilient software capability is a competitive advantage that will define future conflicts.”
Innovative use of software is not just critical for national security purposes, as emphasized by the DoD, but is pivotal for society at large. In a hearing as part of the U.S. House of Representatives Committee on Science, Space and Technology titled “Securing the Digital Commons: Improving the Health of the Open Source Software Ecosystem” (www.congress.gov/event/117th-congress/house-event/114727), several elected officials as well as industry experts testified to the importance of a resilient OSS ecosystem. Congressman Bill Foster called OSS the “hidden workforce of the digital ecosystem.” Congresswoman Haley Stevens stated that “a vibrant open-source ecosystem is an engine for U.S. competitiveness and growth.” In an Open Source Software Security Summit hosted by the White House in 2022, it was emphasized that most major software packages include OSS, including software that is used by the national security community (www.whitehouse.gov/briefing-room/statements-releases/2022/01/13/readout-of-white-house-meeting-on-software-security).
Many are beginning to make the case that OSS is such a vital aspect of society that it should be considered critical infrastructure as well, comparing it to interstate highways, power grids, water treatment, and other fundamental aspects of our society (http://hbr.org/2021/09/the-digital-economy-runs-on-open-source-heres-how-to-protect-it). The argument also claims that designating OSS critical infrastructure would lead to additional resources, cross-sector coordination, public awareness, and dialogue.
Despite the ubiquity of OSS and its importance to national security, commercial industry, and society, it can be argued that its security concerns have been neglected. In an article titled “Open-Source Security: How Digital Infrastructure Is Built on a House of Cards” (http://lawfareblog.com/open-source-security-how-digital-infrastructure-built-house-cards), researcher Chinmayi Sharma makes the case that OSS and its associated vulnerabilities are pervasive across all critical infrastructure sectors and, due to a lack of resources and incentives, pose a systemic risk to society.
This lack of attention is not lost on malicious actors either, as some studies state we have seen software supply chain attacks experience as much as a 650 percent year-over-year (YoY) increase in 2021. This is not a unique phenomenon, with 2020 seeing an over 400 percent increase. These stark increases are also reflected in sources such as the Cloud Native Computing Foundation's (CNCF) Catalog of Supply Chain Compromises.
This uptick in software supply chain attacks is also supported by research from organizations such as the Atlantic Council, in their “Breaking Trust: Shades of Crisis Across an Insecure Software Supply Chain” white paper (http://atlanticcouncil.org/wp-content/uploads/2020/07/Breaking-trust-Shades-of-crisis-across-an-insecure-software-supply-chain.pdf). Their research shows a sharp increase in software supply chain attacks, with third-party applications among the primary attack vectors, along with OSS. The report documents more than 100 software supply chain attacks over the last decade, through a myriad of vectors such as hijacked updates, malicious dependencies, compromised software development platforms, and account compromises. This demonstrates not just the consistent and increasing use of software supply chain attacks by malicious actors, but also the diversity of attack vectors that malicious actors can use to compromise downstream software consumers due to the complexity of the modern software ecosystem. As demonstrated by the report, not only are these attacks impacting millions of users, but they are also quickly becoming a standardized method of nation-state conflict and engagement in the modern digital society. The attention from malicious nation-state actors was also emphasized by ODNI in its 2017 publication (http://dni.gov/files/NCSC/documents/supplychain/20190327-Software-Supply-Chain-Attacks02.pdf).
It is not just OSS components that are being targeted. Malicious actors are also targeting managed service providers (MSPs), cloud service providers (CSPs), and several other entities, all of which play various roles in the modern software ecosystem.
Malicious actors have realized the fruitfulness of targeting software supply chain components or suppliers and causing a massive downstream impact, which is more efficient than individually targeting the same number of victims. In this book, we will discuss everything from the background on software supply chain threats, notable incidents, emerging guidance, technical capabilities, and best practices, as well as where we are headed in the future.
What Does This Book Cover?
This book covers the topics relevant to the emerging discussion and challenges associated with software transparency and software supply chain security. This includes a detailed background on software supply chain threats, existing approaches, and the rise of innovative tools, technologies, and processes to address this exponentially relevant threat. Discussions will include the impact these threats have on nearly all aspects of society and practical guidance for various stakeholders on how to address these threats. It will cover emerging regulations and their impact, as well as predictions on where we as an industry and a society go from here moving forward.
Chapter 1
: Background on Software Supply Chain Threats
This chapter outlines core topics such as the incentives for attackers and the anatomy of a software supply chain attack as well as relevant landmark cases.
Chapter 2
: Existing Approaches—Traditional Vendor Risk Management
This chapter reviews existing approaches to software security, such as traditional vendor risk management, application security models, and methods such as hashing and code signing.
Chapter 3
: Vulnerability Databases and Scoring Methodologies
This chapter discusses existing and emerging vulnerability databases, as well as common methods used for scoring and prioritizing vulnerabilities in software and applications.
Chapter 4
: Rise of Software Bill of Materials
This chapter discusses the origins of the SBOM concept, including early failures and successes and the U.S. federal and industry organizations that have contributed to its maturity.
Chapter 5
: Challenges in Software Transparency
This chapter focuses on challenges related to software transparency, such as differences between open source and proprietary code as well as firmware and embedded software.
Chapter 6
: Cloud and Containerization
This chapter reviews the evolution of IT, including the cloud and containerization, as well as the complexity associated with software transparency in the realm of software-as-a-service (SaaS). The chapter also covers efforts associated with DevSecOps.
Chapter 7
: Existing and Emerging Commercial Guidance
This chapter discusses existing and emerging commercial guidance related to software transparency and software supply chain security from both public and private sector organizations.
Chapter 8
: Existing and Emerging Government Guidance
This chapter discusses existing and emerging government guidance related to software transparency and software supply chain security from the governmental sector.
Chapter 9
: Software Transparency in Operational Technology
This chapter discusses some of the unique aspects related to software transparency and operational technology (OT) as well as implications for broader software supply chain efforts.
Chapter 10
: Practical Guidance for Suppliers
This chapter focuses on practical guidance for software suppliers to help them meet emerging guidance and best practices and to facilitate their role in bolstering software supply chain security.
Chapter 11
: Practical Guidance for Consumers
This chapter features practical guidance for software consumers, including whether an SBOM is actually needed, what to do with it, and how to mature organizations' software supply chain risk management efforts.
Chapter 12
: Software Transparency Predictions
This chapter covers software transparency predictions moving forward, including emerging regulations and their impact on broader markets, promising emerging technologies, and where we go from here as an industry and a society.
Who Will Benefit Most from This Book?
This book will benefit various technology and cybersecurity professionals such as chief information security officers (CISOs), chief technology officers (CTOs), senior technology and security leaders, security engineers and architects, software developers, and open source software enthusiasts. It will also benefit acquisition professionals concerned with secure software acquisition and procurement and auditing professionals aiming to understand emerging software supply chain guidance and requirements. Researchers and policy makers interested in best practices and threats related to software and society will also benefit.
Special Features
DEFINITIONThroughout the book, we'll explain the meanings of terms that may be new or nonstandard in this special feature.
NOTEIn-line boxes are used to expand further on some aspect of the topic, without interrupting the flow of the narrative.
Small general discussions that deserve special emphasis or that have relevance beyond the immediately surrounding content are called out in general sidebar notes.
How to Contact the Authors
Chris Hughes can be contacted via email at [email protected] as well as via LinkedIn at http://linkedin.com/in/resilientcyber or on Twitter @ResilientCyber.
Tony Turner can be contacted via email at [email protected] as well as via LinkedIn at http://linkedin.com/in/tonyturnercissp or on Twitter at @tonylturner.
If you believe you have found a mistake in this book, please bring it to our attention. At John Wiley & Sons, we understand how important it is to provide our customers with accurate content, but even with our best efforts an error may occur.
In order to submit your possible errata, please email it to our Customer Service Team at [email protected] with the subject line “Possible Book Errata Submission.”
