How to develop a defensive plan for your open-source software project

Open-source software is becoming more and more popular. Recent research by Forrester Research found that the open-source model is now pre-eminent in application development and that custom-written code now often constitutes only 10 to 20 percent of most applications.

As the open-source model becomes a de-facto standard for developers, concerns about its security have become more prominent. As CIO stated back in 2017, “the speed of open source deployment by enterprises everywhere puts software security into question.” This has been a debate that has perennially resurfaced over the past decade, with various commentators claiming either that open source is more secure than proprietary code or less so.

In reality, open-source code can be made as secure as the most rigorously developed proprietary code, but in order to achieve this, developers need to put in place an equally rigorous defensive plan. This is critical not only for preventing security weaknesses in code snippets but also for your own sanity: it’s difficult to avoid burnout if you are constantly called to fix the damage caused by hacks.

In this article, we’ll run through four core principles that should form the base of any defensive plan for open source projects.

1. Inventory your repositories

Despite the frequency with which open source code is used, the fact remains that many developers are unable to list all of the open-source components they currently employ. Since you can’t secure what you’re not tracking, the first step in defending your systems must be a thorough inventory of all the open-source code you are running. When doing this inventory, you should also remember that the components you are using have dependencies, so it’s important to conduct an inventory that covers these as well.

While this level of research might seem like overkill in regard to, say, a beloved Solitaire game, it takes on greater concern when considering the technical underpinning of common payment processing features, which have become reliant on an increasingly higher level of code in recent years. The same goes for an appointment, billing, CRM software, and many others. When flawed code endangers the bottom line or functioning of a small business, it becomes more serious in a hurry.

This inventory should take into account every aspect of your software. At a very basic level, many applications make use of open source databases, but the very centrality of these systems to your software makes this easy to overlook. At the other end of your stack, client-focused systems like appointment reminder software often contain open source components, even where these packages are proprietary. Your inventory should thoroughly assess each part of your software for even the smallest piece of open source code. 

2. Map key vulnerabilities

Armed with a list of all the open-source code you are using, you can use public sources such as the National Vulnerability Database (NVD) to gather information on the known vulnerabilities in these components. Just be aware that not all security issues are reported to the NVD in a timely manner, so you shouldn’t rely on it as your only source of information.

You can complement public systems like the NVD with more investigative techniques, making use of forums and industry reports to find further vulnerability reports. There is even much to be learned from high-profile data breaches as reported in the media since even huge companies can fall foul of open source vulnerabilities.

3. Usage policies 

Usage policies are very important for securing open-source code, but they are often forgotten about by developers. Usage policies are a key part of the documentation for your software and should contain detailed information on which other components you have tested it with. They can help users to keep components secure by ensuring that they don’t use them with other, untested pieces of software. Ideally, developers should liaise closely with management to devise rigorous, secure usage policies for every piece of software that is released, and these should specifically cover access and authentication protocols.

Of course, in an open-source environment, you can’t stop your end-users from using software alongside yours or replacing your recommended components with others. However, you should also recognize that employees often seek to circumvent security measures by using unapproved extra software. Sometimes these pieces of software are straight software scams, and sometimes they are merely insecure. If you’ve gone to great lengths to ensure the security of your own software, you should also encourage end-users to use components that you have tested for security.

4. Continuous monitoring 

Whilst the list of common software and hardware vulnerabilities is, in itself, quite short, this belies the raw number of vulnerabilities that are identified every year. There are more than 3600 individual instances of vulnerabilities of the open-source variety discovered every year: that’s almost 100 per day. Because of this, you need to build continuous monitoring into your defensive plan. Continuous monitoring can mean a variety of things to different developers and companies. 

Some will make use of a dedicated piece of software that scans bulletins for new vulnerabilities. Others will simply check the news every week. In all cases, however, continuous monitoring means that you need a system to thoroughly catch all vulnerabilities as they arise, even for software that was shipped years ago.

In fact, monitoring should occur both during software development, but also—critically—after a piece of software has been released. Patching new vulnerabilities as they arise is as important as avoiding them during development. Monitoring should also take place in liaison with the management team and should form an integral part of product development processes. While your business development team might be great at ideating variations of the latest popular online businesses, it likely has little idea how these affect the security of the software you already have in place (or in development). A risk assessment of each new product, before it is launched, can help to avoid problems later down the line.

Learning to learn

All of the steps above are critical components of any defensive plan for open source software development. Furthermore, they do not apply only to dev and security teams. Effective defensive plans require input from every organizational level: not just developers, but also management and end-users. 

This kind of organizational integration is a critical part of cybersecurity in 2020 because it allows security to be built into every stage of the conceptualization, development, and ongoing maintenance of every piece of software. That’s why organizational liaison of this type is an important component of DevSecOps, a relatively new approach to cybersecurity that attempts to combine development processes with operational business functions.

That might be a major change to the way that you work at the moment. But, as we’ve pointed out before, being a developer in 2020 is all about embracing change, and being agile. In other words, it’s about learning how to learn.