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.

Comments
Open Source Developers Still Not Interested in Secure Coding
Newest First  |  Oldest First  |  Threaded View
lancop
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...


Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Incorporating a Prevention Mindset into Threat Detection and Response
Threat detection and response systems, by definition, are reactive because they have to wait for damage to be done before finding the attack. With a prevention-mindset, security teams can proactively anticipate the attacker's next move, rather than reacting to specific threats or trying to detect the latest techniques in real-time. The report covers areas enterprises should focus on: What positive response looks like. Improving security hygiene. Combining preventive actions with red team efforts.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-1813
PUBLISHED: 2022-05-22
OS Command Injection in GitHub repository yogeshojha/rengine prior to 1.2.0.
CVE-2022-1809
PUBLISHED: 2022-05-21
Access of Uninitialized Pointer in GitHub repository radareorg/radare2 prior to 5.7.0.
CVE-2022-31267
PUBLISHED: 2022-05-21
Gitblit 1.9.2 allows privilege escalation via the Config User Service: a control character can be placed in a profile data field, such as an emailAddress%3Atext '[email protected]\n\trole = "#admin"' value.
CVE-2022-31268
PUBLISHED: 2022-05-21
A Path Traversal vulnerability in Gitblit 1.9.3 can lead to reading website files via /resources//../ (e.g., followed by a WEB-INF or META-INF pathname).
CVE-2022-31264
PUBLISHED: 2022-05-21
Solana solana_rbpf before 0.2.29 has an addition integer overflow via invalid ELF program headers. elf.rs has a panic via a malformed eBPF program.