Software Bill of Materials and the Vulnerability Exploitability eXchange

University of Oxford
GPT, NLP AND AI/ML IN
CYBER SOFTWARE
VULNERABILITY
SBOM / VEX

G E N E R A T I V E P R E -
T R A I N E D T R A N S F O R M E R S ,
N A T U R A L L A N G U A G E P R O C E S S I N G
A N D A R T I F I C I A L I N T E L L I G E N C E A N D
M A C H I N E L E A R N I N G I N C Y B E R
S O F T W A R E V U L N E R A B I L I T Y M A N A G E M E N T:
A U T O M A T I O N S I N T H E S O F T W A R E B I L L
O F M A T E R I A L S A N D T H E V U L N E R A B I L I T Y -
E X P L O I T A B I L I T Y E X C H A N G E

G P T, N L P A N D
A I / M L I N C Y B E R
S O F T W A R E
V U L N E R A B I L I T Y :
A U T O M A T I O N S
I N T H E
S O F T W A R E B I L L
O F M A T E R I A L S
A N D T H E
V U L N E R A B I L I T Y -
E X P L O I T A B I L I T Y
E X C H A N G E

I O T A N D
S B O M / V E X
• One of the most burning topics in
cybersecurity in 2023 will undoubtedly
be the compliance with the Software Bill
of Materials
• Keywords: Artificial Intelligence and
Machine Learning , Cyber vulnerability
management, Software Bill of Materials ,
Vulnerability-Exploitability eXchange ,
Common Security Advisory Framework ,
Software Supply Chain Cyber Risk

I N T R O D U C T I O N
• This article addresses problems
associated with cyber vulnerability
management, going into details about
Common Security Advisory Framework ,
and the relationship between the
Software Bill of Materials and the
Vulnerability Exploitability eXchange and
the implementation
• The main aim of the article is to present
solution for automation in the
SBOM/VEX implementation process,
because asset owners operate with
priorities related to revenue, uptime,
maintenance, but cybersecurity is not
one of their key priorities
• Regulatory requirements can be priority,
especially if they are related to safety,
asset owners will have to comply with
the regulation, but it’s not their main
priority for operations

I N T R O D U C T I O N
• This article is covering only a small part
of the cybersecurity operations, which is
the updates and patch management
• A cybersecurity professional would
always advise critical infrastructures to
do their patches and updates, and the
response is quite often, is it necessary,
it’s hard, why should I do this, and this
debate is a big part of the problem
• One simple solution proposed by Art
Manion was to replace the Common
Vulnerability Scoring System Calculator
, with three possible strategies, based
on the vulnerability score only, these
options are if CVSS > 8.9 then patch
now; if CVSS > 6.0 patch latter; and if
CVSS < 7.0 then accept the risk

R E S E A R C H A I H A I M S A N D O B J E C T I V E S
The aim of this review paper is to derive with working
solutions for automating the compliance of SBOM and
VEX
The objectives are to resolve the problems with product
naming, and to present different solutions for association
of SBOM to VEX in an automated and scalable method

D ATA S O U R C E S
• The primary data includes 20 case study
interviews and 3 workshops with Cisco,
conducted between 2019 and 2022,
virtually and in person
• The secondary data sources include
data records, video recordings, working
papers, and draft reports from CSAF,
NTIA, CISA, NIST, and Cisco
• Additional secondary data was extracted
from existing research data records
• To gather relevant research data records
and to synthesise existing knowledge on
the subject, we first started by searching
the Web of Science Core Collection for
records on ‘Vulnerability-Exploitability
eXchange’, which resulted with 0 date
records

D ATA S O U R C E S
• The final search we
conducted was on Google
Scholar, and on VEX we had
to use the " " again, because
the results were scattered
around different topics, but
with the " " function, we
obtained 4 results, which
was more than the previous
two searches

M E T H O D S F O R
A N A LY S I S
• To analyse the data records,
the case study research
method is applied, in
combination with grounded
theory to categorise data
records into axes
• The emerging solutions are
derived from multiple
sources and verified through
workshops with the study
participants
• Experimental testing of the
solutions was conducted in
the Oxford e-Research

B R I E F L I T E R AT U R E P R E V I E W
O F C Y B E R S E C U R I T Y R E P O R T S
O N V E X A N D S B O M

