deutsch🇩🇪

Open Source Security

Proposals for securing projects through a fund

Dr. Thomas Fricke

On behalf of the Prototype Fund

Version: 0.9, 8 September 2021

License: Creative Commons License CC BY-SA 3.0 EN

Authorized Deepl translated version

Summary for the decision

Open source is an important economic factor and contributes to billions in value creation per year. There are numerous projects that are used in security-relevant areas. These initiatives need support in the area of process automation and modern, secure procedures.

The communities are very security-conscious and deliver secure open source packages at a stable level. However, more elaborate methods of securing software processes are not standard because there are not enough human resources available in the projects. Sometimes communities work at the edge of their capabilities. In order to implement secured processes, support by a fund in the range of 15-30 million € / year is suggested. The goal must be a largely automatic analysis and installation of the software. On the other hand, there are risks for potential damages in the high billion range.

The proposed projects are important for industrial application from the field of clouds, Gaia-X, machine learning and the further development of deployment. In addition, there are real laboratories for future security technologies in the energy and industrial sectors to raise modern security paradigms to the standard.

Responsible disclosure is suggested for dealing with security vulnerabilities. The fund should be managed by technically experienced persons who are recognized in the community in order to achieve acceptance.

The document addresses what the author considers to be important examples. It is not a representative analysis and is based on personal experience over the last decades. There are many more projects that deserve mention.

Economic importance of Open Source

The economic impact of open source is 65-95 billion euros in 2018 , according to the results of the Open Source Impact Study¹ . The use runs through all areas of economic life, from private mobile phones² , routers³ , televisions⁴ , vehicles⁵ , telecommunications infrastructure⁶ , to industrial plants with thousands of pages⁷ of software inventory list in the SBOM⁸ . The importance goes so far that specialized open source products are co-developed by Bosch and Siemens , among others , for the automated collection of all components , which allow the automatic creation of SBOMs from the source code⁹. In addition, Bosch, BMW, Daimler and Siemens have their own groups working on the standardization of open source compliance as part of the open chain project on ISO 5230. The ¹⁰share of software in value creation in cars is estimated to reach 60% in just a few years¹¹.

For the use in public authorities and the further development of open source by the public sector, the fundamental questions have already been clarified.¹² Many of the aspects discussed also apply to the economy.

Security of Open Source vs Closed Source products

The assumption that only enough eyes need to look at the code to bring all bugs to the surface, also called Linus's law¹³[, is used to argue for FOSS in the security debate. However, it does not say how many eyes, nor how often they should look at the code.]

In contrast, closed source does not mean that the binary code cannot be read. There are appropriate tools¹⁴ and software engineers experienced¹⁵ in reverse engineering who, with their help, are also able to read binary code; even chips¹⁶ can be analyzed with the appropriate effort. If these systems contain a global key¹⁷, for example, this knowledge spreads very quickly on the Internet and entire groups of systems are discredited at a stroke and are massively attacked after a very short time¹⁸. The security holes become known at the latest with the patch and the attacks begin within a day¹⁹[.]

All this shows that security by obscurity²⁰ is not a strategy to secure systems and only increases the effort to discredit a closed system. This has been known in principle since the 19th century²¹. Also the totally inadequate update process in medical telematics components²²shows that under such circumstances the number and criticality of known security vulnerabilities for a device can have serious consequences over time.

Manufacturer support for durable assets

For components with already expired or expiring manufacturer support

the manufacturer no longer informs about new vulnerabilities, even if they become known (so-called "end-of-life" components). Therefore, it is essential for operators to monitor whether manufacturer support is still offered for all components used.

The security status of the component is unknown without support and a "worst case assumption" is required. The operator now has the responsibility to take measures so that security vulnerabilities in the components cannot be exploited. For example, this can be enabled by access restrictions with network segmentation or additional authorization and authentication features in jump hosts. Further measures are described in the BSI Basic Protection Compendium, among others ²³.

The problem of end-of-life components can be circumvented in the field of open source. For example, in order to continue operating classic operating systems such as VAX/VMS or Solaris, OpenVMS²⁴and OpenSolaris have ²⁵been supplied with upgrades and new features by a community for years.

