The first thing to understand is that it is crucial to develop an open source security strategy. The implementation of a security framework that will enable a company to realise the benefits of using open source, without dramatically increasing risk, is crucial.
It’s important to understand that open source software risks revolve around three key areas, namely: visibility, security and governance. Understanding these factors and how they pervade open source security helps an enterprise formulate a stronger cyber security strategy.
Open source has emerged as one of the most essential tools for enterprise software development. Today, online libraries, modular components and pre-built code serve as the foundation for DevOps and other enterprise initiatives.
The challenges related to using open source code effectively and safely revolve around identifying new and different types of threats, risks and problems quickly, and then taking action to address vulnerabilities.
Organisations that wait for external fixes in the open source library, or believe that simply having more “eyes on the code” to spot problems, may be lulled into a false sense of security.
Consider this fact − mature AppSec programs have a 35% higher policy pass rate than new programs.
Being able to answer certain questions about the organisation’s coding practices in each of the three key areas is vital to creating a cyber security strategy that effectively protects its software. Let’s address specifics in these three key areas.
Visibility
The first question to ask is: where in the business are open source software components in use?
It’s crucial to have complete visibility into the organisation’s use of open source software and code. In the open source world, however, the problem is particularly difficult because companies often rely on libraries which, in turn, rely on other libraries that rely on other libraries (and so on and so forth).
It’s crucial to have complete visibility into the organisation’s use of open source software and code.
Therefore, even though a developer could be pulling in only a few open source libraries directly, those libraries could easily pull in hundreds of other open source libraries − inclusive of their vulnerabilities − with them.
Additionally, while one segment of a library may not be vulnerable, other subsets may be. It is critical to assess which ones are carrying vulnerabilities in order to know how to proceed.
The next question to ask is: what open source versions are in use? Add to that the need to understand the versions of the components being utilised. Are they the most recent? Are they older?
It’s a mistake to assume that the groups within the organisation automatically update to the most recent and secure versions of open source software. It’s also a mistake to assume they’re using the best tools to detect vulnerabilities.
When to check on the status of open source and how often development teams and other groups must check on patches and updates is another concern. On top of that, knowing the timeframe between coding flaw/vulnerability detection versus when it’s fixed is crucial.
Security
What patching policies are in place? It’s one thing to check on the status of open source updates, it’s another to ensure patches and updates take place in a timely manner. A clear policy with established procedures must be in place to oversee code patches and updates.
There is also the need to examine the vulnerability management approach and establish how the company intends to react in the event of an issue with open source code (or any other software, for that matter).
This framework can help the enterprise navigate the inevitable coding vulnerabilities that occur and address them in a prompt and effective manner.
Are there testing and validation systems in place? This is one of the most crucial aspects of application security. Knowing there is a problem with open source code is far less important than understanding how it will impact the business.
Governance
Licensing terms and conditions are critical issues, as the firm must fully understand the implications of copyright and licensing.
It’s important to know how the software can be used, how it can be modified, and how so-called “copyleft” licensing affects usage and modification. Also examine if the open source software used fits in with the organisation’s compliance policies.
This latter is a critical element of open source usage − it must be used in accordance with the company’s policies and procedures, augmented by effective controls that ensure compliance.
How does the organisation control whether insecure libraries make it into production? With the ability to integrate security into development tool chains, it is possible to stop development from proceeding when critically vulnerable libraries are causing an application to be exploitable.
Balancing the need for developers to quickly generate code and for security teams to lock down protections/avoid breaches are fundamental issues for all businesses. These two goals don’t have to be in conflict with each other. By rethinking and rewiring processes − and putting the right framework in place − it’s possible to detect problems and address them promptly.
In my next article I will reveal seven essential strategies for securing open source.
