Securing open source software is about process, tools and developers – ITProPortal

Many successful cyberattacks stem from exploiting application vulnerabilities, and having stout network security may not be enough. Regardless of how strong network security may be, hackers can find ways in. Sometimes, they are inside an organizations network and do not exploit a vulnerability for many years. Attacks on vulnerable buffer overflows and code injections can be in the works for a very long time and lead to major data breaches, ransomware, or loss of service.

That leaves organizations with a more difficult task: protecting their systems at the software level. In this way, enterprises can minimize the damage hackers can cause once they have access to a given system. That process starts with securing software at the development level. This is already a topic increasingly high on the agenda for CIOs and CISOs.

In parallel, the vast majority of businesses use open-source software for their development projects because it gives them far more options and libraries that enable rapid innovation. Open source is not inherently any less secure than proprietary software, but there are some specific considerations. The good news is that while security risks are a fact of life, mitigating them through some achievable steps during software development is possible.

While security software tools have an essential role, organizational culture, management, and processes are critical to reducing vulnerabilities. Software development which these days almost always includes open source can rapidly become an unmanageable sprawl. Thats especially true for larger systems, where there are hundreds, sometimes thousands, of libraries (dependencies) and software being introduced by different individuals, often from different locations and without adequate communication between those parties. This is why software development should include compliance processes according to company policies, consistent service level agreements (SLAs), ongoing supervision and technical support (which may be better performed by a third party, since internal expertise is often limited), and a formal open-source selection process that weighs the health and proactive community support before onboarding open source packages.

One of the best aspects of open source is knowledge-sharing, and that extends to security. While one of the arguments against open source is that code is visible to anyone, likewise, so are the fixes to vulnerabilities. There are likely to be regular updates to address new vulnerabilities for open source software with solid community support. However, enterprises must proactively check for those regularly: the community will not reach out to them.

One valuable resource is the National Vulnerability Database (NVD), which is still relevant to developers worldwide while based in the USA. This repository of standards-based vulnerability management data includes databases of security checklist references, security-related software flaws, misconfigurations, and impact metrics. Associated with each vulnerability, there is a Common Vulnerability Exposure (CVE), which aims to identify, define, and catalog publicly disclosed software vulnerabilities based on a Common Vulnerability Scoring System (CVSS). This helps security professionals and developers prioritize the most severe vulnerabilities carrying critical and higher risk.

All these resources are beneficial to developers, but they rely on known vulnerabilities being reported. While that does happen a lot, it is not universal (by the way, that applies to proprietary software, where there is even less information sharing). There is reliance on developers to think about sharing information about the vulnerabilities they have discovered and subsequently fixed.

Furthermore, if a company is successfully exploited and a major data breach occurs, they are currently under no obligation to report the details of how that was achieved. Compare this to the aerospace industry, where there would be a detailed review and analysis of a plane crash. Thus, software security needs its own black box disclosure and accountability. Security attacks can have serious consequences outside the digital world, such as recent breaches leading to the unavailability of power or fuel.

All this points towards a change in attitude towards security, and fortunately, that is beginning to happen. For instance, the Open Source Security Foundation is carrying out some great work and has recently received a $10 million annual commitment from companies including Amazon, Google, Facebook, Microsoft, and others. The more software developers and vendors can get on board with them and provide support, the better the opportunities to protect software in the future, with actions such as vulnerability disclosures and the creation of software bill of materials (BOMs).

Internally, there also needs to be a greater focus on training developers to be more security-aware. Conventionally, security was not part of the developers role: theirs is to create functional code. That must and is starting to change, particularly with the advent of movements such as Shift Left and DevSecOps, whereby testing and security scanning are given more importance early in the development life cycle. However, to reduce the impact on developer workload, those processes must be automated as much as possible. Automation also helps reduce the risk of manual error and keep up with the sheer speed of many projects. Testing and monitoring should enhance, not slow down, development.

Several relevant types of tools are available, both commercial and open-source, including static application security testing (SAST), which involves inspecting and analyzing code even while it is being written to find and stop flaws going into production. SAST tools are like having a security expert looking over a developers shoulder, keeping an eye on potential flaws and vulnerabilities. SAST tools can also assist with compliance with standards.

Perhaps more familiar to many people will be dynamic application security testing (DAST), whereby tests are performed by attacking a running web application from the outside. Testing through the web front-end helps to identify potential security vulnerabilities or architectural weaknesses.

For open source security, software composition analysis (SCA) is a very useful security tool, with several good commercial and open source options. With SCA, the open-source libraries (dependencies) used in the source code of applications are analyzed. By identifying direct dependencies and transitive dependencies, the tool cross-checks against a vulnerability database such as the NVD to determine the existence of vulnerabilities (CVEs) and corresponding CVSS score.

There are, of course, well-established security processes, such as penetration-testing, whereby a white hat hacker tries to get into an organization's networks and applications to discover potential exploits and vulnerabilities. These have a lot of benefits, but they are not enough on their own. It is like having locks on a door: the more, the better but eventually, a talented thief will find a way in. What matters is making sure that when they do, valuable assets are not within their reach.

Whether open-source or proprietary, tackling application security is a complex challenge. For companies who want to improve that security, streamlining processes, instilling cultural attitudes, adding security training, and using the right tools is a good place to start.

Javier Perez, Chief Evangelist for Open Source and API Management, Perforce Software

Excerpt from:
Securing open source software is about process, tools and developers - ITProPortal