Vulnerability handling
oej 2023-03-23 v1.2

What the industry is working on
CRA
Mapping
dependencies in
SBOM
Mapping
SBOMs with vulnerability
databases
Getting a list of known
vulnerabilities
Processing the
vulnerability list
Finding that 90% is not
relevant to our usage
or just wrong
Focusing on the 10%
Avoiding pressure
and calls from concerned
customers
Using VEX to mark all
vulnerabilities in SBOM with
our decision
Automating to
fi
nd
the important
vulnerabilities to work on.

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
A universal vulnerability is a state in a computing system (or set of systems) which
either:
๏ allows an attacker to execute commands as another user
๏ allows an attacker to access data that is contrary to the speci ed access
restrictions for that data
๏ allows an attacker to pose as another entity
๏ allows an attacker to conduct a denial of service
Vulnerabilities
A security
fl
aw, glitch, or weakness found in software
code that could be exploited by an attacker (threat
source).
https://csrc.nist.gov/glossary/term/Software_Vulnerability
CRA

Act now!
Information about vulnerabilities
is traded on the net.
It takes hours, not days or weeks, from
publication until there are hackers using it on
the net.
CRA

Even small devices and
applications can cause harm.
5
Of
fi
ce
network
Your
device
You don’t want to be the
gateway to other systems
in your customer’s network.
Which is why the
CRA includes ALL
components.
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Mapping a vulnerability
• Exploited vulnerability (CVE)
• Known vulnerability (CVE)
• Our own issues
Managing and assessing the
fl
ow of vulnerabilities
will be a critical function in the dev team.
CRA
CVE
CVSS
Common Vulnerability Enumeration
- identi
fi
er for a known vulnerability
Common Vulnerability Scoring System
- indicates severity level
CWE
Common Weakness Enumeration
- indicates type of vulnerability

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
What is a CVE?
CRA
CVE
CVSS
Common Vulnerability Enumeration - a unique identi
fi
er for a vulnerability
Common Vulnerability Scoring System
• Started and operated by MITRE
• A shared database with many
organisations that contribute
• Quality not very consistent
• A method to measure severity of
a CVE going from 0 to 10
0.0 None 0.1-3.9 Low 4.0-6.9 Medium 7.0-8.9 High 9.0-10.0 Critical

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Information flows
https://nvd.nist.gov/vuln/detail/CVE-2022-3643
https://www.cve.org/CVERecord?id=CVE-2022-3643
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
The fix
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
CVE Alert to process…
How many in your organisation can
process this and evaluate the risk?
CRA

CVSS is an indicator
• CVSS is NIST evaluation of the severity
• CVSS conveys how a particular vulnerability works and what aspects of
the information security triad—con
fi
dentiality, integrity, and availability
(CIA)—are impacted by the
fl
aw.
• Some projects have their own levels
• Commercial vendors also add their own evaluation and advice to CVEs
• Don’t rely blindly on CVSS, your usage may be di
ff
erent
• CVSS is not a measurement of risk
• “Consumers may use CVSS information as input to an organizational
vulnerability management process that also considers factors that are
not part of CVSS in order to rank the threats to their technology
infrastructure and make informed remediation decisions. Such factors
may include: number of customers on a product line, monetary losses
due to a breach, life or property threatened, or public sentiment on highly
publicized vulnerabilities.”
Good reading: https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerability-severity-levels/
CRA

Tales from the real world
- RedHat security team annual report
1635
Red Hat Security Advisories
in 2022
35
Critical
629
Moderate
892
Important
2
Exploited
https://www.redhat.com/rhdc/managed-
fi
les/rh-2022-risk-report-detail-254252wg-202303-en.pdf
6
Days handling
CRA

Red Hat’s severity ratings
https://access.redhat.com/sites/default/
fi
les/pages/attachments/an_open_approach_to_vulnerability_management_v1.4.pdf
CRA

