Anthony Harrison, APH10
What a great day at the first Nordic Software Security Summit#nsss24 organised by Olle E Johansson. Great presentations, thought provoking discussions and a great community.
So what were the key takeaways from Day 1?
🎯 There are many challenges in developing a ‘must have’ Open Source application (curl) used by 20 billion devices without any funding. Becoming a CNA helps control who can raise vulnerabilities but the CNA process is not scalable for the millions of OSS projects.
🎯 Many OSS projects try to follow best practices in improving robustness of the software. This is visible to the community unlike proprietary software.
🎯 AI will not save issues in identifying vulnerabilities in open source software. AI will burden maintainers by generating ‘potential’ vulnerabilities which will require a detail triage for each one.
🎯 Cyber requires a multi-disciplined team to provide effective governance, management and use of technology. Legal and technical specialists need to work together to understand the cyber threats and assess the suppliers that the organisations is dependent on.
🎯 The senior leadership team need to be aware of their responsibility which the CRA will be requiring the organisation to implement and the consequences for not implementing the regulation.
🎯 The CRA is focused on the product security and not the organisation (although to deliver the CRA will require the organisation to implement certain practices necessary to secure a product effectively). The CRA changes the incentive to make product security mandatory.
🎯 The CRA is required because it can’t wait for a global solution to be developed in time.
🎯 The CRA expects a product to have no known exploitable vulnerabilities with a fix determined by the criticality. Software Bill of Materials (SBOMs) need to be available (on demand) but do not need to be publicly shared; the depth of dependencies will require more than just the direct dependencies used by a product (noting that 6 out of 7 vulnerabilities reside in transitive dependencies). SBOMs must not contain details of vulnerabilities; vulnerabilities need to be provided in separate VEX artefacts.
🎯 The CRA requires a shared responsibility model with regards vulnerabilities. Vendors fixing vulnerabilities need to share with the upstream project.
🎯 There are still many detailed issues surrounding how the CRA will work. The CRA is based on the work of the US EO 14028 but covers a wider scope (not just systems for the federal government).
🎯 There has been significant progress in the past few years to improve the security of Open Source software led in particular by OpenSSF. However much of this is aimed at the larger projects; many of the recommendations cannot be implemented by the typical small OSS projects and tooling needs to catch up to help many of these projects do the ‘right thing’ automatically.
Looking forward to another awesome day tomorrow.
(Originally published on LInkedIn)