Cloud providers are showing a trend here, as they have been relying primarily on open source for security-relevant components such as operating systems, libraries, cloud²⁶, network components ²⁷and also standard hardware for ²⁸some time. This achieves independence from the underlying hardware and the manufacturer.

The Python example

The example of Python can be used to discuss very well which security requirements are placed on a community software and how security vulnerabilities affect it. Python is a programming language that covers all fields from microcontrollers²⁹to high performance computing. ³⁰As of August 2021, Python has moved up to #2 in the TIOBE Index³¹, just behind C and ahead of Java and C++. According to the IEEE's assessment, Python has been ranked #1 programming languages in the engineering field for five years ³². This is remarkable because Python emerged from an open source community and not from a corporate project, but like C++ from a university study³³. Python still has a non-proprietary community, unlike Java(Oracle, Red Hat, IBM), C++, DotNet (Microsoft), Go (Google), Rust (Mozilla) or NodeJS (NPM). A comprehensive analysis is already available for Java ³⁴.

Python in Critical Infrastructure

Python is the basis for most machine learning frameworks³⁵ and is used extensively in critical infrastructures, e.g. to predict energy consumption and price at the Leipzig Energy Exchange, but also to plan power grids in the network of the German Transmission System Operators and the European Transmission System Operators^{36 37}.

Based on the results of these predictions, transactions on the Leipzig Energy Exchange or circuits in the high-voltage grid above 110kV have been carried out manually up to now, and later also automatically. The effects of these calculations therefore have indirect and in the future also direct effects not only on electricity trading but also on operational technology³⁸, i.e. industrial control systems, and are thus considered critical infrastructures in the ³⁹sense of BSI and BBK ⁴⁰. The author is not aware of any systems whose failure would have more far-reaching consequences. A failure would have a direct impact on the economy and security in Germany and Europe.

Python Releases

Community support for releases is three years, with the exception of the last release of Python 2, version 2.7 with 10 years⁴¹ to facilitate the move to Python 3. The migration was extended again and again because the user community could not complete the migration.

Python Security

The Python ecosystem affects not only the programming language itself, but also the central library repository, the Python Package Index PyPi⁴² with hundreds of thousands of packages and millions of releases. Hidden in that set of packages is malware. The attackers try to exploit typos in the package name to initiate an installation. This method, called typosquatting⁴³is now being fended off ⁴⁴. This can be used to initiate all kinds of attacks, e.g. data theft ⁴⁵or further compromise of even critical systems.

Existing security projects

The problem is not unrecognized. Already within the Horizon 2020 project⁴⁶, there were efforts to investigate licensing and security compliance as a Fasten 2020 initiative⁴⁷. The initiative has so far not had any profound success, mainly because the breadth of the questions, fluctuations in the project and lack of anchoring in the community have not led to sustainability. Also, in the author's opinion, typosquatting cannot be detected with existing compliance patterns. The Google Insights⁴⁸ project has addressed Python but has not yet implemented it. In this case, it is only possible to identify relevant packages, automatically scan them with all their dependencies and qualify them as checked. In applications, packages secured in this way no longer need to be audited separately.

The Python Security Project⁴⁹ has fallen asleep because it was not continued after the end of Python 2.7.

An audit process that qualifies and signs individual projects⁵⁰ and a PyPi mirror⁵¹ with audited packages are obvious ways to distribute only relatively safe packages. The Python community itself has ⁵²made a proposal for a curated index, which is logically very similar to the idea of a mirror. A curated index is like a virtual mirror.

The bottleneck is clearly the low staffing, only one person works part-time paid for PyPi⁵³ . Implementing these ideas would easily require several full-time positions for development and administration.

Embedding in other projects

There are a number of similar projects into which these activities can be integrated. These include the Linux Foundation's⁵⁴ The Update Framework project ⁵⁵, which aims to make update systems secure. A Python version, updaterpy already exists ⁵⁶. Other projects, such as securing deployment pipelines through SigStore ⁵⁷, integration with the Open Security Foundation ⁵⁸and its project

ScoreCards⁵⁹ are highly recommended. With the appropriate equipment, newer projects such as Google Insights could also be supported.