Red hat and upstream
CVSS may differ
CRA
Original Open
Source project
code
Original Open
Source project
code
Red hat version
with patches
Original Open
Source project
code
“The Red Hat portfolio is based in large part on upstream open source software. As
part of our productization processes, changes are made to make that code easier to
digest for enterprises. Therefore, the software Red Hat provides is not necessarily
identical to what could be obtained or used from upstream. Vulnerability analysis
on those upstream projects and components are often not always directly applicable
to a Red Hat o
ff
ering.2 As a result, the CVSS scores of an upstream package often
di
ff
er from those for a Red Hat product.”
Red hat document “An open approach to vulnerability management”
How do we separate these
two in SBOM, CVE and
CPE?

Telling the world how you handle a
vulnerability: VEX
• An SBOM is a list of all ingredients in a software,
all components
• This is compared with the NVD, national
vulnerabilities database
• A list of known vulnerabilities will be highlighted
for your software
• For each of these, you need to create a VEX
entry, indicating how you handle this issue
• This will avoid a lot of questions to support…
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
VEX is related to your
SBOM
SBOM
VEX
SBOM VEX
VEX included in SBOM VEX as separately linked document.
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
VEX - vulnerability
exploitability exchange
SBOM
Vulnerability
database (CVE)
VEX
Known, affected
Known, not affected
Under investigation
Fixed
Documenting your assessment
internally and externally.
https://cyclonedx.org/capabilities/vex/
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
VEX - as a filter
SBOM
Vulnerability
database (CVE)
VEX
SBOM vendor
code
SBOM our product
current release
Vulnerability
assessment
SBOM our product
old releases
Vulnerability
database
Vulnerability
assessment
SBOM our code
SBOM open source
components
VEX Filter
“not affected”
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
VEX - needs assessment
SBOM
Vulnerability
database (CVE)
VEX
Do you trust your vendor’s
assessment?
SBOM vendor code SBOM our product
current release
Vulnerability
assessment
Vulnerability
assessment
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
VEX - complexity
SBOM
Vulnerability
database (CVE)
VEX
SBOM vendor code SBOM our product
current release
Vulnerability
assessment
Vulnerability
assessment report
SBOM your code
Vulnerability
assessment
CURL gopher not used
CURL gopher used
CURL vulnerability
in gopher protocol usage.
Houston!!!!
We got a problem.
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
VEX - standards
SBOM
Vulnerability
database (CVE)
VEX
CRA
CycloneDX
https://cyclonedx.org/
OpenVex
https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md
https://www.ntia.gov/
fi
les/ntia/publications/vex_one-page_summary.pdf

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
VEX - online updates
SBOM
Vulnerability
database (CVE)
VEX
CRA
• VEX updates needs to be available
online
• Customers needs to be able to
check the current status regurlarly
• Standard APIs for this will likely
evolve

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
SBOM: Customer control
over installed base
• Get SBOMs for software, equipment and other assets with software
• Build an enterprise-wide SBOM database to check for vulnerabilities that can a ect
operations
• Extend SBOM with priority data - like “Internet facing”, “handling PIR data”, “Customer
facing” etc to assist when prioritising which product to focus on when a problem arises.
• Many enterprise customers will likely require SBOM, regardless of what the law says.
SBOM containers
SBOM printers
SBOM CRM system
SBOM others
QUERY
VULNERABILITY
DATABASE
CRA

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
SBOM/VEX tools
• Massive e
ff
orts right now
• Both commercial
and open source
• Dramatic changes coming
CRA

Handling vulnerabilities
(CVE)

Overview
• A vulnerability handling process
describes how the manufacturer
reacts to vulnerabilities in
software, regardless if it’s in internal
code or 3rd party components
• Needs to be easy to
fi
nd and
understand by customers and end-
users
• Will have legal requirements (and
possibly certi
fi
cation requirements)
VULNERABILITY
HANDLING
PROCESS

Organisation
Product
security
incident
response
team
PSIRT
Country
security
incident
response
team
CSIRT
EU
cyber security agency
ENISA
Manufacturer

Classification
identi
fi
er Severity
Type
Registry
CVE CVSS CWE
Mitre
NIST National
vulnerability database (NVD)
https://www.cve.org/
https://nvd.nist.gov/vuln-metrics/cvss#
https://cwe.mitre.org/index.html

CVE: Vulnerability identifier
identi
fi
er
CVE
Organisation
Organisation
Organisation
Organisation
CVE
CVE
CVE
A global registry with unique
ident
fi
ers for each vulnerability
Many organisations are vetted to
publich in the database.
CVEs can be allocated before public
announcement of the issue to assist
in the process.

