Open Source Security Is Still a Challenge
Virtually no piece of modern software is built from scratch entirely from the ground-up. In the same way that very few housebuilders would construct their own bricks, window, and door frames, it’s much cheaper and less time-consuming for builders to take building blocks that have already been created and put them together as required, augmenting them with bespoke elements where required. When it comes to software, the bricks equivalent in this analogy are “packages” or “modules” of code. Millions of such packages are available online in popular coding languages, with the majority of them coming from the open source community, found in places such as the immensely popular code repository Github.
The use of these open source building blocks results in what are referred to as dependencies. As the name suggests, these are software elements that rely on another program in order to work. While almost all software has dependencies of some sort, dependencies can nonetheless prove problematic. Some software users will sometimes refer to “dependency hell,” in which the various dependencies built into the software they want to use becomes troublesome. This dependency hell might, for example, mean having to download larger than expected software packages in order to run the program you want. Still other dependencies require a specific version of a piece of software. Dependencies may additionally conflict with one another, stopping software from working as it should.
There are, however, significantly worse open source dependency issues you can encounter — which is why it is essential that good DevSecOps practices are followed to ensure safe, high quality software.
Security risks in open source
By far the most dangerous aspect of open source software dependencies involves possible security risks when it comes to vulnerabilities and flaws. A recent survey of hundreds of open source contributors highlighted how security can be a neglected part of open source development. The study by the Laboratory for Innovation Science at Harvard University (LISH) and Linux Foundation’s Open Source Security Foundation (OpenSSF) found that the average free and open source software (FOSS) developer spends just 2.3% of their time focused on improving their code security. Reasons for failing to do so often focused on how improving code security was a “soul withering” or “insufferably boring” aspect of developing software, compared to areas like adding new features.
Regardless of the reason, however, it highlights a major weakness when it comes to relying on open source software. While open source means that the software code is available to scrutinize, many users will not have the ability to do this — and a surprising number of developers may opt not to for timesaving reasons.
With open source applications and components found in upward of 70% of modern application code, this represents a notable source of vulnerability.
Putting a weak window into a new house
Dependencies that have vulnerabilities transfer these across to the software that they are used in, the same way that — returning to the house-building analogy — a pre-made window or door frame that can be easily forced open represents a security risk to whichever house it is fitted in. Companies which therefore fail to do their due diligence when using open source packages or modules in their applications risk including major security vulnerabilities within products.
Vulnerabilities exploited by bad actors could have a wide range of negative consequences, from remote code execution to large scale data theft. Damage to organizations could range from the operational risks associated with business functions and processes to reputation risk to, potentially, regulatory risks when it comes to non-compliance with certain laws around topics like data protection.
While only a minority of vulnerabilities in open source projects will ever be weaponized by attackers, the potential impact of these attacks is such that people should do all they can to protect against them. After all, no-one goes on vacation and leaves their front door open because burglars represent a statistically small percentage of the population.
Manage security holes
Organizations therefore need to do a much better job of managing security holes with DevSecOps, a set of practices bringing together software development (the “Dev” part) and IT operations (“Ops”) — with security (“Sec”) firmly included in the middle. The DevSecOps model was developed to help address possible security vulnerabilities wherever they arise, and reduce the life cycle for systems development, resulting in high quality software.
Fortunately, the tools exist to help protect against open source security issues. Tools including Web Application Firewalls (WAF) and Runtime Application Self-Protection (RASP) are essential when it comes to detecting and rapidly blocking attempted exploitation of vulnerabilities by hackers. Other defense tools include API security systems, DDoS protection, and more. In doing so, customers can greatly increase the application security of systems, while reducing risk in both legacy and new applications — and all without negatively impacting the productivity of developers.
The post Open Source Security Is Still a Challenge appeared first on Cybers Guards.