Bringing it together under one organization that supports open source security along with the community is urgent. The contradiction between economic value and resources needed by the community is grotesque. On the side of value creation we have billions of benefits, with corresponding risk in case of failure, for a damage in the European Critical Infrastructure without further ado also a trillion risk ($10\ ^{12}$€), on the other hand a community that organizes the project itself and has created the Python Foundation, an organization that not only drives the development of the programming language into one of the most important languages for all kinds of applications, but also supports conferences with a budget in the low millions⁶⁰, compared to the revenue Firefox gets for selling search to Google⁶¹.

On the other hand, security is practically done on the side and or in the spare time. Funding in such as through the Core Infrastructure Initiative⁶² is urgently needed. Before the Heartbleed⁶³ security breach, OpenSSL⁶⁴ , the library responsible for encrypting most Internet connections through TLS⁶⁵, had a funding of a paltry $2,000 per year; afterwards, through industry donations, among other things, the amount jumped to a few $100,000 per year. The Core Infrastructure Initiative (CII)⁶⁶, a sub-organization of the Linux Foundation, is funding two full-time positions.

Containers and Kubernetes

The container ecosystem has ⁶⁷spawned an entire ecosystem since the proliferation of Docker in 2013⁶⁸ as a simplification of Linux Containers. Orchestration, i.e. managing the interplay of many containers connecting distributed microservices⁶⁹cloud native applications, is ⁷⁰now almost exclusively implemented with Kubernetes.⁷¹

Based on its own container system "Borg", Google decided in 2014⁷² to make Kubernetes available as open source. All cloud providers and well-known software companies offer products in the Kubernetes ecosystem, which are certified⁷³ by the Cloud Native Computing Foundation CNCF⁷⁴. The landscape⁷⁵ includes nearly a thousand projects. Behind the startups in this field venture capital investment in the range of nearly 20 billion. Kubernetes taps from the use of a lightweight variant K3S in IoT⁷⁶to the use in the military ⁷⁷and in the cloud ⁷⁸.

There are now cluster management systems, i.e. systems that manage clusters themselves again, that ⁷⁹can manage millions of clusters. Numerous German cloud providers have taken up the deployment of Kubernetes in their data centers as a business model and offer a version managed by them.⁸⁰

Likewise, the 5G mobile network is secured from the core to the cell towers with Kubernetes and containers⁸¹.

Gaia-X

The main idea of Gaia-X⁸² is to provide federated services⁸³ in an ecosystem. The Sovereign Cloud Stack⁸⁴ , a description of the necessary components and interfaces through an integration of Kubernetes in Openstack⁸⁵ is an exemplary reference architecture. It includes existing and future components of standardized sovereign cloud and container infrastructures that complement each other. The goal is to define, implement, and operate a fully open, federated, and interoperable platform.

What's notable about this is that the Kubernetes components in it are mandatory, but the implementations on Open Stack are optional ⁸⁶. All components are under open source licenses, Open Stack is largely ⁸⁷implemented in Python and would also directly benefit from securing the Python ecosystem.

Security in the Container Ecosystem

Due to rapid growth, complexity has grown to the point where the majority of users are already noticing security issues⁸⁸. The technical problems range from containers with malware, wrong decisions in the architecture of Kubernetes and misconfigurations in the application. Of particular concern is that many gaps often remain unaddressed years later. DockerHub⁸⁹is the most comprehensive and important registry ⁹⁰for containers. The insecurities that were complained about for images in 2015 ⁹¹are still present in 2020⁹²:

Almost 51% of the images had critical vulnerabilities that could be exploited and 68% of the images were vulnerable to varying degrees. 0.16% or 6432 of the images analyzed contained malware*.*

The cloud providers and manufacturers are shifting the responsibility to the operators and developers, who are completely overwhelmed with the task of securing in the first place.

There is a lack of sustainable, effective and applicable processes that deal with the detection and permanent elimination of security-relevant difficulties. Red Hat alone has a commercial offering with a container catalog⁹³that keeps important basic containers up to date and evaluates their security with a health index based on American school grades⁹⁴. Productive use requires a Red Hat subscription.

Plans for similar offerings for other distributions are not known. It ⁹⁵Debian-based distributions and Alpine⁹⁶. Debian-based systems, including Ubuntu, are the most common with almost 50%⁹⁷. Alpine containers are very widely used because they are optimized for size and are much smaller, sometimes a factor of 3, than other container distributions⁹⁸ and thus save resources in the cloud environment and can be deployed much faster. Typical automated processes in deployment pipelines involve thousands of images and, given the same resources, container processes built on Alpine are correspondingly faster. Alpine has a strict security policy that replaces even established tools and libraries to keep the attack surface as small as possible⁹⁹. For this reason, Alpine is also a very good candidate for reproducible builds¹⁰⁰.

