Open-source code: how to stay safe while evolving rapidly

Open source has transformed the software world, dramatically reducing the cost of introducing new technologies by enabling wide reuse across products and industries. However, organizations pulling their code from open source will often find themselves in scenarios where they have created a final Frankenstein-like artifact, with extremely fragmented origins.

This can cause problems when organizations don’t consider long-term support for the open source libraries they rely on and, at worst, create security issues within their applications. The series of log4j vulnerabilities at the end of 2021 is a perfect example. Organizations should take the time to carefully consider their approach to supply chain security in order to prepare for possible future security incidents and take full advantage of open source.

Open source isn’t really free

Code derived from multiple sources poses unique security issues that organizations aren’t always equipped to handle — or even aware of. The supply chain can be incredibly complex, consisting of a massive tree of open source dependencies, all updated regularly. IT teams typically don’t audit every line of code in their system when upstream open source software is updated or changed. With a web of dependencies, constant change, and the lack of thorough assessments by IT teams, external security threats should be of great concern, despite their origins outside the organization.

Regardless of who is initially responsible for bugs, organizations are held accountable when they ship software that includes open source code plagued by vulnerabilities. Without processes in place to verify open source inclusion and updates, organizations will continue to fall into the trap of using open source components without understanding the risks involved. Additionally, as the world of software continues to evolve, new technologies such as containerization will put a secure position even further out of reach.

When releasing a vulnerability in an open source project, organizations can be overwhelmed with the burden of auditing updates for all relevant software updates under potentially tight timelines. This can devastate developer productivity, as subject matter experts must choose to either audit thousands of lines of code, or blindly accept the latest version of their dependencies, or both, at the risk of introducing bugs. in the process.

Despite the risk factors, there are ways for organizations to effectively secure and protect their use of open source code. With a better understanding of dependencies and the proper checks and balances in place to mitigate risk, teams can begin to feel secure in their use of open source and reap its full benefits.

Make a difference to keep open source secure

IT managers must first and foremost establish policies focused on mitigating threats and risks before starting projects. Policies that ensure review and approval of new open source dependencies, as well as regular updates to those dependencies are essential to reduce the risk of future disaster scenarios. This has to be done with development buy-in, of course – developers want to use the latest and greatest technology, and if they can’t use the best tool for the job, they won’t be happy developers. – but a minimal baseline policy can help pinpoint the problem. Inventory and regular maintenance are key here, because you can’t fix what you’re not aware of, and it’s much easier to update a dependency from last week’s build than to put updated a version of the last decade.

Once these guidelines are in place, development should take the initiative to implement procedures to meet policy requirements. This is where DevSecOps comes in: bringing a software development mindset to solving security issues can reduce costs and help break down barriers within organizations.

First, teams need to understand what software is deployed in their environments, assuming they haven’t documented a BOM from the start. This can be difficult because there are many layers of dependencies in a modern software stack. For example, most container vulnerability scanners are limited to packages installed through the operating system’s package manager (e.g. apt or yum). By design, this lacks many dependencies such as statically linked binaries, manually installed packages, programming language dependencies, etc.

Second, teams should implement processes to keep dependencies up to date. While this may strain developers’ time and resources, this ongoing cost is surely far less than what would be required of teams during an unexpected breach – and more financially secure as well.

Alternatively, organizations that lack the development resources to inventory dependencies and continuously monitor vulnerabilities should reduce their security footprint by using platform-as-a-service (PaaS) products from cloud service providers. For example, purchasing a database-as-a-service (DBaaS) product rather than self-hosting a PostgreSQLName clustering on a set of virtual machines can eliminate an organization’s liability for a very large stack of dependencies. This can allow teams to divert attention from the mundane “undifferentiated heavy lifting” and towards innovation and business value.

Take the good out of the box and seal the bad

Organizations can – and should – take advantage of the open source community’s rich rewards for great code and innovative solutions. But this must be accompanied by thought and planning for the potential security risks at hand. IT leadership teams can significantly mitigate supply chain risk when they take appropriate steps to assess and guide the inclusion of open source dependencies. Preparing in advance can bring peace of mind today, keep risks at bay, and encourage developer innovation.

Margie D. Carlisle