Article by Limor Wainstein

Open Source Software is an integral part of modern web/mobile applications.  Even parts of most proprietary software is built on top of OSS components. An Open Source software is usually developed within a public collaborative initiative. This is because OSS usually generates an increasingly more diverse potential of design perspective when compared to what a single organization can put together in a stand-alone effort.

However, your organization's CSO might not be comfortable with your choice of open-source components and convincing them requires a bit of an effort. This is usually justifiable because not all open-source components are secure and tested to run in a production environment.

Quick Overview

Let's have a quick look at a few facts that should give you an idea of how reliant developers are on open-source libraries.

1. Open-source libraries comprise of an upwards of 80% of most modern JavaScript software applications
2. JavaScript's npm repository currently comprises of 400,000 components that are downloaded more than 10 billion times annually.
3. These libraries/frameworks are almost always as secure as in-house developed components
4. That said, different dependencies between components can create unsuspected consequences at times.
5. Many OSS components have severe vulnerabilities with a vulnerability score as high as 10 and these components serve as the building blocks of modern applications.
   

Although freebies are great, as pointed out in #4 & #5, there are a few risks involved while using these components.  This post walks you through the top 5 things to improve the security of your open-source dependencies and thereby keep your CSO happy with your choice of components.

Use Industry Standard Best Practices For Security

Using well-known industry standard practices is a tried and test method to ensure your Open Source Software is free from vulnerabilities as much as possible. Some of these are listed below.

1. Maintain an inventory and upgrade your dependences to the latest versions when they're released
2. Keep a measure of how quickly your organization can update code once a vulnerability has been identified
3. Conduct a regular architecture and code level security audit
4. Encourage a behavior of reporting, and ideally fixing, vulnerabilities or related issues once identified
5. Establish a governance and review process related to Open Source contribution
6. Identify a set of policies and procedures to govern security and quality control with regard to Open Source Software components
7. Have an established and widely circulated process to report component vulnerabilities and contribution to patches
8. Verify that the code published by an Open Source code developer is the same that your organization is using
9. Ensure that the software used by your organization complies with the prescribed information assurance policy standards
10. Manually audit code reviews and automate frequent monitoring of CVE databases for identified vulnerabilities
    

For more tips on improving the security standards of your application, this article by WhiteSource should help you get started.

Create an Inventory of Open-Source Components

Having an inventory of the current components will help you in understanding the magnitude of the current risks. The best way to circumvent this is by creating a baseline inventory of all components.

There are a number of different ways to build an inventory, especially if you are looking at controlling the source or component repositories. One of the most reliable methods, though, is by leveraging the security testing that you would already have in place. Popular code-analysis tools have the facility of creating an inventory of components for you.

An up to date inventory can prove invaluable to your security team's ability to respond to a newly discovered vulnerability. This, in turn, allows you to focus and double your efforts on those applications which you know to already have a vulnerable component.

Map the Components to Already Known Vulnerabilities

Sources like the National Vulnerability Database or the NVD is helpful in providing information on publicly disclosed vulnerabilities in Open Source software. However, this comes with a caveat that not all vulnerabilities are reported to the NVD in a timely manner.

Therefore, the format of the NVD records often makes for difficult determination of which versions of a specific Open Source software component is affected by a particular vulnerability. For this reason, businesses and users should not rely solely on the NVD as their sole source of vulnerability information.

There are free and commercial tools that allow you to check your code for vulnerabilities and then you can that knowledge to isolate the issue to a particular dependency. The next plausible step would be patch the vulnerability by upgrading to the latest release or finding an alternative to the library. 

Enforce a Strict Security Policy and Educate Your Team

Perhaps the toughest challenge in addressing security concerns for organizations is knowing the right place to start and understanding where to focus attention to ensure the organization's compliance goals are met and exceeded. Security and Compliance teams need to set a stringent corporate compliance and security policy that explicitly lays out the component vulnerabilities and the required action at each stage. This is complemented by mentioning the desired timeframe for each report.

When it comes to developers, the priority to upgrade vulnerable software components can be raised and ask developers to mention the explicit policy in their requests. This goes a long way in helping businesses understand the potential trade-offs with improved time-to-market.

By establishing a policy that treats component vulnerabilities as important to the business as compared to other non-functional requirements like availability, ensures the organization is shielded from potential future hiccups. A policy such as this also helps to ensure that there is a certain amount of traceability between security needs and the regulations required by the industry. For a business, addressing a components risk can also potentially be a part of a customer's risk requirement.

In some cases, it is possible that developers are unaware of the need to keep a tab on the Open Source components they use for security patches etc, or the fact that some components may not be as secure as required. The good news is that it is relatively easy to educate developers to this need for protecting against injection vulnerabilities. Whether this developer education is delivered in 1x1 setup or by way of a more formal CBT course, it goes a long way toward addressing this problem.

Integrate Security Testing into your Integration Pipeline

Developing a baseline inventory is valuable as long as no changes or modifications are made to the software in use. As development teams continue using this software, an increasing number of changes are made to their applications. In this case, it is of utmost importance to update the inventory as well as the security picture.

Using CA Veracode simplifies this process by collecting related information while conducting a static analysis of your application's Open Source components in parallel. CA Veracode can also include Open Source components used by compiled libraries for which the organization or developer does not have a ready source code.

##

About the Author