Kubernetes security

Due to the complexity of Kubernetes, it is virtually impossible to securely set up and operate a Kubernetes cluster with reasonable effort¹⁰¹. Investigations with Aqua Security's Kubebench, which is based on the ¹⁰²CIS standard¹⁰³, almost always find security vulnerabilities that allow an attacker to take over a cluster¹⁰⁴. With appropriate Kubernetes knowledge, it is even possible to build a parasitic control plane controlled by the attacker that is not detected during normal operation ¹⁰⁵. The security depth, defined as the number of flaws that must coincide to allow a full compromise, is four.

1. Error in the application¹⁰⁶,

2. Access to the SecurityToken ¹⁰⁷

3. Local installation possibility,
   it is enough to be able to write into a temporary directory ¹⁰⁸

4. Ununderstood role-based access control ¹⁰⁹

Point 1 is a common error in applications¹¹⁰, point 2 is the default ! setting, point 3 is also almost always met, even in "secure" containers. Point 4 needs a common misconfiguration, often described on the Internet as part of an installation guide. These factors meet very often in practice.

Kubernetes offers numerous options for operating containers in a secure and hardened manner¹¹¹. Secure basic configuration at the container level through access controls¹¹² , network policies ¹¹³, or zero trust in the form of service meshes¹¹⁴ are already implemented in the form of open source projects ready for use. Unfortunately, the default setting is also insecure here¹¹⁵, although a secure setting is easily possible¹¹⁶. In order to master the further increased complexity, automated security checks are urgently needed, e.g. as an extension or addition to Kubebench (see above). Custom resources¹¹⁷are part of the extension options for Kubernetes, but unfortunately also susceptible to misconfiguration ¹¹⁸.

Side channel attacks

Another problem for the shared use of hardware resources are side-channel attacks on the CPU cache¹¹⁹. This attack is generally threatening to clouds and can also be exploited in classic virtualized systems . The major cloud providers use internal undisclosed customizations to prevent these attacks¹²⁰ , detection is actually not difficult¹²¹ . Previous defensive measures include disabling hyperthreading, which results in a loss of performance, or patches that only close the known gaps. However, new variants are discovered again and again, which cannot be patched with known methods¹²².

The right place to monitor processes is a dedicated control group for cache misses¹²³ and integration with Kubernetes¹²⁴ . For this, a corresponding Cgroup module would have to be written and brought into the Linux kernel¹²⁵.

Key Libraries

Cryptographic key libraries are important for securing the Internet transport layer¹²⁶especially OpenSSL ¹²⁷, but the other implementations like GNU TLS, LibreSSL or WolfSSL are also common¹²⁸.

Implementation errors

Despite its inclusion in the Open Source Security Foundation's program (see above), OpenSSL is often the victim of vulnerabilities¹²⁹, currently another vulnerability that arose from a lack of understanding of memory management¹³⁰. It is completely unacceptable that such vulnerabilities are still present in widely used libraries that have been in use for years.

Crypto library updates

The lifetime of cryptographic procedures is in the range of a few years. For no procedure can the BSI currently recommend use for more than five years¹³¹. This means that an algorithm that is discredited must be replaced. To date, there are no generally valid processes for this. While the transport layer only needs to be secured in the short term, signature processes are also based on cryptographic processes with a life cycle of several years. This is a problem for IoT in industrial plants in particular, but also for buildings.

The reason for this is on the one hand the long service life of industrial plants, which can be used contractually for up to 30 years, but in some cases are also in operation for 50 years. If the software is integrated into "smart" buildings in the future, the issue of safeguarding may also extend to buildings and their service life¹³².

Hashlists

The entire range of chained hashlists and blockchain¹³³ depends on the strength of the hash algorithms used. In all these cases, the integrity of the signature must also be ensured when a crypto algorithm is broken. This has happened several times for hash algorithms, most recently collisions have become easy in SHA1¹³⁴, so now at least SHA2 must be used. After finding a theoretical weakness, it took about a decade to finally make SHA1 unusable.

