| New Initiative For Taking Open Source Software Security Seriously |
| Written by Nikos Vaggalis |
| Monday, 21 February 2022 |
|
The Alpha Omega Project is a new initiative by the Linux Foundation to strengthen the security of critical open source applications. Why is this important? The answer is the extent to which we all now rely on open source software which, as I recently reported in European Union Will Pay For Finding Bugs In Open Source Software, powers everything, from modern servers, to IoT, to the desktops used by enterprises and governments. Evidence of the criticality of such software was provided by the commotion caused by the OpenSSL Heartbleed bug or the recent RCE bug which shook the foundations of every industry. Nowadays every company is a software house, be it Adidas, Tesco or Oracle, whose stack is certain to involve open source libraries at a minor or larger scale. Even the White House acknowledged this, leading to the SBOM directive. The fact that Microsoft and Google are shoveling money into the Alpha-Omega Project, with an initial investment of 5 million dollars, is further evidence of its importance. The narrative is that given the scarcity of the resources to allocate, bug bounties like the European Union's one and the Linux Foundation's SOS Rewards are welcome, but not enough, as they're small in scale. The Linux Foundation found that a larger more holistic attempt should be utilized. For that reason they kickstarted the Alpha Omega initiative. This is actually two distinct but interrelated projects. Alpha is the attempt to directly engage the foundation's experts with the maintainers of the most impactful open source software in order to help them to understand what their security posture is and where their gaps are, in order to fill those gaps and remediate any vulnerabilities found. The foundation is taking a preventative approach which in essence aims to prevent the security related bugs happening in the first place, or identifying them quickly if they do. This involves technical assistance, use of manual code reviewing and whatever tools are appropriate to identify critical vulnerabilities. But the most important aspect is the mentoring they'll provide to the software's maintainers. The mindset is that it's best to prevent the bugs happening than racing to patch them as soon as they are identified. And that can only take place through educating developers to involve security as part of their software's lifecycle rather than treating it as an afterthought. From "The State Of Secure Software Development - Three OpenSSF Courses" : Education is what matters and no tool, however powerful, can replace it. Knowing how to write secure code minimizes the exposure and can mitigate the limitations of the tools. The complexity of today's software doesn't just require writing the core code with security in mind. It requires security not as an aftermath of the development process, but as an integral part of the CI/CD pipelines. There's even a new principle out there on that very subject; the intersection of DevOps and Security in DevSecOps. The core problem is that security is not taught as part of a College or Computer Science degree and for that reason the Linux Foundation has set up the Open Source Security Foundation (OpenSSF), with the aim of educating developers in:
and by launching three courses that together can lead to a Professional Certificate in "Secure Software Development Fundamentals": Geared towards software developers, DevOps professionals, software engineers, web application developers, and others interested in learning how to develop secure software, this course focuses on practical steps that can be taken, even with limited resources, to improve information security. This course will enable software developers to create and maintain systems that are much harder to successfully attack, reduce the damage when attacks are successful, and speed the response so that any latent vulnerabilities can be rapidly repaired. Alpha takes that mindset one step further and under that perspective it gets in touch with the maintainers of selected projects to provide tailored help as well as help them embrace the best practices. But due to limited resource allocation of personnel, they won't be able to cater for all open source projects out there but only for the top 10 or maybe top 20 projects that are deemed the most critical. This brings up the question, who decides which projects get to the top 10 and what are the criteria which dictate which project is more critical than the other? The official statement is that: The projects will be selected based on the work by the OpenSSF Securing Critical Projects working group using a combination of expert opinions and data, including the OpenSSF Criticality Score and Harvard’s “Census” analysis identifying critical open source software. For information on how criticality is measured see our report on the project, Taking Open Source Criticality Seriously, which also has the inital list of 32 projects that had the highest scores. For the rest of the projects that won't make it into the Alpha list, there still is the Omega list. Omega will be the automated tooling part of the story, lightly involving humans as well in tuning the rules to reduce the false positives and the associated noise. The Omega toolchain would involve fuzzing and static analysis tools. The tools to be used are not announced but there's a proof of concept docker container circulating that hosts such tools. I could think of a few that would be included and covered here on IProgrammer in the past : Semgrep - More Than Just a Glorified Grep a tool to search through code for flaws where plain regexes fall flat and using Static Application Security Testing would be overkill. Semgrep proclaims itself as: "a tool for easily detecting and preventing bugs and anti-patterns in your codebase. It combines the convenience of grep with the correctness of syntactical and semantic search". It isn't just a glorified grep, though. It occupies a space somewhere in between grep and a SAST tool - more expressive than grep, but not as hard to tweak and learn as a SAST.
While Qodana's job is to identify and suggests fixes for bugs, security vulnerabilities, duplications, imperfections, anomalous code, probable bugs, dead code, etc, it is also a complete Code Quality Platform with the aim of improving the overall code structure of a project by applying best coding practices. Or a dependency checking tool, in Open Source Insights Into The Software Supply Chain Open Source Insights is a new project by Google that helps developers understand and visualize their applications' dependencies and therefore the vulnerabilities that come with them. A tool that would let you get down to the bottom of every dependency as large or as little that might be. It is capable of detailing how a particular software package is put together;how its building blocks depend on each other. For each such building block you get detailed statistics, security vulnerabilities alerts, its licenses, etc. With that insight then you can decide whether you should use that dependency or how an other version of it will affect your existing code base. Ultimately, Alpha Omega is an attempt to learn, through collaboration, involvement, interaction and tweaking of tools, how to find optimal ways of building more secure software.That is, to identify the blind spots and the difficulties of embracing security as a whole and then streamline the process benefiting developers and society alike. More InformationRelated ArticlesEuropean Union Will Pay For Finding Bugs In Open Source Software $1 Million SOS Rewards Pilot Program Taking Open Source Criticality Seriously JetBrain's Qodana - More Than Just A Linter Open Source Insights Into The Software Supply Chain The State Of Secure Software Development - Three OpenSSF Courses Semgrep - More Than Just a Glorified Grep Does Sigstore Really Secure The Supply Chain?
To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin. 
Comments
or email your comment to: comments@i-programmer.info |
| Last Updated ( Monday, 21 February 2022 ) |
