The Open Source Software Security Foundation (OpenSSF), a project of the Linux Foundation, has come up with a 10-point plan to improve the safety of the software supply chain, costed at $147.9M over two years, though it relies in part on developers changing their behaviour to take more account of security issues.

According to the OpenSSF “roughly 70-90% of any software stack consists of open source software.” Whether or not an application itself is open source, it is likely to include libraries and dependencies that are, developed using open source programming languages and compilers, and deployed on open source platforms.

“The shared benefit also comes with shared risk in the form of exposure to vulnerabilities in those OSS components,” observes the new paper.

Top of the list is developer training, with the OpenSSF proposing ideally 40-50 hours training, which may be offered for free, to teach “writing software securely.”

Another proposal is to extend the use of digital signatures. Users have learned to be wary of compiled software that is not digitally signed, and app stores such as those from Google, Apple and Microsoft require them. The development process though may include unsigned code, making the signing of the final output less meaningful.  The OpenSSF is promoting use of sigstore, a project with wide industry support, which aims to automate digital signing of components to give assurance they are tamper-free.

The plan also urges the “replacement of non-memory-safe languages,” with the finger pointed at C and C++ which “allow programmers to easily make memory management mistakes.” Here, the partner project is Prossimo, from the same security group which provides Let’s Encrypt certificates, and with initiatives including a Rust library to replace OpenSSL, and memory-safe alternatives for critical networking components including DNS resolvers, curl and NTP.

The OpenSSF team also intends to promote SBOMs (Software Bill of Materials) as a “fundamental building block” towards more secure software. The issue is simple: if there is no SBOM, it is hard for organizations to know what software they are using, and therefore whether they are impacted by a newly discovered vulnerability.

“SBOMs are not yet widely generated or consumed in the software industry,” said the OpenSSF.

Other proposals include a new incident response team, faster discovery and disclosure of vulnerabilities, code reviews of the most critical open source components, and a new vendor-neutral risk assessment dashboard.

This new 50-page report has plenty of ideas and detail, but changing developer culture is not easy. Teams under pressure to deliver projects on time and on budget may not give security the attention it deserves, tools which suck down dependencies with near-invisibility to the developer make it hard to keep track, and exhortations to switch to a safer language often do not go down well with experienced coders.