Next planned
release
2 weeks
1 week
72 hours
Set your SLA
CRITICAL
HIGH
MEDIUM
LOW
CVSS 0.0 None 0.1-3.9 Low 4.0-6.9 Medium 7.0-8.9 High 9.0-10.0 Critical
CRA: “In due time”
For customers, 72 hours is an
eternity when it comes to a critical
issue.
Severity
CVSS

Issue discovered locally or by customer.
Known issue in 3rd party or our software
Not reported as exploited and/or exploitable.
Known issue in 3rd party or our software
Reported as exploited and/or exploitable.
Report from customer about active exploit.
Escalate to corporate security to handle and report to Enisa.
Vulnerability classification
Active exploit
Known exploitable/
exploited vulnerability
Known vulnerability
New vulnerability

CWE: Common Weakness Enumeration
CWE™ is a community-
developed list of software and
hardware weakness types. It
serves as a common language,
a measuring stick for security
tools, and as a baseline for
weakness identi
fi
cation,
mitigation, and prevention
efforts.
https://cwe.mitre.org/
Type
Registry
CWE

CVD: Coordinated vulnerability disclosure
• The CVD is part of the vulnerability handling process
• The CVD declares how anyone should be able to report
vulnerabilities in a safe way, anonymous if needed, and
con
fi
dential. Email is commonly used - with PGP keys for
encryption.
• Most of the reports come from someone who wants to
help you, so having a good attitude is helpful.
• Some reporters give you a limited time until the report goes
public
• Handling this process properly and patiently is very
important.
Reception

CVD: More reading
https://resources.sei.cmu.edu/asset_
fi
les/SpecialReport/2017_003_001_503340.pdf
Well worth your time!
Reception

Publish information about the issue,
combined with a fix (if available)
Find a way to remediate the problem,
fix it or avoid it by configuration
Verify that there’s a problem (unless already
verified by 3rd party)
Receiving a report direct or
indirectly (through 3rd party component)
Sample process
Remediation
Publication
Product
security
incident
response
team
PSIRT Reception
Veri
fi
cation

Reception
Veri
fi
cation
Report coming
through support call
Customer report from
security officer or other staff
Report from customer
Internal discovery by developer
or other employee
Developer
Support
This phase needs
con
fi
dentiality
and social skills.
Report through bug
bounty program - paid for
Customer report from
security officer
Vulnerability scan, pen test or
other type of security audit
Existing CVE or similar in
3rd party component
Bug bounty program
Security Audit
Report from upstream
Anyone

Verification
Veri
fi
cation
PM
Sec team
Dev team
Q/A team
Dispute
Con
fi
rm
Reception
Remediation
Give feedback to
reporter, discuss.
Existing CVE report
and/or exploit

Remediation
Con
fi
rm
Alert customers
Update risk
assessment
Register CVE?
Other mitigation
Update
Provide
fi
x
Alert authorities
Con
fi
g

Inform customers fast
• Depending on the risk, inform customers before
fi
x is available
• Suggest possible actions to protect systems
and networks
• Inform about planned actions even if you have
no
fi
x yet
Mitigation
using
fi
rewall
Mitigation
using con
fi
g
change
Mitigation by
updating
software

Keep reporter in the loop
• The reporter wants to do good, wants to help
• The reporter may give a deadline for action
• No response or communication from vendor leads
to irritation and possibly unplanned disclosure
• Do not threaten the reporter in any way, don’t
discuss legal actions.
• Read the Coordinated Vulnerability Disclosure
PDF for more information and advice
Planned
disclosure
date
Planned
fi
x
Credits for
fi
nding the
issue

Retrospective:
Learning from every issue
• Gather the team and discuss
• Could the process run better?
• Is the reporter satis
fi
ed with the process
and result?
• Does the code pattern exist elsewhere?
Can it be detected during code tests?
• Update process and coding best practise
documentation if needed
Retrospective
Reception
Mitigation
Testing
Update
Validation

Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
CRA Declaration of
conformance
Manufacturing process
documentation
Detailed description of product
Risk assessment
Vulnerability process
Customers
CRA

Thank you. Questions?
CRA
oej@edvina.net