Software Bill of Materials and the Vulnerability Exploitability eXchange

Petar Radanliev
Petar RadanlievPost-doctoral research associate
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
Software Bill of Materials and the Vulnerability Exploitability eXchange
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
M E T H O D O L O G Y
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
D I S C U S S I O N
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
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
• 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
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
• 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
1 of 38

More Related Content

Similar to Software Bill of Materials and the Vulnerability Exploitability eXchange (20)

Abb e guide3Abb e guide3
Abb e guide3
Claricio Gobbo619 views
ByteCode pentest report exampleByteCode pentest report example
ByteCode pentest report example
Ihor Uzhvenko196 views
Aliens in Your Apps!Aliens in Your Apps!
Aliens in Your Apps!
All Things Open410 views
Analysis and Design of Information SystemsAnalysis and Design of Information Systems
Analysis and Design of Information Systems
Nhận Viết Thuê Đề Tài Baocaothuctap.net/ Zalo : 0909.232.62035 views
DOES14 - Joshua Corman - SonatypeDOES14 - Joshua Corman - Sonatype
DOES14 - Joshua Corman - Sonatype
Gene Kim10.1K views
Reduce Third Party Developer RisksReduce Third Party Developer Risks
Reduce Third Party Developer Risks
Kevo Meehan229 views
Software Bill of MaterialsSoftware Bill of Materials
Software Bill of Materials
Petar Radanliev11 views

More from Petar Radanliev(20)

Petar Radanliev, PhD ThesisPetar Radanliev, PhD Thesis
Petar Radanliev, PhD Thesis
Petar Radanliev9 views
Introduction to Cyber DiplomacyIntroduction to Cyber Diplomacy
Introduction to Cyber Diplomacy
Petar Radanliev41 views
Inclusiveness in the MetaverseInclusiveness in the Metaverse
Inclusiveness in the Metaverse
Petar Radanliev11 views

Software Bill of Materials and the Vulnerability Exploitability eXchange

  • 1. University of Oxford GPT, NLP AND AI/ML IN CYBER SOFTWARE VULNERABILITY SBOM / VEX
  • 2. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. M E T H O D O L O G Y
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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’
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. D I S C U S S I O N
  • 26. 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
  • 27. 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
  • 28. 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 • 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
  • 29. 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 • 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. R E F E R E N C E S • Software Bill of Materials | National Telecommunications and Information Administration