[S]hareholders said they learned that CrowdStrike’s assurances about its technology were materially false and misleading when a flawed software update disrupted airlines, banks, hospitals and emergency lines around the world.
I don’t see how they can make this argument.
Falcon is a kernel module. When kernel modules fuck up, you get kernel panics.
Sure, the layperson may not know enough about computers to recognize this, but it’s a basic enough fact about operating systems that an investor in a company like this should take the time to learn. It’s not like they hid that fact.
If you invested in a company without knowing how their product works, that’s on you.
You highlighted the wrong portion of this article.
The complaint cites statements including from a March 5 conference call where Kurtz characterized CrowdStrike’s software as “validated, tested and certified.”
If the CEO is making claims that the software is tested and certified, then the CEO should be able to prove that claim, no matter where the software lives. It is very reasonable to say, at face value, the CrowdStrike testing pipeline was inadequate. There is a remote possibility that there were mitigating factors, eg some other common software update released right before from another vendor that contributed; given CrowdStrike’s assurances and understanding of where it falls in most supply chains I consider that to be bullshit. I personally haven’t seen anything convincing that shows a strong and robust CI pipeline magically releasing this issue.
Now shareholder lawsuits are bullshit in general and, as someone constantly pushed to release without fucking any confidence, I think it’s really fucking dumb to ever believe any software passes any inspection until you have actually looked at the CI/CD process in-depth.
I mean it was true. It’s just that here was a bug with the automated testing software that let the bogus file go through.
They could have shown their testing/certification pipeline to investors, but it wouldn’t have changed anything unless investors would have somehow been able to figure out there was a bug in what they showed them.
To add to that, I very much doubt any big company tests and verifies anything anymore.
Boeing ships planes with missing bolts and proper software, Crowdstrike pushes updates with no testing, we’ve all seen Microsoft push updates that break stuff because there’s no testing, and that’s just what comes to mind.
That’s how they maximize profits - get rid of testing environments, do minimal checks, and have the one guy doing 3 jobs at once just push it to production.
I’ve been in IT for the banking industry for over a decade and I promise you, we’re all a missed cup of coffee or a comma away from another massive outage due to a program or network misconfig.
As long as business culture is set to maximize profits for one quarter, I wouldn’t trust a sales website about “verification” or “disaster recovery backups” any more than I trust a used car salesman.
That goes for Crowdstrike, but also all of their competitors.
I’ve got friends at Boeing on DoD contracts. Not only is it waterfall, it gets tested hardcore. My experience in private industry is the exact opposite. A consultancy I know of just lost (pretty sure) a state contract because they opened shit up to the public because, surprise surprise, they didn’t test their infra changes.
Now I will say that when I have had to manage client SLAs and there is a cost to post-release defects and change requests, testing increases. Not to the level I’m super comfortable with (which is well below perfect, mind you; I like shipping more than once in a lifetime), but a bit more.
The CTO of a competitor, Sentinel one, was just on the security podcast Risky buisness. He went deep into how his company does this.
Apprently, their client touches the kernel much less, so it is less likely to cause issues. They also have a large internal test bed that updates have to pass to go out at all, and then if they have a 2% failure rate during the wide deployment, the update is automatically stopped.
Crowdstrike does almost none of this. There core client is deep in the kernel, making it powerful and dangerous. They apprently do test on their local machines, but the company is an apple shop, so none of the windows updates was tested locally. The updates pushed out started crashing computers immediately, but weren’t stopped for 78 minutes by manual intervention. That was long enough to crash 8 million computers across the world.
There are kernel modules, and then there are kernel modules.
Based on conversations from the CTO of sentinel one, a crowdsrike competitor, the crowdstrike client is intentionally engineered with a lot of and way deeper hooks then most of the industry. This makes their engine powerful and very dangerous. The other vendors in the space touch the kernel as little as possible, moving everything they can into userspace to minimize any possible damage.
The fact that crowdstrike was fully in the kernel and then running basically no tests while deploying updates is the reckless fuck up.
You would be surprised at how little investors know about the things they invest in. They only look at the money flow. The case will likely go nowhere though since a small gap in processes isn’t the same as a complete lack of processes that the lawsuit is implying.
I don’t see how they can make this argument.
Falcon is a kernel module. When kernel modules fuck up, you get kernel panics.
Sure, the layperson may not know enough about computers to recognize this, but it’s a basic enough fact about operating systems that an investor in a company like this should take the time to learn. It’s not like they hid that fact.
If you invested in a company without knowing how their product works, that’s on you.
You highlighted the wrong portion of this article.
If the CEO is making claims that the software is tested and certified, then the CEO should be able to prove that claim, no matter where the software lives. It is very reasonable to say, at face value, the CrowdStrike testing pipeline was inadequate. There is a remote possibility that there were mitigating factors, eg some other common software update released right before from another vendor that contributed; given CrowdStrike’s assurances and understanding of where it falls in most supply chains I consider that to be bullshit. I personally haven’t seen anything convincing that shows a strong and robust CI pipeline magically releasing this issue.
Now shareholder lawsuits are bullshit in general and, as someone constantly pushed to release without fucking any confidence, I think it’s really fucking dumb to ever believe any software passes any inspection until you have actually looked at the CI/CD process in-depth.
I mean it was true. It’s just that here was a bug with the automated testing software that let the bogus file go through.
They could have shown their testing/certification pipeline to investors, but it wouldn’t have changed anything unless investors would have somehow been able to figure out there was a bug in what they showed them.
To add to that, I very much doubt any big company tests and verifies anything anymore.
Boeing ships planes with missing bolts and proper software, Crowdstrike pushes updates with no testing, we’ve all seen Microsoft push updates that break stuff because there’s no testing, and that’s just what comes to mind.
That’s how they maximize profits - get rid of testing environments, do minimal checks, and have the one guy doing 3 jobs at once just push it to production.
I’ve been in IT for the banking industry for over a decade and I promise you, we’re all a missed cup of coffee or a comma away from another massive outage due to a program or network misconfig.
As long as business culture is set to maximize profits for one quarter, I wouldn’t trust a sales website about “verification” or “disaster recovery backups” any more than I trust a used car salesman.
That goes for Crowdstrike, but also all of their competitors.
I’ve got friends at Boeing on DoD contracts. Not only is it waterfall, it gets tested hardcore. My experience in private industry is the exact opposite. A consultancy I know of just lost (pretty sure) a state contract because they opened shit up to the public because, surprise surprise, they didn’t test their infra changes.
Now I will say that when I have had to manage client SLAs and there is a cost to post-release defects and change requests, testing increases. Not to the level I’m super comfortable with (which is well below perfect, mind you; I like shipping more than once in a lifetime), but a bit more.
The CTO of a competitor, Sentinel one, was just on the security podcast Risky buisness. He went deep into how his company does this.
Apprently, their client touches the kernel much less, so it is less likely to cause issues. They also have a large internal test bed that updates have to pass to go out at all, and then if they have a 2% failure rate during the wide deployment, the update is automatically stopped.
Crowdstrike does almost none of this. There core client is deep in the kernel, making it powerful and dangerous. They apprently do test on their local machines, but the company is an apple shop, so none of the windows updates was tested locally. The updates pushed out started crashing computers immediately, but weren’t stopped for 78 minutes by manual intervention. That was long enough to crash 8 million computers across the world.
There are kernel modules, and then there are kernel modules.
Based on conversations from the CTO of sentinel one, a crowdsrike competitor, the crowdstrike client is intentionally engineered with a lot of and way deeper hooks then most of the industry. This makes their engine powerful and very dangerous. The other vendors in the space touch the kernel as little as possible, moving everything they can into userspace to minimize any possible damage.
The fact that crowdstrike was fully in the kernel and then running basically no tests while deploying updates is the reckless fuck up.
You would be surprised at how little investors know about the things they invest in. They only look at the money flow. The case will likely go nowhere though since a small gap in processes isn’t the same as a complete lack of processes that the lawsuit is implying.