W H A T I S S O F T W A R E
S U P P L Y C H A I N
C Y B E R R I S K
• Software Supply Chain can
be defined as the collection
of components, libraries,
tools, and processes used to
develop, build, and publish
the software

W H A T I S T H E S O F T W A R E
B I L L O F M A T E R I A L S A N D
H O W D O E S I T H E L P W I T H
C Y B E R R I S K A S S E S S M E N T
• The Software Bill of Materials can be
defined as a nested inventory for
software, a list of ingredients that make
up software components and
dependencies, and their hierarchical
relationships | National
Telecommunications and Information
Administration, 2021)
• The main use cases include supply
chain assets and vulnerabilities
management via sharing and
exchanging SBOMs, but because of ‘the
diverse needs of the software
ecosystem, there is no one-size-fits-all
solution’
• In Figure 1, we can see the hierarchy of
automation in different formats ,
specifications, and tools that are still
under development

B A C K G R O U N D T O T H E
V U L N E R A B I L I T Y
M A N A G E M E N T
P R O B L E M S
• SBOM enables us to identify potentially
vulnerable components, but a
vulnerability associated with a software
component is not necessarily exploitable
• Organisations cannot perform
cybersecurity risk management for all
known vulnerabilities, and risk
management is based on their cyber risk
tolerance, which is based on the
likelihood and severity of the risk
materialising
• Vulnerabilities also need to be risk
assessed because around 75% of
attacks in 2020 used vulnerabilities were
at least two years old and high-risk
vulnerabilities are present on the
network perimeters of 84% of companies

W H A T I S T H E V U L N E R A B I L I T Y
E X P L O I T A B I L I T Y E X C H A N G E
A N D H O W I S I T D I F F E R E N T
F R O M S B O M A N D C V E
• From the most severe vulnerability
of 2021, the Log4j, we can
understand why vulnerabilities need
to be assessed for exploits – while
most cybersecurity professionals
wasted vast amount of time risk
assessing if Log4j was exploitable
on their system, in many cases, it
was not exploitable, and yet, it is
extremely likely that a high number
of Log4j vulnerable applications
remain online
• To help prevent this in the future,
the Vulnerability Exploitability
eXchange was created in
• VEX’s providess the SBOM’s with
transparency and an up-to-date
view of the status of vulnerabilities

W H A T I S T H E V U L N E R A B I L I T Y D I S C L O S U R E
R E P O R T A N D H O W I S I T D I F F E R E N T F R O M
V U L N E R A B I L I T Y E X P L O I T A B I L I T Y E X C H A N G E
The Vulnerability Disclosure Report is ‘an attestation of all vulnerabilities
affecting a product, or its’ dependencies, along with an analysis of the impact’ ,
and are issued by the software supplier, or a third party, and include a
timestamp signing the date and time of the VDR
VDRs contain a list of vulnerabilities that affect a specific software product and
its component dependencies, includes an analysis of the impact and plans on
how to address the vulnerability
Vulnerability Exploitability eXchange on the other hand, comparing to VDR, ‘is a
negative security advisory intended to state all vulnerabilities a product is not
affected by’

S U R V E Y O F S E C O N D A R Y D A T A
O N R E T H I N K I N G V E X A N D S B O M

U T I L I S AT I O N P R O B L E M
At present, SBOMs are used extensively by software developers,
and given how useful SBOMs have been for them, developers
are very keen on distributing the reports to end users
The motivation for this article, is not to determine the value of
SBOMs in securing end users’ networks, that topic has been
covered extensively in year 2021/
The motivation for this article is to determine what will persuade
end users to start using SBOMs, and the key to this is to
determine what is the real value in SBOMs for end users

A U T O M AT I O N A N D S C A L I N G
R E Q U I R E M E N T S
One of the leading reasons why software users are not requesting
SBOMs is that approximately 95% of all vulnerabilities for
components listed in an SBOM won’t be exploitable in the product
Given that cybersecurity teams are already over stretched by
responding to exploitable vulnerabilities detected by their scanners,
checking 95% of false positives doesn’t seem like a good idea
Since the Dependency-Track tool is not the only tool, and the OSS
Index is not the only database, we can expect at least 50,000
organisations to be using SBOMs for vulnerability management

