![]() When you have a network that isn't isolated within a single area, you need assistance to manage it remotely. ![]() SNMP remote monitoring is a vital function for any company with a large network. But making no contribution at all is an option that the industry can’t afford.Selecting the Right SNMP Remote Monitoring Equipment for Your Network Options include either contributing to open source as it was originally intended, by improving the code and publishing it for others, or employing experts to manage the OSS code and debug it as required. “It’s open-source, go change it!” is a statement you will hear a lot from the open-source community, and it highlights a key fact: Expecting good security levels for free while others contribute time, effort or money to the equation is not reasonable or sustainable. In these business-critical scenarios it is sometimes more elegant to employ an expert to backport the fix and maintain a version for a longer period than the wider community supports. If your mission-critical solution relies on a specific software version, updating may mean losing functionality and/or requiring unscheduled downtime. Paying someone to probe the security of your open-source solutions can help plug this gap, while you continue to enjoy the wider benefits of open source.Īnother challenge with OSS updates and patches is that they need to be applied to secure systems, a fact that can present specific challenges. Relying exclusively on a volunteer community to identify vulnerabilities, report and fix them is a bet with long odds. The result of Squires adding an infinite loop to colors.js and faker.js was widespread failure of NPMs that included his code, prompting a scramble to roll back the changes to safe versions (colors.js v1.40 and faker.js v5.5.3). The two simple JavaScript libraries were baked into thousands of Node Package Manager (NPM) programs, which in turn were downloaded multiple millions of times every week – till their creator, JavaScript developer Marak Squires, deliberately broke them for reasons unknown. Indeed, 70% of the average program today is made of open-source software, with the number of dependencies varying widely by language: a mere 25 dependencies per project in Python’s case, but a massive 174 per project in the case of JavaScript.Īs the situation with the colors.js and faker.js packages demonstrated earlier this year, problems with dependencies can have real-world impact on enterprise software. Due to the vast amount of OSS code in active use, examples of active security issues with open source are legion. The reality is that these potential security issues are not a distant, imaginary problem, or industry FUD that can be easily ignored in the real world. This is the often-ignored side of OSS security: while the good guys can hunt for bugs and vulnerabilities in the code to fix them, the bad guys can hunt for those same bugs to exploit them. This is a fact highlighted by the report, which found that the average number of days to fix a vulnerability is currently 97.8 – leaving enterprises running that software open to attacks for many months. Even worse: only 49% of organizations have an open-source security policy.Įven if a security issue is found in open-source software, it does not mean someone will fix it. ![]() That’s 15,000+ lines of code per active developer!Ī recent report from the Linux Foundation found that the average number of outstanding critical vulnerabilities in an application is 5.1, and that 41% of organizations are not confident in their open source software security. For example: the Linux kernel project has 30+ million lines of code, hundreds of bugs that need to be fixed, and almost 2000 active developers working on it. This can be a challenge even for larger open-source projects. There are widely used open-source projects that are being maintained by only a small number of engineers, and those engineers cannot be entirely altruistic with their contributions of time and effort – they, too, have bills to pay. The challenge of OSS security is that just because everyone can look at the source code, it does not mean anyone will. After all, why would we continuously try and write code that solves problems that others have already solved? Why not share the knowledge and gradually and incrementally improve existing open-source solutions? These egalitarian ideals are arguably central to civilization itself – never mind software – but also contain underlying tensions that have been a challenge for generations. ![]() Open-source software (OSS) has a lot of advocates.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |