Your cybersecurity team deserves a belated holiday gift, or maybe a few extra days off. While most of us were enjoying the festive year-end season, many cybersecurity professionals were hard at work trying to fix the Log4j vulnerability that became a major issue starting in late November. Instead of riding out the latter part of December in lock-down mode, IT professionals were scrambling to track down the extent of the issue and take all the necessary remediation steps. Lots of sleep and vacation time were lost in the process.\n\nEven if your company wasn\u2019t directly hit with a cyber incident caused by Log4j, it may have been impacted by a third-party vendor that was. Just in time for end-of-year reports, Kronos, which offers Human Resources products, detected \u201cunusual activity impacting UKG solutions using Kronos Private Cloud,\u201d which made the services unavailable. \n\nLog4j, the vulnerability found in Java\u2019s logging package, shows both the importance and weaknesses of open source software. In a warning, the FTC stated, \u201cThe Log4j vulnerability is part of a broader set of structural issues.\u202fIt is\u202fone of the thousands of unheralded\u202fbut critically important\u202fopen-source\u202fservices that are used across a near-innumerable variety of internet companies.\u202fThese projects\u202fare often created and maintained by volunteers, who don\u2019t\u202falways have adequate resources and personnel for incident response and proactive maintenance even as their projects are critical to the internet economy.\u201d\n\nThis particular vulnerability is not an isolated event, nor is it something new. The Equifax breach from several years ago, for example, was also due to an open source vulnerability. \n\nOpen source cyberattacks have increased by 650% between 2020 and 2021, and they will continue to increase because open source is relied on more than ever throughout the software supply chain. \n\nThreat actors targeting open source\u2019s popularity\n\nA lot of users are stuck in the mindset that viruses and vulnerabilities are found primarily on Windows machines and in Microsoft software. While this may have been the case a decade ago, we\u2019ve moved past that. And that is thanks to the popularity of Linux and open source, which is where hackers have moved, and now where some of the biggest, most damaging attacks we\u2019re seeing occur, sometimes in the most basic of software modules.\n\nSuch as the logging function. It\u2019s a pretty benign piece of code, but Log4j exploits poorly written code in the logging function used across thousands of products and embedded systems running Linux. This isn\u2019t a core element of the application; it creates logs. It is a basic feature that has become a backdoor for threats, taking a usually overlooked piece of code and hijacking it. Now it is everywhere, and thanks to the timing of its discovering, Log4j became the Grinch who stole a lot of Christmases and holiday celebrations. \n\nIt needs to serve as a warning of the risks involved in the open source supply chain. \n\nNot all code is created equal\n\nBecause open source is a collective software design, developers need to take responsibility for vulnerabilities and security flaws found in the code. That\u2019s the way it is supposed to work, in theory. In reality, not all code is created equal. Code scanners used by developers didn\u2019t identify the logging vulnerability until it was exploited. \n\nThe challenge for CISOs and CIOs using open source software within their organization is to come up with a way to put more scrutiny on greater elements of the code, going further into the weeds to find potential problems in unexpected places. The tools that are used need to evolve.\n\nMost computer science grads would rather write their own software than debug or find vulnerabilities in other developers\u2019 code. But it has to be done. CISOs and engineering executives now are going to ask why the logging function didn\u2019t get more scrutiny. After the next exploit of a forgotten code, the same question will come up: \u201cWhy didn\u2019t anyone think to look at this and fix it before it became a problem?\u201d (Answer: because everyone wants to work on more interesting problems.)\n\nThere needs to be a focus on open source security, at all levels of the code. It should be part of a set of checks and balances developers use to make sure no code is missed. It should also be partly automated, using AI to do the grunt work that humans would rather skip. Both parts, working in tandem, need to be used across all components of open source, especially when open source is used in critical infrastructure. \n\nIt's scary to think that something so basic, such an unimportant piece to the value of the overall product, has the ability to take down entire business operations. Yes, some are convinced open source is more secure than proprietary software because of the millions of people going over the code. Last December, we saw that those million pairs of eyes didn\u2019t see everything. Until the processes are in place for deep scans into the code, open source will continue to be a potential threat.