Asymmetric encryption

Similarly, asymmetric, public-private key, encryption and signature methods¹³⁵ . The basic assumption that it is mathematically hard to factorize the product of two prime numbers cannot be proven or disproven at present¹³⁶. Asymmetric encryption is used to replace a symmetric key to speed up for

For the theoretical use of quantum computers, there is already¹³⁷ a procedure with the Shore algorithm that ¹³⁸can break asymmetric keys of any length. Because asymmetric keys are the basis of secure communication, in this case the entire encryption of the Internet would be broken. Only the difficulties of building a working quantum computer that implements the Shore algorithm save us from the Quantum Cryptocalypse¹³⁹. When and if quantum computers will ever be usable is difficult to predict. The EU digital strategy expects a first European quantum computer in 2023 ¹⁴⁰. It is to be expected that the mass proliferation of quantum computers will also severely shake all crypto methods ¹⁴¹.

Because quantum computers are not universal computers, there have been efforts for several years to ¹⁴²advance the development of post quantum cryptography. In the meantime, there are many candidates that have been cryptographically investigated and can be rolled out. In most cases they are not slower than the known algorithms, but some of them need much more memory, so that they can only be used in the next generations of smart cards¹⁴³.

Therefore, it seems important to secure crypto processes, both with regard to existing security gaps as well as to threatening fundamental cuts by quantum computers or missing mathematical proofs for the security of the processes.

Common ground

What all these problems have in common is that they can be solved well with updates. Given the urgency of the problems, it is essential to detect, fix and patch security vulnerabilities, i.e. install a secure version as soon as possible.

This can only be achieved if this process can be automated as far as possible. Static analysis methods are standard¹⁴⁴. Google has been looking for security vulnerabilities in C, C++ and Java Virtual Machine based languages for a long time¹⁴⁵using fuzzing ¹⁴⁶, a method that checks source code by random input and ¹⁴⁷is already used in Germany by Bosch, Telekom, Continental and Deutsche Börse ¹⁴⁸. The wolfSSL library was checked for common errors¹⁴⁹. The method uses a lot of unused computing power. An academic project like Angr ¹⁵⁰, which analyzes the control flow more effectively, has had some spectacular successes, but is hardly used.

Secure deployment pipelines

Continuous Integration / Continuous Deployment is the process of continuously assembling components into an application¹⁵¹. It consists of several steps, from checking in the source code to rolling it out in production.

This way of rolling out new software under the keywords Continuous Integration¹⁵²and Continuous Delivery ¹⁵³or Continuous Deployment ¹⁵⁴has become standard in many modern system environments.

A simple deployment pipeline with elementary security checks is shown in the following picture from the commit of the source code to the rollout into production, i.e. the installation on the target platform.

More complex pipelines are easily possible by integrating more tests. For small changes, the pipeline can easily be run through completely in 20 minutes, from commit of the source code to deployment in production¹⁵⁵. The security relevant steps are highlighted in red and can run asynchronously, e.g. overnight. A more complex example with separation of the environments can be found at Gitlab ¹⁵⁶.

Importantly, the deployment pipeline is the software implementation of a DevSecOps¹⁵⁷ process, not simply a tool to be deployed¹⁵⁸. A full description of this process has been produced by the Cloud Native Computing Foundation in conjunction with the US Department of Defense.¹⁵⁹

This is a significant change that affects not only technology but all processes including the organizational structure itself, also referred to¹⁶⁰ as shift-left. The author estimates that implementing these processes in an established organization will take at least five years. The US National Institute of Standards stated this back in 2017 with regard to containers: tailor organizational operating culture and technical processes to enable the new way of developing, operating, and supporting applications in containers ¹⁶¹. There are immediate implications for the operational organization from the technical requirement. Since organizations generally resist change passively at first, this change process must be actively managed.

Efforts for the operation of build pipelines

Compared to the classical work in software development, the use of build pipelines represents a transition from code development to software engineering. The playful motivation of many open source developers is partly opposed by the strict requirements of software engineering. The integration into an automated environment with static code analysis and fuzzing means a change in the way of working, and not to be underestimated effort for the evaluation of the analysis results¹⁶². The transformation is not trivial for established projects and very difficult to accomplish without support¹⁶³.

