devopsy.kinsta.cloud

Tag: Log4J vulnerability

  • GitBOM Tool Automatically Identifies Software Artifact Components

    GitBOM Tool Automatically Identifies Software Artifact Components

    An open source GitBOM tool, discussed at the Open Source Summit Europe conference this week, can automatically track every source code file incorporated into each built artifact.

    Nell Shamrell-Harrington, a principal software engineer for Microsoft, told conference attendees via a video link that the GitBOM tool, based on a compact Artifact Dependency Graph (ADG) technology, can verify which artifacts are being used across any programming languages, environments and packaging formats without any effort made by developers. To do this, GitBOM repurposes the directed acyclic graph made available in Git version control software.

    All that is required is for GitBOM identifier—a unique, content-addressable reference—to be inserted into the artifact at build time. That identifier then creates a Gitoid that can be consumed by ADG, Shamrell-Harrington said. Each Gitoid then views an artifact as a binary large object (BLOB) through which of all the components that went into it, including source files, dependencies and object files can be identified.

    Support is also included for the Software Package Data Exchange 2.3 format for sharing software bill of material (SBOM) information discovered by GitBOM.

    GitBOM can also detect potential vulnerabilities at runtime, regardless of the depth, in every software artifact that might be impacted to make it simpler for IT teams to remediate issues. That approach makes it simpler to find, for example, every instance of the Log4j vulnerability that might exist in an application environment. GitBOM only includes the minimum information required to create a fingerprint to enable efficient runtime scanning for a known-vulnerable artifact.

    The goal is not to replace SBOM tools but rather to make it easier for them to collect data about artifacts in the most frictionless way possible for developers, Shamrell-Harrington said. GitBOM enables any metadata to be linked to a specific set of corresponding software artifacts to make it easier to discover exactly how they were constructed. Artifact IDs can then be extended to produce GitBOM documents that can be consumed by other build tools.

    GitBOM is being shared at a time when the focus on securing software supply chains has never been higher. In the wake of the Log4j vulnerability disclosure, the Biden administration is requiring every federal agency to construct SBOMs to enable developers to find instances of vulnerable software components. Most large enterprise organizations are generally following suit.

    However, collecting SBOMs is only the first part of a bigger challenge. Organizations will then need to acquire tools to analyze SBOMs and provide feedback to application developers. In effect, eventually, organizations will be able to accept or reject software based on the components being used to create it. Armed with those insights, developers then have the option to upgrade software components to bring applications in line with any policy an organization defines.

    It may be a while before SBOMs proliferate across IT organizations, but the immediate issue at hand is simply finding the least-intrusive way possible to create them.

  • White House Meeting Puts Spotlight on OSS Sustainability

    White House Meeting Puts Spotlight on OSS Sustainability

    A recent meeting between IT industry leaders and White House officials highlighted open source software sustainability concerns as high-profile breaches and zero-day attacks have many organizations reviewing their software supply chains.

    The White House published a statement describing, among other things, how participants had a “substantive and constructive” discussion on how to make a difference in the security of open source software while continuing to effectively engage and support the open source community.

    Meeting participants included Deputy National Security Advisor for Cyber and Emerging Technology Anne Neuberger, National Cyber Director Chris Inglis, and officials from the Office of the National Cyber Director, Office of Science and Technology Policy, the Department of Defense, the Department of Commerce, the Department of Energy, the Department of Homeland Security, the Cybersecurity and Infrastructure Security Agency (CISA), the National Institute of Standards and Technology and the National Science Foundation. Akamai, Amazon, Apache Software Foundation, Apple, Cloudflare, Facebook/Meta, GitHub, Google, IBM, the Linux Foundation, the Open Source Security Foundation, Microsoft, Oracle, Red Hat and VMware all sent representatives.

    The White House reported that the discussion focused on preventing security defects and vulnerabilities in code and open source packages, improving the process for finding defects and fixing them and shortening the response time for distributing and implementing fixes.

    There were few specific recommendations, but the White House is clearly bringing more pressure to bear after the disclosure of the zero-day Log4j vulnerability in Java applications wreaked havoc in enterprise IT environments and government agencies. That vulnerability made it clear just how dependent organizations are on open source software projects and brought to attention the fact that many are created and maintained by just a handful of volunteer maintainers and contributors. The individuals that created those projects don’t always have a lot of cybersecurity expertise. In fact, many of them would argue that the onus for securing open source software is on the organizations that use what amounts to free software. It’s not the responsibility of the contributors and maintainers of open source software to drop everything and create a patch on-demand to address a zero-day vulnerability.

    The federal government, however, has made it clear via executive order that it expects IT vendors and large enterprises that depend on open source software to do more to secure it. In the meantime, IT teams will need to evaluate their dependence on open source software; especially if, from a security perspective, that software isn’t sustainable simply because there are not enough contributors with the necessary expertise.

    Naturally, this is a complex issue. In many cases, organizations are relying on open source components without even realizing it. Those components have been embedded within an application by an independent software vendor (ISV) that typically doesn’t disclose how that application was constructed. When a zero-day vulnerability is disclosed, cybersecurity teams can spend weeks looking for all the ways the instances of an application they either built themselves or licensed are impacted.

    “There’s no way to really know,” said Mitch Ashley, principal for Techstrong Research, an arm of Techstrong Group, the parent company that publishes devopsy.kinsta.cloud. “A vulnerability can be anywhere.”

    It’s not abundantly clear how critical an issue the sustainability of open source software security is just yet. Relative to the amount of open source software currently employed, the number of security issues that have been encountered is comparatively small, noted Ashley.

    “The innovation benefits enabled by open source software far outweigh the risks,” he said.

    It may be a while before the open source community comes to terms with rising software supply chain concerns. However, it’s clear that many more members of the IT community are about to be held accountable for it.

  • Log4j: Is There Such a Thing as ‘Too Much’ Open Source?

    Log4j: Is There Such a Thing as ‘Too Much’ Open Source?

    The Log4j vulnerability got me thinking: Is there such a thing as too much open source?

    Before anyone immediately fires off a flaming email, rage tweet or scathing blog post, hear me out for a moment. If you know me, you know that I am an open source fanatic. I’ve been asked many times, “Should we use open source software and, if so, how much?” My response was (and still is) that open source software is a massive source of innovation and I can promise you, whether or not you use it, know that your competitors certainly are!

    I could go on and on extolling the virtues of open source and how it enabled the cloud, reshaped software architectures, created new product categories and gave us valuable tools like telemetry and increased visibility into cloud-native apps, infrastructure and beyond.

    When I first heard about the Log4j vulnerability on December 9, like many others, I quickly informed the tech leaders, engineers and SREs in my network about the serious potential risks such a zero-day vulnerability in the widely-used Log4j tool represented. In one way—probably the only way—the Log4j exploit shared a very important characteristic with the SolarWinds supply chain attack of late 2020: The widespread distribution and ubiquitous use of the software across applications, systems and organizations. Arguably, Log4j is used much more widely.

    This similarity raised questions I hadn’t fully considered in the context of such widely used software. Can we use too much open source software? Is Log4j too prevalent in its use and, therefore, a single point of failure? How bad would the Log4j situation be if a fix wasn’t immediately available or if one wasn’t forthcoming?

    The answer I kept coming back to is a resounding ‘no’. I still don’t think there’s such a thing as using too much (insert any open source project name) software. Log4j—and so many other open source software projects—are massively beneficial to us, and we virtually couldn’t function without these systems, tools and solutions in today’s age of ubiquitous software.

    What the current Log4j vulnerability, recent software supply chain attacks and other cybersecurity incidents with widespread impact highlight is our need to quickly respond to security incidents and take remediation steps anywhere they are found in the software stack. And that includes open source software. High-impact security vulnerabilities can occur anywhere across the numerous software stacks and services we use, though they have even greater impact when they occur in widely-used infrastructure, reusable components and microservices.

    In a world of infrastructure-as-code (IaC), it’s no longer a matter of patching a particular set of routers or servers. Unfortunately, much of the software stack is not containerized or built using smaller, easily replaceable containers and microservices—at least not yet. Our mindset and processes going forward from this incident must change, and we have to be prepared to respond to and remediate vulnerabilities both horizontally and vertically across the software stack. In certain circumstances, we have to do this on a large scale.

    As is common with active open source projects, Log4j contributors responded quickly with a readily available fix. The real answer to my original question above is that few are as prepared to respond to an important security vulnerability as those incredible, hard-working, active and engaged open source software developers.

  • Log4j Puts Effective IT Operations at Center Stage

    Log4j Puts Effective IT Operations at Center Stage

    News of the Apache Log4j vulnerability exploit is striking fear into the hearts of both software makers and users. Log4j is the most popular Java logging service used today, with over 400,000 GitHub downloads and has been embedded in most internet services and products from companies all over the world, including Apple, Amazon, Cloudflare, Steam, Tesla, Twitter and Baidu, just to name a few.

    Exploiting this vulnerability is simple and allows threat actors to control Java-based web servers and launch remote code execution (RCE) attacks. New variations of the original exploit are being introduced rapidly—over 60 in less than 24 hours. The attack surface grows by the minute. Good credential management and advanced authentication will not help as this exploit is pre-authentication, which means an attacker doesn’t need to authenticate to your web applications to attack. Your web server is vulnerable.

    The good news is your organization likely has a team of seasoned IT operations pros that can help protect against the worst of Log4j’s devastation.

    How IT Operations Can Protect Against Log4j Vulnerabilities

    Step One: Find Log4j Wherever it Exists

    You need to investigate every internet-facing application, website and system that you own or use. This includes self-hosted installations of vendor products and cloud-based services. Focus on systems that are internet-facing that contain sensitive data. Once you’ve completed assessing your hosted apps and vendor systems, move on to endpoint applications. Java-based apps like WebEx, Minecraft, Citrix and many more.

    Step Two: Patch, Patch, Patch

    Patch in the same order as above: Internet-facing applications, websites and systems. If no patch is yet available for your apps and systems, uninstall.

    The pandemic has forced many endpoints into workers’ home environments, which creates extra challenges for patching those endpoints and keeping them compliant. Operations teams can’t rely on work-from-home folks to patch their own systems, even if they’re given clear instructions. Many of them will just ignore those directions, so you need to adopt systems that enforce continuous compliance.

    Step Three: IT Operations is Essential

    Communicate with your senior leaders. They should be in the know about this one! Senior leadership needs to position their IT operations teams among their most vital employees. Don’t think this is going to go away any time soon—we’re just starting to get a glimpse of what is being tried out there in the wild. Buckle up. 

     

  • To Log or Not To Log

    To Log or Not To Log