some order • The problem • CRA in short • Securing the software development supply chain • SBOM - Software bill of materials • Managing vulnerabilities • Q/A CRA
• 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
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
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
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.
for a product team CRA Follow new regulation in EU Find vulnerabilities fast, fix them fast Make software dependecies visible Create more secure products.
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?
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?
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
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
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
• 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
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
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
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
• 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
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
• 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
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
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
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
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
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
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
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
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
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
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
kentapapa
kentarofujii
yahonda
syuchimu
camiha
.png){kind=avatar}
yamad
jtakeda
.png){kind=avatar}
codatum
ivry_presentationmaterials
yu23ki14
kworkdev
kairim0
bkeepers
mayatellez
letsgokoyo
mfonobong
samtorres
cassininazir
asonas
codingconduct
![CRA: A development perspective oej 2023-05-05 v 2.42 [email protected]](https://files.speakerdeck.com/presentations/40f50a03ad7a44e2b1fa2b67009bad1e/slide_0.jpg){kind=link}