The example of the established project GnuPG should explain this. The business model has produced G10 Code¹⁶⁴, a company that takes care of further development and support. Support and service contracts make GPG usable for classified documents¹⁶⁵ for customers from security authorities. The existing developers can also support this model well. However, there is a lack of resources for the maintenance of documentation, automatic code analysis, fuzzing of the code base, setting up deployment processes and further development. External audits take place regularly, but the incorporation of the results means a high additional effort in each case.

The GnuPG association¹⁶⁶ is well funded, but lacks resources for community management and external representation. In addition, the aging of the community is also a problem here¹⁶⁷.

An initial estimate shows that five to ten full-time positions would be useful here.

Supply Chain Attacks

All packages discussed here are part of the supply chain, which itself is a prime target of attacks ¹⁶⁸. ¹⁶⁹. Remedies by signing the single steps in the pipeline like by Sigstore ¹⁷⁰or the pipeline itself including auditing will become standard in the near future¹⁷¹ . Especially safety-critical code must be built from source code in trustworthy environments, ideally as a reproducible build, see above. Projects cannot afford this software engineering effort on a permanent basis as a part-time job.

Summary and measures

The establishment of an open source security fund seems urgently needed. On the one hand, there are billions in investments that depend on open source; on the other hand, there are no coherent and sustainable measures to safeguard it. For the usual EU research projects like Fasten 2020, there is funding in the range of a few million over three years. At the end of the project, a project report is produced, but there remains no organization to further develop the results and transfer them to the community. The main good approaches for secure DevSecOps processes have strong ties to the US military and should be complemented by a strong, civilian European initiative.

The fund should identify individual projects, communities, and ecosystems and work with maintainers to analyze vulnerabilities and provide resources to fix them. To do this, the most important components must be found and processes defined with the community that can be supported automatically. These processes should also be implemented and secured together.

For a community like the Python Foundation, this would mean several full-time positions due to the number of packages, accompanied by external expertise such as at least annual audits and the provision of curated subrepositories of PyPi. In addition, there would be an appropriately highly secured deployment pipeline. With project and community management, a higher single-digit million amount would need to be used annually. A sustainable investment is important, projects with a finite time horizon always fizzle out. Cooperation with partners should be sought and coordinated.

Other projects worth supporting

Corresponding projects for other programming languages like Ruby or the ecosystem of Owncloud or Nextcloud¹⁷² , video conferencing tools like Jitsi or Big Blue Button¹⁷³ would certainly lead to similar results, depending on the scope of the components. Another example is data center infrastructure, Software Defined Networks can be run securely on common high end hardware even with open source¹⁷⁴. Individual cloud providers force hardware suppliers to Linux based operating systems ¹⁷⁵or maintain their own infrastructure components derived from open source software. Support for Open Hardware and Open Infrastructure is also warranted with respect to deployment in the Gaia-X initiative ¹⁷⁶. Other ambitious projects such as the Linux Phone ¹⁷⁷or a modified Android are ¹⁷⁸aimed at the privacy of users, but it must be emphasised that their use also directly benefits the security of the economy.

Remarkable is the high competence that German and European providers have already built up, such as BISDN¹⁷⁹ in the high end carrier and network market, Nitrokey¹⁸⁰ in the field of encryption or K-9 Mail with email encryption¹⁸¹. K9 Mail has launched a funding call for maintenance. K-9 Mail is essentially the project of a single developer¹⁸² asking for a comparatively modest amount of funding, most of which has already been raised by the community. This project, with 600,000 downloads, actually depends on smaller companies, each with a hundred employees using K-9 Mail¹⁸³. When asked about funding, he can't imagine starting a company with his own staff. He would like to see a simple funding option for small open source, such as is offered in the USA by the Open Collective platform. ¹⁸⁴

Rating

The interviews conducted for this analysis show a high level of need for support. The communities very often signal, as in the GnuPG example, that they are well provided for¹⁸⁵, but on closer enquiry it becomes apparent that this statement is only true at a low level. The equipment of the projects, like GnuPG, Python or Alpine Linux is only sufficient for a minimal demand. If one asks for professional software development that includes automation, such as deployment pipelines, automatic security analyses, fuzzing or audits, there are deficits in many areas. The community makes up for this with overwhelming personal commitment, but at the price of burnout, which has also arrived in the open source communities. With the proper awareness, the symptoms can even often be observed¹⁸⁶.

