Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

8/5/2020
02:00 PM
Robert Former
Robert Former
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

3 Tips for Securing Open Source Software

Maintaining myriad open source components can be tough. Here's how teams can begin to address open source security and continue to innovate.

Open source code is a part of roughly 99% of commercial codebases, according to research from Synopsys. Most developers prefer using open source software because of its flexibility and the pace of innovation within open source communities. However, the same study shows that 75% of audited codebases contain open source components with at least one known vulnerability. A primary culprit: The use of out-of-date software that's no longer maintained by the open source community. 

Many proprietary software companies still try to spread fear around increased open source risks, when, if properly managed, the opposite is true. A Purdue University study showed that open source communities have more eyes on security vulnerabilities and risks, and issue patches faster than proprietary software. Bug bounties are also becoming more prevalent in open source; for example, the European Commission offered funding in 2019 for 14 open source bug bounty programs.

Even so, the onus is often on users to install the most up-to-date security patches provided by open source communities. This can make security a challenge. Many engineering teams are spread too thinly to think about maintaining the myriad open source components within their technology stack. So how do organizations address open source security issues and continue to innovate at the same time?  

Here are three tips to get started.

Embrace Secure Software Development
Within many organizations, security and engineering teams share responsibility for security. That can make the issue of who "owns" open source security murky. More advanced teams embrace a secure software development lifecycle (SSDLC), where security becomes an integral part of every stage in the development process. This approach requires that engineers are trained in secure coding best-practices. Red teams pressure-test the systems engineers build to ensure that nothing slips through the cracks.

Regardless of who finds a vulnerability -- whether it's a software engineer, internal pentester, a white hat hacker, or otherwise -- it's a moral imperative to fix these bugs quickly and share fixes publicly with everyone in the open source community. The more eyes on open source software, the better everyone is protected against potential security threats.

Dedicate Time to Managing Risk 
The same open source security study cited above showed that 91% of codebases contained components that either were more than four years out of date or had seen no development activity in the last two years. Most active open source communities update software and regularly issue patches for known vulnerabilities. When major open source projects or their dependencies (the external code a project depends on) become outdated, communities sunset the software (also known as end-of-life) and offer a new version.

However, if no one internally updates the software, that's where the issues arise. The now- infamous Equifax breach is a prime example. In 2017, Equifax confirmed that hackers exploited a vulnerability in open-source Apache Struts. A patch for the vulnerability was issued in March, and hackers exploited the bug to break into Equifax servers two months later. 

To avoid these types of issues, organizations should dedicate 20% of engineering time to managing open source risks. This includes consistent patch and vulnerability management, as well as staying on top of end-of-life deadlines. With time and practice, this 20% may decrease, depending on internal risk assessments.

Embrace Automation Wherever Possible
Managed open source can help resource-constrained teams stay on top of open source security. Most commercial open source software vendors offer automation and/or services that can help customers maintain their open source components, alleviating the pressure on internal teams to manage everything themselves.

Many code repositories also offer ways to automate security checks for open source components. For example, GitHub's dependencies graph lets developers see all of the packages their software depends on, as well as any vulnerabilities detected within these dependencies. As of recently, developers can automate these patches.

Some leading-edge open source communities are taking the responsibility of security into their own hands by offering automatic security updates. For example, auto updates are a major initiative recently announced by the Drupal community.

To sum up, open source security thrives in an environment of radical transparency. Teams shouldn't wait for SecDevOps to become mainstream; instead they should embrace a SSDLC and actively work with red teams to identify and fix vulnerabilities. If companies are transparent about the bugs they find and fix them in the open, the entire community wins.

Related Content:

 

As chief information security officer and vice president of security, Robert Former leads the governance, risk, compliance and security practices at Acquia. Robert has most recently held roles at Pegasystems as senior director of compliance and at HP/HPE/Micro Focus as senior ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-20469
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has a SQL injection vulnerability. The vulnerability stems from the log_edit.php files failing to filter the csa_to_user parameter, remote attackers can exploit the vulnerability to obtain database sensitive information.
CVE-2020-20470
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has web site physical path leakage vulnerability.
CVE-2020-20471
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has an unauthorized access vulnerability in default_user_edit.php, remote attackers can exploit this vulnerability to escalate to admin privileges.
CVE-2020-20472
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has a sensitive information disclosure vulnerability. The if_get_addbook.php file does not have an authentication operation. Remote attackers can obtain username information for all users of the current site.
CVE-2020-20473
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has a SQL injection vulnerability. The vulnerability stems from the control_task.php, control_project.php, default_user.php files failing to filter the sort parameter. Remote attackers can exploit the vulnerability to obtain database sensitive information.