How to manage risk with open-source software

Open-source software might be free to use, but that doesn’t mean it’s free of obligations. With threats becoming more complex, security must be a top priority.

As the adoption of open-source software continues to grow rapidly, software development teams must go to ever greater lengths to manage risk. Low-code development platforms (LCDPs) have further added to that risk surface by bringing development outside the IT department, potentially resulting in a rise of shadow IT.

Despite this, the use of open-source libraries can deliver tremendous benefits to businesses by delivering specific functionalities without developers having to build them from scratch. Open source is also a natural fit for low code, especially at a time when at least 82% of firms consider custom app development outside IT important for driving growth. Moreover, Gartner predicts that two thirds of all business apps will be created using low-code platforms by 2024.

These developments are among the defining characteristics of modern digital transformation strategies. This is also why open source accounts for as much as 90% of all code in today’s web and cloud apps, with the average software application relying on at least 500 open-source dependencies. As such, the sheer size and proliferation of open source has made it a key target for threat actors, with inevitable vulnerabilities leading to a significant increase in open-source risk. The grouping of open source and low code can, potentially, further expand that risk surface by letting it grow far beyond the auspices of the IT department.

Of course, that’s not to say businesses should scale back their adoption of open-source and low-code – not at all. Together, these innovations are vital for helping businesses adapt and scale rapidly in an era of constant change. But as is always the case with any innovation, new risks arise that need to be managed from the outset. Thus any digital transformation must be secure by design as such that security becomes a driver of innovation rather than a barrier. Here’s what that means for open-source low-code software development:

What are the causes of open-source risk?

There are three principle sources of open-source risk: vulnerabilities, malware, and intellectual property issues. All of these risk areas must be considered when expanding your open-source footprint, especially in conjunction with low code development routinely happening outside of the IT department. Here’s a closer look at these key risk areas:

            Vulnerabilities

Vulnerabilities are a problem with any software, but for open-source libraries, vulnerabilities are public knowledge, which is generally a good thing. Vulnerabilities are often disclosed by principle contributors themselves or by organizations like the Open Web Application Security Project (OWASP). On the other hand, vulnerabilities may first be discovered and exploited by cybercriminals. Furthermore, vulnerabilities in open-source software can be more difficult to identify and patch, particularly if they are inherited from other libraries.

            Malware

Given the sheer size of the open-source attack surface, more sophisticated threat actors have taken to injecting malicious code into software itself. After all, open-source software is free for anyone to download, use, and modify, but that also means there’s nothing stopping hackers from doing the same. For example, attackers may create or modify libraries that appear to be safe but actually contain malicious code or might be injected with malicious code later on. Such malicious code injection is a common attack vector for ransomware.

            Licensing

Finally, the third key risk area of open-source software are intellectual property issues and the various legal ramifications around them. There are more than 200 open-source licenses, and many of them are not compatible with each other. Another potential complication is the rise of so-called copyleft, which requires you to release any software created using open-source libraries as open-source software itself. This effectively prevents you from using open-source libraries in proprietary software or for certain commercial purposes. Fortunately, Corteza uses the Apache License 2.0, which does not include a copyleft clause.

How can organizations mitigate open-source risk?

Mitigating risks to security, privacy, and compliance requires a strategic approach comprising several key steps that span the entire lifecycle of the software stack. While the blend of open-source software and low-code development offers unprecedented freedom, that freedom can also come at the cost of spiraling complexity, architectural disparity, and a rise of shadow IT. This is why a robust strategy is so important for proactively mitigating risk. Here’s a break-down of the main steps organizations need to take:

1. Create and enforce your security policies
   

Organizations must implement security policies that apply to anyone involved in development and maintenance of software. These policies should govern how developers in the company access and use open source libraries. Low code development naturally expands the user base into departments other than IT. However, while great for productivity and efficiency, those who lack technical expertise are also more likely to overlook potential security risks. A proven way around this is to have less experienced developers build apps in a sandbox environment that’s logically separated from the broader computing infrastructure. Then, only once these apps get through quality assurance tests in the IT department can they be approved for business use.

2. Know which open-source libraries are in use

With many software applications relying on dozens or even hundreds of open-source libraries, it can be easy to lose sight of the numerous components that make up your software stack. This leaves many potential single points of failure in the form of vulnerable libraries, APIs, and other components. Software dependencies generally account for the largest attack surfaces because of this. OWASP has already recognized this problem and added a regularly updated list of open-source components with known vulnerabilities to its website, but this can’t be relied on entirely. Developers should also use automated tools like dependency checkers and static code analysis. With the help of these tools, IT teams can build an up-to-date repository of all components that make up their software stacks and monitor them for potential vulnerabilities.

3. Have an established patch-management process
   

Arguably the greatest benefit of low code software development is that it saves time by letting non-programmers build business applications. However, the speed advantage can quickly end up being negated if end users have to constantly worry about things like patch management. As such, it’s vital that everyone who uses the platform be provided with the latest versions of all software, tools, and their various dependencies. Patch management itself doesn’t have to be complicated, and it should be something that the IT department can largely automate. This should involve the automated updating of vulnerable libraries while alerting security teams to the existence of any vulnerable libraries that have yet to have patches released for them.

4. Incorporate role-based access controls

Mitigating malware, social engineering scams, and most other threats requires a multilayered and granular approach to security. Data should always be encrypted both at rest and in transit, while access controls should ensure that end users only have access to the data they explicitly need to perform their roles. For example, a low-code integration platform brings all databases together under a single, centrally managed environment, but that doesn’t mean all data in said databases has to be made accessible to all. Like many platforms, Corteza has an role-based access control (RBAC) facility that allows administrators to define which roles have access to which resources. RBAC, along with other functions like zero-trust security and the principle of least privilege, should be integrated into the underlying architecture so that any low-code apps built on top of it are also secure.

Open-source software undeniably represents the future of computing, and the adoption of low-code development is further accelerating that revolution. That being said, the risks cannot be ignored, and while open source and low code present exciting business opportunities, they do not come without responsibilities. For this reason, any organization that relies on open-source software for its mission-critical operations seek third-party support to share the responsibility and the risks alike.

Planet Crust is the primary contributor to the open-source project Corteza, a low-code platform for building complex business applications. With our quality assurance and support services, you can reduce operational risk and protect your software against future threats. Get started for free today.