This is an unpopular opinion, and I get why – people crave a scapegoat. CrowdStrike undeniably pushed a faulty update demanding a low-level fix (booting into recovery). However, this incident lays bare the fragility of corporate IT, particularly for companies entrusted with vast amounts of sensitive personal information.

Robust disaster recovery plans, including automated processes to remotely reboot and remediate thousands of machines, aren’t revolutionary. They’re basic hygiene, especially when considering the potential consequences of a breach. Yet, this incident highlights a systemic failure across many organizations. While CrowdStrike erred, the real culprit is a culture of shortcuts and misplaced priorities within corporate IT.

Too often, companies throw millions at vendor contracts, lured by flashy promises and neglecting the due diligence necessary to ensure those solutions truly fit their needs. This is exacerbated by a corporate culture where CEOs, vice presidents, and managers are often more easily swayed by vendor kickbacks, gifts, and lavish trips than by investing in innovative ideas with measurable outcomes.

This misguided approach not only results in bloated IT budgets but also leaves companies vulnerable to precisely the kind of disruptions caused by the CrowdStrike incident. When decision-makers prioritize personal gain over the long-term health and security of their IT infrastructure, it’s ultimately the customers and their data that suffer.

  • vrighter@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    1
    ·
    4 months ago

    the virus definition is not written in c++. And even then, the problem was that the file was full of zeros.

    • SparrowRanjitScaur@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      3
      ·
      edit-2
      4 months ago

      Maybe I heard some bad information, but I thought the issue was caused by a null pointer exception in C/C++ code. If you have a link to a technical analysis of the issue I would be interested to read it.

      • vrighter@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        3
        ·
        4 months ago

        They said it was a “logic error”. so i think it was more likely some divide by zero or something like that

      • 0x0@programming.dev
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        1
        ·
        4 months ago

        No one does, it’s not public yet, if ever. This is close enough.

        The real problem was, among others, lack of testing, regardless of the programming language used. Blaming C++ is dumb af. Put a chimpanzee behing the wheel of a Ferrari and you’ll still run into… problems.

        • SparrowRanjitScaur@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          edit-2
          4 months ago

          I’ll reiterate, if it was a null pointer exception (I honestly don’t know that it was, but every comment I’ve made is based on that assumption, so let’s go with it for now) then I absolutely can blame C++, and the code author, and the code reviewer, and QA. Many links in the chain failed here.

          C++ is not a memory safe language, and while it’s had massive improvements in that area in the last two decades, there are languages that make better guarantees about memory safety.

          • vrighter@discuss.tchncs.de
            link
            fedilink
            English
            arrow-up
            1
            ·
            4 months ago

            but it very probably was not a memory error. Rust isn’t magic. It probably could not have prevented this bug anyway.