T H E E X E C U T I V E
O R D E R 1 4 0 2 8
• As of August 2022, every US
federal agency is required to start
requesting SBOMs from their
suppliers
• With VEX documents becoming
more widely available, and when
the consumer tools and services
are available, we can expect end
users to start using SBOMs and
VEXs for software risk
management
• Meanwhile, the executive order
14028 is in full effect from August
2022, we can expect SBOMs to
start transmitting to end users,
but at present, there is not a
single complete end user tool for
consuming SBOM/VEX

T H I R D - P A R T Y
S E R V I C E P R O V I D E R
• This does not mean that SBOM/VEX is a
lost cause, it just means that end users are
unlikely to be interested in exploitable
vulnerabilities in the software they use and
will most likely resort to using third party
service providers
• The most likely short term solution is a
subscription-based service for SBOM/VEX-
based software component vulnerability
management, where the cost would be
divided over many customers, creating a
form of economy of scale in SBOM/VEX
analytics
• The third-party service provider would need
to add value to the software component
vulnerability management process, such as
direct communication with the suppliers on
determining if different component
vulnerabilities are exploitable in a specific
product

P R O B L E M S W I T H S B O M
A N D V E X A N D S O L U T I O N S
F O R A U T O M A T I O N O F
S B O M A N D V E X
• : Pedigree and provenance information: to support
the supply chain custody, SPDX needs improved
data on the place of origin, chronology of
ownership, or the known history, and this data
needs to be correlated to VEX, including
relationships and interactions integrity checks
• : Lack of representation: SPDX needs to identify
VEX use cases and add elements to support such
use cases
• : SBOM to VEX association in an automated way
• : Product naming
• : Real-time updates
• : Ethical challenges: One of the ethical challenges
for SBOMs and VEXs is the question why software
producers would create something that would
allow consumers to openly look at the code
vulnerabilities

C O M P A R I S O N
B E T W E E N S B O M ,
V E X , C S A F , A N D V D R
• One simple comparison between
SBOM and CSAF is that SBOM is
designed for automation, the same
as CSAF
• SBOM is designed for
vulnerabilities across the entire
software supply chain, while CSAF
leverages relationships with
existing vendor
• VEX will play a major role in
resolving many issues related to
SBOM and CSAF, especially in
terms of reducing the workload,
because VEX is a negative security
advisory, and it can be especially
useful in hype cases like log4shell,
by providing the support team with
some relief when the panic starts

I M P A C T O F S B O M S
O N T H E U K A N D U . S .
C Y B E R D I P L O M A C Y
• Since 2016, I have been working
on a US/UK funded project, and
one of the key conclusions from
this long research project, is that
for the UK to continue
collaborating with the US on
developing new software, UK
cybersecurity agencies must
comply with U.S. cybersecurity
regulations on software security
• Since the U.S. agencies are
currently leading in cybersecurity,
this compliance is mutually
beneficial, but the values are not
clearly visible to UK cyber policy
decision makers

• The challenge for UK
developers is that the
regulations and standards
across the US and the UK
are very different, and since
the US president issued the
Executive Order 14028 on
Improving the Nation’s
Cybersecurity, software
developers in the US have
adapted, and software bill of
materials are transmitted to
vendors, customers, and
users

• To facilitate, UK cybersecurity
agencies need to learn from
the U.S. vast network of
different cybersecurity
agencies, not to impose my
technical opinions, but to
identify the general idea,
including the obstacles and
motivations for UK/US
cybersecurity bodies and
government departments to
work collaboratively on
standardising the software
application security
requirements, which
contributes to building a more
secure and resilient world

F R A M E W O R K F O R R E -
E S T A B L I S H I N G T H E U K /
U . S . C Y B E R D I P L O M A C Y
• The framework we developed is directly
related to other UK efforts on cyber
security, and with focus on re-
establishing cyber diplomacy with U.S.,
UK, and EU cyber regulations
• This work is based on the new and
emerging areas is the ‘Vulnerability
Exploitability Exchange’ and the
‘Software Bill of Materials’ with the
OASIS Common Security Advisory
Framework , and the quantification of
cyber risk in close collaboration with the
Factor Analysis of Information Risk
Institute
• This framework is targeted at applying
existing know-how, to develop a new
US/UK cyber-policy for the problems
associated with cyber vulnerability
management

