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

12/8/2020
05:50 PM
50%
50%

Open Source Developers Still Not Interested in Secure Coding

Security and development are still two different worlds, with open source developers resistant to spending time finding and fixing vulnerabilities.

Coding new features, improving tools, and working on new ideas are the top 3 activities that motivate open-source developers to continue coding. At the bottom of the list? Security.

In a survey of 603 free and open source software (FOSS) contributors, the Linux Foundation's Open Source Security Foundation (OpenSSF) and the Laboratory for Innovation Science at Harvard University (LISH) discovered that the average FOSS developer only spent 2.3% of their time on improving the security of their code. While the contributors expressed the desire to spend significantly more time on their top 3 activities, they did not feel compelled to spend additional time on security, according to the 2020 FOSS Contributor Study released this week.

Related Content:

Open Source Flaws Take Years to Find But Just a Month to Fix

The Changing Face of Threat Intelligence

New on The Edge: BECs and EACs: What's the Difference?

Developers' opinions of security and secure coding — calling it a "soul-withering chore" and an "insufferably boring procedural hinderance" —  highlight that companies who want to harden their applications against attacks have a significant gap between those desires and getting their own developers on board, says Frank Nagle, a Harvard Business School professor and contributing author to the report analyzing the survey results.

"It appears that this 'shifting left' has not fully pervaded the minds of FOSS developers," he says. "Although we did not specifically ask whether developers think security is important, they likely understand that is a concern, but believe others should deal with it."

Open source components and applications account for more than 70% of the code included in modern applications, making the security of those components of paramount concern. Yet, open source developers are more focused on working on the latest tools and implementing their own priorities, according to the 2020 FOSS Contributor Survey report.

The perception that open source components often have unresolved vulnerabilities has led to more companies implementing a variety of security checks and procedures, including more than half — 55% — requiring regular patches and updates, 49% permitting and blocking specific components, and 47% using a manual review process to allow specific components, according to the DevSecOps Practices and Open Source Management report published by software security firm Synopsys this week. 

Companies' approaches to open source software continues to be uneven, says Tim Mackey, principal security strategist for Synopsys. 

"One key takeaway from this report is that greater automation is required to inventory open source usage," he says. "From there, businesses need to develop and implement processes to benefit from all the innovation occurring within open source communities."

Companies are still figuring out how to integrate security into their DevOps pipelines, according to the Synopsys survey. While a third of companies consider their approach to DevSecOps to be mature, another 40% only have limited implementations or pilots, and the remaining 27% are still researching or not planning to follow DevSecOps.

Media coverage of specific open source vulnerabilities and the general issue of open source security has prompted many companies to put more stringent controls in place and migrate to better-maintained open source projects, according to Synopsys's report. 

However, media coverage of a particular threat is not a good indicator of how dangerous a vulnerability or flawed component may be, says Synopsys's Mackey.

"What we should recognize is that media coverage will cause non-technical people to start asking questions," he says. "Those non-technical people want to ensure that their business isn't in the news for a similar event and will start to ask questions about how open source security is managed within their organization. Having a well-defined process, one which is able to quickly identify the impact of a new vulnerability, goes a long way to calming concerns."

The FOSS Contributor Survey suggests that companies should start with a focus on secure code as one of the requirements of the business. Writing simpler, well-commented code, automating tests and security checks, and using memory-safe languages can minimize coding mistakes. 

"As we see an increasing number of companies actively paying their employees to work on FOSS projects, these employers should incentivize their employees to both write secure code from the beginning, and also spend some time helping find and address existing security vulnerabilities," Harvard University's Nagle says.

Companies that do not perform their due diligence could find that the open source building blocks of their applications introduced security vulnerabilities into their products. On Dec. 8, for example, network-security firm Forescout disclosed vulnerabilities in four different open source TCP network stacks installed on millions of connected devices and routers.

The Open Software Security Foundation recommended that organizations who pay employees to contribute to open source projects should also contribute to security audits and have those employees rewrite portions or components of those libraries. Part of such a rewrite could be to switch to a memory-safe language, the FOSS Contributor Survey report said.

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
lancop
50%
50%
lancop,
User Rank: Moderator
12/10/2020 | 6:12:57 PM
FOSS developers don't get paid for secure coding
This doesn't surprise me, as even full-time paid commercial programmers produce code that is riddled with security vulnerabilities and insecure coding practices. They are much more security conscious than FOSS programmers, but still not always at the security level that would be desired in organizations with serious data privacy concerns.

I don't expect this situation to change whatsoever, so I believe that the workaround is for security conscious users & organizations to assume that FOSS software is highly insecure and should only be run on untrusted PC's in untrusted network subnets. By this I mean that a computer network should be divided into isolated & firewalled subnets that are separated into high security (trusted), medium security (production), low security (untrusted) and public (totally untrusted) zones that never co-mingle their network traffic. That way security breaches in untrusted subnets are irrelevant to the organization because no valuable private information ever exists in them – they are only for public facing insecure tasks with no privacy value.

That, actually, makes sense for those of us embracing open source – why would we need data security privacy on a computer devoted to creating FOSS & FOSH content that we'll be donating to the global commons anyway? Sure, we might take basic security precautions, but nothing beyond that is worth our time & effort. Especially if the FOSS we're using is full of unpatched security holes anyway...
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
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-2021-27180
PUBLISHED: 2021-04-14
An issue was discovered in MDaemon before 20.0.4. There is Reflected XSS in Webmail (aka WorldClient). It can be exploited via a GET request. It allows performing any action with the privileges of the attacked user.
CVE-2021-27181
PUBLISHED: 2021-04-14
An issue was discovered in MDaemon before 20.0.4. Remote Administration allows an attacker to perform a fixation of the anti-CSRF token. In order to exploit this issue, the user has to click on a malicious URL provided by the attacker and successfully authenticate into the application. Having the va...
CVE-2021-27182
PUBLISHED: 2021-04-14
An issue was discovered in MDaemon before 20.0.4. There is an IFRAME injection vulnerability in Webmail (aka WorldClient). It can be exploited via an email message. It allows an attacker to perform any action with the privileges of the attacked user.
CVE-2021-27183
PUBLISHED: 2021-04-14
An issue was discovered in MDaemon before 20.0.4. Administrators can use Remote Administration to exploit an Arbitrary File Write vulnerability. An attacker is able to create new files in any location of the filesystem, or he may be able to modify existing files. This vulnerability may directly lead...
CVE-2021-29449
PUBLISHED: 2021-04-14
Pi-hole is a Linux network-level advertisement and Internet tracker blocking application. Multiple privilege escalation vulnerabilities were discovered in version 5.2.4 of Pi-hole core. See the referenced GitHub security advisory for details.