All community projects signal that they would very much welcome further resources. Selected small projects by individual developers should be funded easily and without much bureaucracy, and it should also be possible to support freelance developers.

Strategic projects

There is also an urgent need to support strategic projects in the cloud area. This also includes edge computing¹⁸⁷, which will be a necessity in the future in the area of massively distributed systems, such as in smart energy¹⁸⁸ management and real-time industrial control¹⁸⁹. Edge computing, for example through K3S¹⁹⁰ is a lightweight Kubernetes, comes from cloud computing. In the whole area of cloud orchestration, even BSI is weak ¹⁹¹. Modern security architectures like Zero Trust¹⁹² , widespread adoption of multi factor authentication¹⁹³ , OpenID¹⁹⁴ and cheap signature services¹⁹⁵ for documents or certificates ACME¹⁹⁶ are needed in this area . Initiatives such as the Souvereign Cloud Stack¹⁹⁷ are seemingly well equipped via Gaia-X and funded projects, but also cannot fully cover this area. An integration of Chaos Security Engineering¹⁹⁸into this architecture is also recommended ¹⁹⁹.

Organization of an Open Source Security Fund

It must be the task of the fund to ensure sustainable and sufficient equipment for the supported projects. In addition to development, this includes reasonable automation, audits and professional communication and community management.

It is recommended that criteria be developed to select 10-20 communities, determine maturity and need, and create 5-10 full-time positions in each. More are not to be moved with a fund at the beginning.

In addition, it makes sense to support an equal number of smaller projects with 2-4 full-time positions. Small and very small projects, including individuals, should be given the opportunity to finance and manage themselves transparently with a structure like Open Collective.

The Fund's leadership positions must be filled by recognized members of the community. Just recently, the Chief Software Officer of the US Air Force resigned because the IT experience of the leadership level assigned to him was not sufficient²⁰⁰. It makes sense that the industry working on the projects should also be able to send representatives with the relevant knowledge. Under no circumstances should the projects be regarded as extended workbenches or even be given instructions.

Reallabs

All these technologies are ready for real use and have the highest technology readiness level²⁰¹, namely 9. It is therefore not a matter of research projects, but of widespread implementation, e.g. in Gaia-X. A federated development model "one for all" together with the members of the Gaia-X Foundation should be able to make the technology, which a single medium-sized provider cannot offer, available to the provider community across the board for all. It is also important here to have flanking support from the BSI, which concretizes and formalizes the requirements.

Dealing with security vulnerabilities

All security vulnerabilities must be published in a Responsible Disclosure²⁰² process. Under no circumstances may security authorities exploit vulnerabilities that have not yet been published. Trading in security vulnerabilities must be strictly prevented, preferably prohibited. All decisions in this regard must be made by the communities themselves, and political influence must be strictly excluded, because otherwise an important part of the security community will no longer be able to cooperate with the program.

The BSI is also not neutral enough²⁰³. The trust of the community in politics has been severely damaged by irrational and technically ill-founded decisions²⁰⁴. Open or covert influence would mean the withdrawal of important players from cooperation with the fund.

Internet bug bounties²⁰⁵ are not a good way to create sustainable security. They create a market that competes with the malware market²⁰⁶.

About the author

Dr. Thomas Fricke

1989 Installation of Unix Cluster, first Linux versions

1994 Doctorate in Aachen

1996-2005 Software developer in employment

since 2005 freelance consultant as software and system engineer

2006 various projects in the area of clouds, automation

Kubernetes since 2015

2013 Co-founder of Endocode AG (now Hoverture Deutschland AG), an open source and cloud service provider

2013-2021 Management Board, CTO and Supervisory Board at Endocode

Kubernetes Projects CoreOs, Google, SAP, Red Hat

2019-2020: Member of the Octarine (now VMWare) Technical Advisory Board.

Independent Cloud Security Architect for Kubernetes and OpenShift since 2017

2021 Co-founder of Resility GmBH (Security Chaos Engineering)

Energy and health sectors

Projects in the security sector for the Bundesdruckerei and mail providers

Honorary participation in the IT Planning Council

osssecurity@thomasfricke.de

---

• ← Previous Post
• Next Post →