F R A M E W O R K F O R R E -
E S T A B L I S H I N G T H E U K /
U . S . C Y B E R D I P L O M A C Y
• This framework is based on our work
based on data collected and shared
evidence from policymakers and
decision-makers on cybersecurity, cyber-
risk, and cyber-diplomacy
• The first phase is to improve access for
the policymaking community to the best
available evidence and expertise from
existing partnership networks and invite
collaborators from industry that operates
in UK and U.S. cybersecurity, to
reciprocate on a SBOM/VEX public
policy
• The first complex problem related to re-
establishing cyber diplomacy with U.S.,
UK, and EU cyber regulations, is to
ensure the UK and EU audience
understands that without SBOMs, we
cannot position where the risk is – e.g.,
in software applications

F R A M E W O R K
D E S I G N
• We already designed and led a similar
knowledge exchange engagement
activity on cyber diplomacy with CSAF,
Cisco, PETRAS, and Oxford
• The objective of the knowledge
exchange engagement activity was to
strengthen the US/UK policy on software
security and enhance the University of
Oxford leadership for policy engagement
• In this knowledge exchange engagement
activity, we developed and shared the
skills required to work as partners
alongside policymakers, so our own and
others’ evidence was better informed in
the decision-making and was enhanced
with evaluation and learning from the
world leading organisations in
cybersecurity

F R A M E W O R K
D E S I G N
• In terms of challenges of effective
knowledge exchange, one of the
major ethical challenges that we
worked on, is the question why
software producers would create
something like SBOM or VEX,
that would allow consumers to
openly look at the code
vulnerabilities
• The solution we proposed to
address these challenges is to
have the data freely available for
all and this is partially related to
cyber legislation and partially
related to new cyber tools

C O N C L U S I O N S
• First problem is that SPDX is not aligned
with VEX, and the provided solution is to
use AI/ML algorithms for provenance and
annotations of the metadata
• Second problem is pedigree and
provenance information is often missing,
and the presented solution is to use AI/ML
algorithms for automated collection of
metadata, provenance and annotations at
scale
• Next three problems are the lack of
representation and use cases for VEX,
followed by difficulties with auditing,
formulation, and vulnerability extensions,
and the constrained IoT use case
• Sixed problem is that VEX use cases differ,
and the proposed solution is a repository
based on the existing Maturity Indicators
and the Maturity Indicator Testing
framework smartAPI interface annotation

C O N C L U S I O N S
• Seventh problem is the product
naming, and for this, a function
based on the CISA-SSVC can be
added in the repository - to the
recent CSAF standard
• Eight problem is the need for
real-time updates, and the
proposed solution is a dynamic
real-time VEX
• Finally, we have the ethical
challenges, the proposed solution
is a website with a user-friendly
application programming
interface , designed in
collaboration with CSAF, NTIA,
CISA and other parties

A R E A S F O R
F U R T H E R
R E S E A R C H
• The OASIS Standard is the
language reference for the CSAF
version 2.0 and is designed to
automate the exchange of Security
Advisories formulated in JSON
• Future research should investigate
if the security of product naming
can be solved by naming software
products as non-fungible tokens
• Generative Pre-Trained
Transformers can be personalised
and specialised to be specific for
the VEX problems, and prevent the
reports being disseminated for
vulnerabilities that should have
been patched yesterday, which
seems to be the case with manual
patching

D E C L A R AT I O N S
Funding: This work has been
supported by the PETRAS National
Centre of Excellence for IoT
Systems Cybersecurity, which has
been funded by the UK EPSRC
[under grant number
EP/S035362/1], the Software
Sustainability Institute [grant
number: EP/S021779/1], and by
the Cisco Research Centre [grant
number CG1525381].
Acknowledgements: Eternal
gratitude to the Fulbright Visiting
Scholar Project

R E F E R E N C E S
• Software Bill of Materials |
National
Telecommunications and
Information Administration

Software Bill of Materials and the Vulnerability Exploitability eXchange

More Related Content

Similar to Software Bill of Materials and the Vulnerability Exploitability eXchange

More from Petar Radanliev

Recently uploaded

Software Bill of Materials and the Vulnerability Exploitability eXchange