2. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Topics in some order
• The problem
• CRA in short
• Securing the software development supply chain
• SBOM - Software bill of materials
• Managing vulnerabilities
• Q/A
CRA
3. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
The problem
• We build on a lot of 3rd
party software that can
have security issues
• Our own software surely
have security issues
• Tools we use may have
security issues
• We need routines to handle
them.
CRA
4. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Authorities react
This has clear effects on how we produce
software.
5. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
CRA focus
Manage and
fi
x vulnerabilities.
Security by
design.
Transparency
to customers.
CRA
6. Which software?
Everything from mobile applications to
embedded systems.
Excluding software-as-a-service with
no local components (apps, systems)
Excluding those that have strict rules - like
aviation, military, medical systems
CRA
8. Placing a product on the
market makes you responsible.
Manufacturer Importer Distributor
CRA
All are responsible.
OEM
9. Two phase approach
Phase one
Make sure all manufacturers
have a vulnerability handling
process in place.
1 year
Phase two
All products sold on
the EU market needs to
be secure by default.
2 years
CRA
10. Phase one and two.
Manage
vulnerabilities
Report exploitable
vulnerabilities
Inform customers
Prioritise cyber
security
Build secure products
Secure the supply
chain
Phase one: 12 months after regulation. All products (old and new)
Phase two: 24 months after regulation. New and updated products.
Self-certi
fi
cation for some product categories,
3rd party certi
fi
cation for others
CRA
Phase one
Phase two
11. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
A new tool chain and
process is needed
Various inputs Inventory Assessment Mitigation
Update software
Only update inventory
“no action”
?
Manage and
fi
x
vulnerabilities.
CRA
= vulnerability
Most of the incoming vulnerabilities
will lead to “no action” because our
solution is “not affected”.
But the serious ones
needs to be handled!
CVE
Data
12. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Security by design
• Coding practises
• Testing by internal and external
teams
• Automatic supply chains, build tools
• CI/CD
CRA
Security by design.
A subject large enough for a
separate meeting :-)
Security by default.
13. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Customers insight
Transparency to
customers.
CRA
SBOM & VEX
Documentation
Risk assessment
EU Declaration of
conformance
Vulnerability process
14. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Declaration of
conformance
Manufacturing process
documentation
Detailed description of product
Risk assessment
Vulnerability process
Customers
16. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
The goal for a product
team
CRA
Follow new
regulation in EU
Find vulnerabilities fast,
fix them fast
Make software
dependecies visible
Create more secure
products.
17. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Gut reaction:
HELP!
CRA
19. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
The supply chain problem
Source: https://slsa.dev
CRA
Many opportunities to
insert bad code.
20. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Software Supply chain
security is critical
Automation is the only way to
handle this.
CRA
Write code
Commit
code
Add 3rd
party library
or tool
Test
Build
package
Distribute
released
package
Who commits
code?
Who made
the decision
and why?
21. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Digital signature on all artifacts and log
fi
les from build, test, release
Signed logs and artifacts
Write code
Commit
code
Add 3rd
party library
or tool
Test
Build
package
Distribute
released
package
CRA
Which identity signs
the artifacts?
22. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Levels of supply chain
security (SLSA)
https://slsa.dev - OpenSSF project
CRA
23. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
What does CRA say?
• If there’s an exploitation related to your product, you need
a lot of information for the auditors
• How the product was built
• Versions of all build tools
• SBOM detailing dependencies
• Documentation of your supply chain
• Certi
fi
cate of conformity
CRA
25. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
All products have many
components
Alice’s Cool IoT Box
Our Code Our protocols Our hardware
3rd party
libraries
3rd party O/S
3rd party
protocols
Standard
protocols
3rd party
hardware
Build and test
tools
CRA
90%
Of the code in all
software products
is estimated to be based on
Open Source
26. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Building on
Open Source Software
• We need to monitor and evaluate open source software
projects like we evaluate and monitor commercial vendors
• We need to interact, contribute patches, open issues,
improve documentation, pay for
fi
xes or support
• We depend on these projects for our products
CRA
27. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Dependency cost
• Open Source is free, but handling every
dependency you add is not free of costs
• Cost/dependency will matter
• Vulnerability handling, contributing
upstream, monitoring upstream projects
CRA
$ $ $
$$
CPD
COST PER DEPENDENCY
28. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Minimize dependency tree
• First question when adding an open source
dependency: “Why? Can I live without this?”
• Don’t blindly add stu
ff
that adds stu
ff
that never
ends and expands your dependency tree out of
control
• Minimize containers, minimize embedded Linux.
• Every addition will add cost in vulnerability
handling.
CRA
CPD
COST PER DEPENDENCY
29. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Critical tool: The SBOM
• Software Bill of Materials
• SBOM is a digitally signed
fi
le listing all
components, their licenses and origin
• Used to track vulnerabilities
• Many formats: SPDX, CycloneFX
• Many usages, not only vulnerability
and license handling
CRA
30. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Types of SBOM (CISA)
SOURCE BUILD ANALYZED DEPLOYED RUNTIME
• SBOM created
directly from
development
environment
• Source
fi
les, tools
• SBOM generated
as part of the
process of
building the
software
• Source
fi
les,
dependencies,
build tools
• SBOM generated
from analysis of
artifacts
• Executable,
packages,
containers, VMs
• SBOM generated
from analysis of a
system
• Based on
inventory of the
system, using the
con
fi
guration
fi
les
and examination
of execution
• SBOM generated
through
instrumenting the
system running
the software
• Captures only the
components
present in the
system, loaded
and executing in
memory as well as
external calls or
dynamically
loaded
components
CRA
DESIGN
• SBOM of
intented, planned
software project
or product with
included
components
(some of which
may not yet exist)
for a new software
artifact
• Typically derived
from design
speci
fi
cation, RFC
or initial concept.
SOURCE: https://www.cisa.gov/sites/default/
fi
les/2023-04/sbom-types-document-508c.pdf
31. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
SBOM for your code
• How do you document your own code in an
SBOM?
• One module or multiple?
• Who creates internal or public CVEs for your
code?
32. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Finding vulnerabilities
• Check all your SBOMs with vulnerability database
• There are both commercial and open source systems for
that.
SBOM dev
SBOM rel 4.2
SBOM rel 3.5
SBOM rel 2.7
QUERY
VULNERABILITY
DATABASE
CRA
33. Ⓒ 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
ff
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
34. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Manage and monitor
dependencies
SBOM vendor
code
SBOM our product
current release
Vulnerability
assessment report
Automation and
standardised
document formats.
SBOM = Software Bill of Materials
SBOM our product
old releases
Vulnerability
management
system
Vulnerability
assessment report
SBOM our code
SBOM open
source
CRA
CVE
35. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
SBOM quality
• SBOM quality is becoming an issue, as is CVE quality
• For automation, the product identi
fi
ers need to be exact
• PURL is critical - a unique URL for the software used
• Just a name like “curl” or “nginx” is not enough
• Work is going on to build rating systems, quality checkers
• Will likely need manual work to adjust output from
scanners
Suggested reading: https://edu.chainguard.dev/open-source/sbom/what-makes-a-good-sbom/
CRA
PURL
Package URL
https://github.com/package-url/purl-spec
37. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
spdx
• The Software Package Data Exchange
• An open standard for communicating software
bill of material information, including
components, licenses, copyrights, and security
references
• ISO/IEC 5962:2021
• A Linux Foundation project
• Standardised markers for open source licenses
• Used to scan and build SBOM
https://spdx.dev
CRA
38. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
CycloneDX
• OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that
provides advanced supply chain capabilities for cyber risk reduction. The
speci
fi
cation supports:
• Software Bill of Materials (SBOM)
• Software-as-a-Service Bill of Materials (SaaSBOM)
• Hardware Bill of Materials (HBOM)
• Operations Bill of Materials (OBOM)
• Vulnerability Disclosure Reports (VDR)
• Vulnerability Exploitability eXchange (VEX)
• Strategic direction of the speci
fi
cation is managed by the CycloneDX Core
Working Group, is backed by the OWASP Foundation, and is supported by the
global information security community.
https://cyclonedx.org
CRA
40. Ⓒ 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
fi
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
41. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
What is a vulnerability?
• Exploited vulnerability (CVE)
• Known vulnerability (CVE)
• Our own issues
• Exploits using our product
Managing and assessing the
fl
ow of vulnerabilities
will be a critical function in the dev team.
CRA
CVE
CVSS
Common Vulnerability Enumeration
Common Vulnerability Scoring System
CWE
Common Weakness Enumeration
42. Ⓒ 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
43. Ⓒ 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
44. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
The fix
CRA
45. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
CVE Alert to process…
How many in your organisation can
process this and evaluate the risk?
CRA
46. CVSS parts
CVSS BASE
(Never changes)
CVSS Temporal
(Vendor changes)
CVSS Environmental
(Usage changes)
CVSS set by NVD/Mitre Values set by vendor
Remediation
Values based on usage
CVSS
default
CVSS
Temporal
CVSS Final
Exploitability
Report con
fi
dence Damage potential
Target distribution
Many metrics
47. Ⓒ 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
48. Ⓒ 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
50. Ⓒ 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
51. Ⓒ Olle E. Johansson, Edvina AB, Sollentuna 2023
Summary
• SBOM is an inventory, a tool
• VEX is statements about vulnerabilities
• Vulnerability scanners do the job in di
ff
erent ways,
use many
• Assessment of “incoming” reports and combining
them with your own will be a mostly manual process
• Someone will need to sign o
ff
on the VEX report for
your product
CRA
52. The Open Source dilemma
• Open Source projects are excluded from the CRA.
• But not if the project is part of a commercial activity - which
is a strange exception. Open Source developers needs to
earn their living too. Selling support, getting funding for
development and performing trainings are all parts of the
Open Source business model.
• Strong reaction from the Open Source community. Some
actors plan to stop distribution to EU if this comes in place.
• The current text is bad for business - both Open Source
projects and commercial products that rely on Open Source.
https://www.internetsociety.org/blog/2022/10/the-eus-proposed-cyber-resilience-act-will-damage-the-open-source-ecosystem/
CRA
53. Ignoring CRA will be
expensive
Notice - “2.5% of total worldwide annual
turnover” or 15 000 000 EUR
CRA
54. Short-term To Do list:
De
fi
ne the gap
Current product
CRA compliant
product
Is it possible to make current products
compliant?
CRA
55. My conclusion
The general idea of the CRA is
good and will lead to a better
market.
The devil is in the details. What is
“state of the art security” and “secure by
default”?
Companies that take leadership will bene
fi
t
and get a better market position.
Open Source will have to get
better protection in the CRA.
Make sure you
have access to expertise in the
area. They are going to get busy
soon.
CRA
56. Comments we’ve heard
This will be a blocker for innovation we
need.
The CRA will lead to products leaving the
EU market.
The CRA is way too detailed and
technology dependent. Will not last over
time.
We have equipment out there that can’t be
updated at all.
CRA