Category: Features

  • Survey Shows Increased Focus on Modernizing IT, Retiring Apps

    Survey Shows Increased Focus on Modernizing IT, Retiring Apps

    A survey of 140 enterprise architects and IT leaders published today suggested that, while moving applications to the cloud remains a priority, more attention is being paid to reducing technical debt by retiring applications.

    Conducted by LeanIX, a provider of a platform for managing enterprise architecture and managing value stream management (VSM), the survey found 40% of respondents identified reducing technical debt created by legacy applications and modernizing legacy systems as their top IT priorities. A full 96% said their company has at least one project planned for this year aimed at reducing technical debt with more than half (52%) noting that retiring IT applications is the primary means they will employ to reduce technical debt.

    Nearly 60% considered migrating applications to the cloud to be a high priority, as well. However, less than a quarter of respondents (24%) identified cloud initiatives as a top IT priority. The second most important cloud initiative, identified by 41% of respondents, is to increase the number of SaaS applications being employed.

    Regardless of the approach to the cloud, nearly three-quarters (73%) of respondents said enterprise architects should form a closer connection with software development teams, with an almost equal percentage agreeing on the importance of tracking the business impact of software development.

    However, only 16% of those surveyed considered the evolution and improvement of their security posture a top priority, even though more than two-thirds considered security initiatives—such as improving risk assessment capabilities and adopting more zero-trust IT offerings—as important or highly important.

    Dominik Rose, vice president of product management for LeanIX, said enterprise architects—or someone within IT who assumes responsibility for enterprise architecture—are trying to minimize disruptions to the business as IT environments continue to expand and evolve. The challenge they encounter is there is usually a divide between software development teams and the rest of the business. The size of that divide will vary by organization; in general, though, digital business transformation initiatives should help bridge the gap—assuming enterprise architects can establish and maintain close connections with software development teams, noted Rose.

    LeanIX is making a case for an enterprise architecture management (EAM) platform that provides visibility into IT environments. The company also makes a VSM offering available on top of that platform that provides visibility into software delivery processes. The number of organizations that have adopted VSM platforms remains relatively small, but as organizations depend more on software to drive digital processes, the need for senior business and IT leaders to have more visibility into software delivery schedules is expected to increase.

    In the meantime, it remains to be seen just how aligned DevOps teams are with the strategic goals of the business. The ability to build and deploy software faster does not automatically equate to gaining a deeper understanding of the needs of the business. In fact, there may come a day when software is built and deployed faster than most organizations can effectively absorb unless they have some equivalent of a VSM platform in place.

  • New Relic Adds SLO Tools to Observability Platform

    New Relic Adds SLO Tools to Observability Platform

    New Relic this week made a service level indicator (SLI) and service level objective (SLO) capability generally available within the New Relic One observability platform. The new capability makes it possible for DevOps teams to customize metrics, unified health reports and alerts.

    Alex Kroman, general manager and senior vice president for product engineering for New Relic, said the goal is to enable DevOps teams to more easily optimize services that span multiple applications and software components at a time when more organizations are relying on software to drive digital business transformation initiatives.

    IT teams have, of course, been tracking SLOs for decades. However, as application environments have become more distributed—thanks, in part, to the rise of microservices—achieving and maintaining SLOs has become more challenging. DevOps teams often lack an understanding of which metrics are most relevant to the business and even when they do, they have historically relied on manual processes and ad hoc tooling, noted Kroman.

    In contrast, New Relic is providing those capabilities in a way that makes it simpler to manage service levels at no additional cost, he added. DevOps teams can, for example, create SLIs in one click to automatically establish a baseline of desired performance and reliability. The platform also provides recommendations based on historical data to both establish benchmarks and customize and configure SLIs and SLOs.

    Those capabilities make it simpler to set service boundaries and track reliability across teams based on benchmarks, tags and reports that include bespoke views for both service owners and business leaders. In effect, via an application programming interface (API) exposed by New Relic, it becomes possible to employ dashboards to gain visibility across an entire business process, said Korman.

    It’s still early days as far as the modernization of SLOs is concerned, but it’s clear that, over time, they will be managed as code along with everything else in a DevOps workflow. The more organizations become dependent on applications to drive digital business initiatives, the more critical it will become for DevOps teams to track SLOs. The decision that must be made is the degree to which it makes sense to manually implement some form of SLO-as-code versus relying on an observability platform that can be accessed as a cloud service.

    Observability, of course, has always been a core tenet of DevOps. Few organizations are able to really achieve it, however, because most IT teams have been monitoring little more than a pre-defined set of metrics. Modern observability platforms make it easier for site reliability engineers (SREs) to launch queries against aggregated instances of metrics, logs and distributed traces to ascertain the root cause of an issue. The issue then becomes how to correlate the results of those queries against the service levels that businesses expect from a set of applications that might be driving, for example, an order-to-cash process. After all, knowing what occurred within an IT environment doesn’t always easily translate into a report that the average business executive can easily comprehend.

  • Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

    Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: No remedy for banned Facebook users, new ARM-based VMs on Microsoft Azure, and The Great Resignation will still be a Thing for the foreseeable. (more…)

  • Security Debt: Speed vs. Common Sense

    Security Debt: Speed vs. Common Sense

    A couple years ago, we had some spectacular security events that involved DevOps and Kubernetes, where the managing team simply redeployed containers whenever one crashed. It turned out that many organizations were doing the same thing, and, what’s worse, they were not talking about it because they knew it was not a long-term solution to crashing issues.

    At the time, I thought these high-profile lessons would teach people to actually fix code issues, even in high-throughput Agile-meets-DevOps shops. I admit I also laughed, yet again, at The Phoenix Project’s expense, thinking, “Yeah, but the CISO isn’t holding things up by demanding that get fixed!” I wish that would ever get old, but it won’t.

    It seems I was wrong. Or at least partially so. Some—perhaps many—shops seem to have missed the message that these issues sent. Anecdotally, we heard this was still happening, so we started asking questions. Yep. There are shops out there (since we started with ‘anecdotally,’ I won’t pretend to put numbers around it) that still take an “If it isn’t causing disruption in core systems, don’t fix it” mentality.

    Ouch. We’ll be revisiting some of those in the future, I’m sure—when it’s listed as a vulnerability or breach somewhere.

    I’m not a security professional. Because the vast majority of enterprises do not have dedicated security and even more don’t have anything close to enough security staff, I have done security as a part of almost every job I’ve taken—because it was what needed doing the most. Many, if not most of you, are in the same boat.

    That said, I can tell when you are blatantly asking for a security incident. And running code known to be faulty or misconfigured to the point that it repeatedly crashes is deliberately asking for a security incident. “But it isn’t exposed to the Internet!” is only a valid rebuttal until an attacker gets inside the perimeter and uses your fault for something like privilege escalation. Then no one cares if it’s connected to the internet or not; they want to know how the attacker did it. And that’s on you.

    So for those organizations in which speed has overridden common sense, let’s be very clear and to the point.

    It is a best practice not to run crash-level faulty software.

    Since you must not have one, write a policy that explains this and lays out a process and/or timeline to fix these problems. Then drive it home. Make certain it is known that this policy will be enforced. For that huge majority of my readers that don’t have the level of authority that “create and promulgate a policy” implies, convince those who do. Point out the issues to them in writing. “Notified in writing of faulty practices that could bite the company in the rear,” tends to get even the most unfriendly management to click into CYA mode and do something about it.

    When we all watched those spectacular failures back in the day, I assumed that this was all about growing pains; you can do so much more with Agile/DevOps/cloud and/or Kubernetes that this type of thing would crop up and, eventually, get addressed. I still believe that. You all are still testing the boundaries and pushing the limits and making all of IT look good. It’s just going to hurt getting there sometimes. Fix the apps, make the policy, keep kicking butt and know you are killing it (as an industry. If you aren’t, stop laughing at my blanket compliment and fix yourself).

  • ACCELQ Further Automates Testing of Low-Code, No-Code Apps

    ACCELQ Further Automates Testing of Low-Code, No-Code Apps

    ACCELQ today unveiled the cloud-based ACCELQ Live test automation platform that is continuously integrated with a wide range of low-code and no-code application development and deployment platforms.

    ACCELQ CEO Mahendra Alladi said the goal is to make it simpler to run complex tests across a multi-cloud computing environment.

    Usage of low-code and no-code tools has greatly expanded since the start of the COVID-19 pandemic. Many organizations are now relying on these tools to accelerate a wide range of digital business transformation initiatives. The challenge they encounter is that many of these processes depend on multiple applications that have lots of interdependencies across which it is difficult to conduct tests, noted Alladi.

    The ACCELQ Live platform reduces testing complexity by automatically updating itself as, for example, Salesforce or ServiceNow platforms are updated. It also provides access to pre-built codeless automation assets modeled on business processes via a live link. The company is also moving toward creating a marketplace where software vendors and service providers can build and deploy pre-built testing assets, as well.

    Gartner predicts the adoption of low-code and no-code technologies will nearly triple by 2025. Testing those applications creates a major challenge as the pace of application development increases. The only way organizations will be able to keep pace is by embracing test automation platforms infused with artificial intelligence (AI) capabilities, said Alladi. In effect, ACCELQ’s ACCELQ Live represents an effort to democratize the testing of cloud and enterprise apps, he added.

    As organizations increasingly appreciate their dependence on software, the way tests are being conducted is rapidly evolving. In addition to dedicated testing teams, developers and application owners are becoming more involved as responsibility for testing applications continues to shift further left. The challenge organizations face is the volume of applications that are simultaneously being constructed has significantly increased. Platforms that automate many lower-level testing functions are gaining traction as a means to enable humans to focus more of their time and energy on testing more complex functionality. The goal now should be to first rely on test automation platforms as much as possible and then employ humans to fill in the gaps as necessary, said Alladi.

    It may be a while before most organizations achieve that level of test automation. However, with each passing day, it’s apparent that AI will play a larger role in application testing. The issue that many DevOps teams are now working through is how to incorporate test automation platforms within the context of a larger workflow.

    In the meantime, the rate at which application testers become burned out should decline as more routine errors are uncovered by machines. It’s not likely AI will eliminate the need for dedicated testing teams any time soon, but as more rote tasks become automated there is going to be more time to focus on enhancing overall quality at a time when application environments have not only become much more distributed but also a lot more complex.

  • Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Legit Security today revealed that it discovered a privilege escalation vulnerability in GitHub repositories that has since been remediated.

    Liav Caspi, Legit Security CTO, said the company worked with GitHub to remediate the issue prior to disclosure. Legit Security researchers reported they found hundreds of GitHub instances rated with over 1,000 stars each that could be subject to the vulnerability.

    Caspi said the company also reached out directly to most of those affected sites, including an instance of GitHub that is used to develop the open source Nginx web server that is employed across hundreds of millions of websites.

    Cybercriminals could exploit a vulnerable build script to modify code or built artifacts that would result in software being shipped with code controlled by some other entity. The vulnerability could also enable access to sensitive secrets, such as keys, that are used to access cloud services or simply create a malicious pull request.

    Legit Security researchers employed a set of risk assessment tools that are part of a larger software-as-a-service (SaaS) platform that enables them to apply security policies across their entire software development life cycle. Earlier this year, the company made available a free Rapid Risk Assessment tool to provide organizations with more insights into their software supply chains. Security research findings, along with other security best practices, are embedded within the policies that can be enforced via the Legit Security platform.

    In the wake of a series of high-profile breaches, there is now more focus on the security of software supply chains than ever. Gartner estimated that 45% of organizations worldwide will have experienced attacks on their software supply chains by 2025, a threefold increase from 2021.

    Despite those concerns, however, the rate at which new applications are being deployed and updated doesn’t appear to be slowing. Organizations are too dependent on software to encourage customers to slow down the development and deployment rate of applications. It will, however, take years for organizations to properly train developers to correctly employ security tools within their application development processes, otherwise known as DevSecOps best practices, to reduce the number of vulnerabilities that now routinely manifest themselves in production environments. The only practical alternative is to embed more tools that automatically discover vulnerabilities in code during the application development process.

    Regardless of the DevSecOps approach, the ultimate goal remains to build more secure applications faster. That can only be achieved if there are more guardrails in place that prevent developers from inadvertently introducing vulnerabilities into an application. The more frequently applications are updated, the more likely it is that a vulnerability will be introduced. Each time those vulnerabilities are discovered after an application is deployed in a production environment, the more expensive they are to remediate. As the volume of vulnerabilities increases, it’s also only a matter of time before the sheer number of security issues that need to be addressed overwhelms both developers and security operations teams alike.

    Application security, of course, has not always received the attention it deserves, but demands for increased application security can no longer be ignored.

  • Dagger: Standardizing CI/CD is the Holy Grail of DevOps

    Dagger: Standardizing CI/CD is the Holy Grail of DevOps

    Continuous integration and continuous delivery (CI/CD) has become a hallmark of quick software release life cycles. Nowadays, many teams support CI/CD pipelines for their software, offering a repeatable pathway to build, test and deploy code. A CI/CD pipeline is necessary to support an iterative, rapid deployment approach—yet, maintaining one is not an easy task.

    Enter Dagger. Dagger is a utility that aims to streamline how developers create and manage their CI/CD pipelines. Dagger, led by founders of Docker, recently unveiled their public beta launch along with a Series A $20 million funding raise led by Redpoint Ventures. While many open source CI/CD projects already exist on the market, Dagger is unique in offering easier configurations, pre-built components and more reusable actions.

    Akin to traditional supply chain management, software supply chain management is an increasingly complex endeavor involving many third-party dependencies. Development teams truly require a set of standard building blocks to piece it all together. For this reason, Solomon Hykes, co-founder and chief executive of Dagger, told SiliconANGLE that “solving this problem is the holy grail of DevOps.”

    Below, we’ll look at the common stressors inherent in creating and managing modern software delivery chains. We’ll also take a peek into the Dagger beta to see what it’s attempting to accomplish.

    Issues Facing CI/CD

    Software development supply chains are growing larger and larger to support a complex network of software architectures. But DevOps engineers, who must automate this chain, are drowning in tool sprawl—and stitching these components together to make custom pipelines can become a big bottleneck.

    Especially as an organization expands its distributed microservices architecture into the cloud, it can be tricky to scale a repeatable CI/CD pipeline across various department and disparate tech stacks. This often results in many bespoke CI/CD pipelines. Even within the same team, nuances between codebases can complicate each CI/CD process and require engineers to rewrite scripts.

    Simultaneously, organizations are under intense pressure to deliver to meet new digital innovation demands. But, until DevOps can make the release process more efficient, software development automation risks introducing more toil than it takes away.

    Diving Into Dagger

    So, how is Dagger alleviating these concerns? Well, Dagger creators described it as a “portable devkit for CI/CD pipelines.” Using Dagger, DevOps engineers can use a standard set of building blocks to assemble their CI/CD pipelines and then run them on their chosen cloud. It’s like a better developer experience for CI/CD pipeline creation.

    So, how does Dagger work under the hood? Dagger is powered by Buildkit, the Dockerfile-agnostic builder toolkit. Developers then use Cue to specify how their code is run in a container and to link up actions. Cue is an open source configuration language developed at Google.

    According to the docs, it takes about five minutes to install Dagger and the necessary dependencies. Dagger also provides boilerplate code to integrate with pre-existing CI environments. In essence, Dagger doesn’t need to replace your CI tool—it adds “a portable development layer on top of it.”

    Then, there are the actions themselves. Dagger supports a growing library of actions that it calls Universe. At the time of writing, the Universe of actions is limited and is being staged in the main Dagger repository. These actions are reusable Cue packages. For example, this package details how to run and deploy the Nginx web server in Cue:

    package nginx
    
    import (
        "universe.dagger.io/docker"
    )
    

    And then,

    #Build: {
        output: docker.#Image & _pull.image
    
        _pull: docker.#Pull
        *{
            flavor: "alpine"
            _pull: source: "index.docker.io/nginx:stable-alpine"
        } | {
            flavor: "debian"
            _pull: source: "index.docker.io/nginx:stable"
        }
    }
    

    Benefits

    CI/CD can certainly benefit from standard building blocks and more fluid wiring between tools. There are several potential benefits from Dagger’s proposition:

    • Unification: Unifying developer and CI environments could avoid headaches.
    • Localization: Dagger enables testing a closed-loop pipeline locally. This helps for debugging.
    • Reusability: Building blocks help avoid rewriting automation scripts repeatedly.
    • Multi-cloud: Easier ability to migrate a pipeline from one cloud to the other, thus avoiding vendor lock-in.
    • Compatability: Dagger can run in any environment compatible with Docker, meaning it’s probably workable with your current toolset.

    Final Thoughts: Lego Blocks For CI/CD

    Docker revolutionized the software industry by easing the process of managing containerized applications. And now, Docker founders Solomon Hykes, Sam Alba, Andrea Luzzardi and others at Dagger are tackling another meaningful problem within today’s complex software ecosystem. Given the success of their previous endeavors, it’s not too difficult to imagine a network of reusable CI configurations emerging with an excitement similar to Docker Hub.

    Of course, Dagger is still in its early stages and there’s much development ahead. It will undoubtedly be an interesting project to follow in the years to come. Dagger is being built as an open source project on GitHub. The company has also opened a Discord channel to engage with the community.

  • WhiteSource Offers Free Spring4Shell Vulnerability Tool

    WhiteSource Offers Free Spring4Shell Vulnerability Tool

    WhiteSource has launched a free command-line interface (CLI) tool that detects vulnerable open source Spring4Shell vulnerabilities (CVE-2022-22965) that are impacting Java applications built using the Spring development framework.

    Susan St. Clair, director of product management for WhiteSource, said the WhiteSource Spring4Shell Detect tool is similar to the tool the company made available earlier this year to detect Log4Shell vulnerabilities in Java applications. It provides an exact path to direct and indirect dependencies along with how to find a fixed version of the Spring framework to accelerate remediation efforts.

    Spring4Shell is yet another zero-day vulnerability that has been given a 9.8 severity score. As a result, DevOps and cybersecurity teams are now racing to update applications impacted by this vulnerability before cybercriminals can exploit it. The Spring4Shell vulnerability enables remote code execution (RCE), and the Java applications impacted employ versions 5.3.17 or 5.2.19 of the Spring framework and version 9 or higher of the Java Development Kit (JDK).

    The vulnerability allows an attacker to remotely execute arbitrary code on the target server. It allows attackers to abuse a RequestMapping annotation that maps incoming HTTP requests into their appropriate handler functions. The vulnerable condition occurs when RequestMapping is used in conjunction with traditional Java objects as the handler parameter. Such an attack might allow access to all website internal data, including any database. It might also allow access to additional internal resources to gain more permissions or to pivot to other parts of the internal network.

    It’s not clear how pervasively Spring4Shell might impact Java applications compared to Log4Shell vulnerability that affected a logging tool, but more security researchers are looking for RCE vulnerabilities within Java application environments. Organizations now will need to determine whether to maintain legacy applications that might be subject to more zero-day vulnerability discoveries or replace them with newer applications that are developed in a programming language that might be more secure. There is, of course, no guarantee a new application will be more secure than a legacy application, but the chances are good a modern application will have fewer vulnerabilities than a legacy application simply because the underlying programming tools and platforms are more advanced from a security perspective.

    In the meantime, DevOps teams likely will be looking for instances of Spring4Shell vulnerabilities for months to come. DevOps teams that have access to a software bill of materials (SBOM) naturally will be able to find those instances more easily than organizations that don’t. However, the percentage of organizations that have SBOMs is still comparatively low. However, as zero-day vulnerabilities become a larger security issue, SBOMs are being implemented more widely as organizations review their software supply chains.

    Whatever the path toward ensuring application security ends up being the level of scrutiny being applied to application development and deployment, processes will in the months ahead accelerate the adoption of best DevSecOps practices across organizations large and small, whether they like it or not.

  • The Missing Link in Continuous DevOps Cycles

    The Missing Link in Continuous DevOps Cycles

    Delivering software quickly, reliably and safely is at the heart of technology transformation and organizational performance regardless of industry. As part of overall technology transformation, many companies are recognizing the benefits of applying DevOps methodologies to areas outside of software development, such as general product development, IT expansion and scaling and new business processes. However, some organizations—and even software development teams—may be missing a crucial step in the product development life cycle. 

    The Missing DevOps Link

    DevOps methodologies are nothing new. In fact, part of the reason organizations are adopting DevOps practices for initiatives outside of software development is because of its tested and proven success when it comes to developing and deploying new processes and features. The exact steps involved in DevOps processes can be debated by reasonable people, but there are three generally agreed-upon factors involved: Continuous integration (CI), continuous deployment (CD) and continuous release (CR). 

    Continuous Integration

    CI refers to a strategy of constantly updating products with new features and code on a regular basis. The cadence of the updates varies from weekly to monthly, but the strategy remains the same: Detect problems early before they can snowball and impact further development down the line. 

    Continuous Delivery

    CD is related to continuous integration but is focused on the delivery stage. CD is executed when new features and development updates are deployed to production. The most critical factor of CD is consistent management of the product’s end environment. To maintain the consistent functionality of a product in the end-user environment, it must be regularly deployed and tested to ensure performance doesn’t suffer as a result of product updates and new features.

    Continuous Release

    CR is the final step before the product development life cycle starts over again. CR refers to the practice of continually releasing new product updates, features and capabilities to end users. The tricky part of CR is that you must execute CI and CD flawlessly to ensure the end user doesn’t experience any bugs or issues caused by an update. 

    But what’s missing? The answer lies in continuous exploration (CE). 

    Why CE is Critical to Product Development Success

    CI, CD and CR are often-discussed product development strategies, but they don’t tell organizations where to start with the DevOps life cycle. To begin developing new products or features, organizations must first identify what exactly they’re building and for whom. As I often say to my product team, you need to get the kitchen ready before you can cook a great meal, but you need to know what meal you’re making before you start cooking the wrong thing.

    CE refers to the continuous exploration of a company’s markets, target audiences and customers to understand their requirements and preferences. This may sound like the job of a marketing department, not product developers, but the two should work together in a coordinated fashion that helps to achieve both teams’ goals. For example, product development teams don’t know what new product features their customers love, which ones they hate or which ones they really need. On the other hand, marketing teams don’t know how to market products if they don’t understand the ins and outs of the new features and how they can be of service to customers. 

    Even departments within an organization that don’t develop products can benefit from CE. For example, if an organization is pursuing a cloud migration of on-premises software, they will likely hire an expert consultant or vendor to help them execute their cloud vision rather than developing their own cloud environment.

    However, simply moving all of the on-premises systems and data to the cloud at once could be a catastrophe. What if you migrate systems and processes to the cloud and they suddenly stop working? Unless you’ve performed the migration at a gradual pace by following CI, CD, CR and CE strategies, you don’t know what, specifically, is causing the system error in the cloud.

    In the same vein, by performing CE internally, organizations can determine which processes and on-premises systems would benefit most from cloud capabilities and execute the migration accordingly. This not only prioritizes technology transformation initiatives based on the needs of the business but may also let the business know which on-premises systems may no longer be needed in a cloud environment.

    Many organizations interested in improving customer experience (CX) and internal processes by leveraging DevOps strategies would benefit greatly from leveraging CE. Products and businesses processes should be designed to meet the needs of customers and drive bottom-line revenue. So, it stands to reason that the first step in meeting the needs of customers is understanding those needs. This cannot be done without CE as the foundational building block of product development life cycles. 

  • Fixing Spring4Shell Starts With Software Supply Chain Management

    Fixing Spring4Shell Starts With Software Supply Chain Management

    Spring4Shell is the latest call to action for radically improved software supply chain integrity. While Spring4Shell investigations continue, one conclusion is indisputable: We must holistically rethink the way we continuously inventory and manage the complex landscape of interrelated software and its sources.

    Whether or not Spring4Shell surpasses the breadth of impact of Log4j, there’s still massive potential for severe consequences to software and API security across the open source infrastructure, frameworks and application software stacks.

    That’s because, as we saw with Log4j, this attack could impact most enterprise Java applications globally. It seems the root cause is a vulnerability in the widely used, free, community-developed, open source programming framework Spring Core.

    The Spring framework is the foundation for most enterprise Java applications—as many as 74%, according to some data. Specifically, Spring serves as the foundation for enterprise Java apps so that teams can focus on application-level business logic without being locked into specific deployment environments.

    Spring Core’s ubiquity introduces significant potential for widespread impact due to its use across enterprise software, cloud services, third-party software and service products as well as internally managed software. This is another call-to-action to improve the way we approach software supply chain security and supply chain management. Thankfully, there’s already a place to start.

    Every infrastructure and software team can begin addressing this vulnerability by leveraging resources from The Linux Foundation’s Software Bill Of Materials (SBOM) project. The 2021 initiative included an SBOM readiness survey, a Generating Software Bill Of Materials training course and an SBOM generator tool based on the SPDX standard (ISO/IEC 5962:2021).

    The Linux Foundation’s SBOM contributions provided all of us a head start to begin addressing issues with software supply chain management. With widespread adoption, SBOM equips software projects and users to assess and address Spring4Shell as well as any other as-yet-unknown vulnerabilities and prepare us for what is undoubtedly a season of high-impact infrastructure software vulnerabilities.

    For more Spring4Shell resources, please visit: https://www.contrastsecurity.com/security-influencers/new-spring4shell-vulnerability-confirmed-what-it-is-and-how-to-be-prepared