It seems mass layoffs are a part of life now. I guess this is what we get for letting the stock market run our lives. "Oh, we have too many people, the market isn't happy, let's make a bunch of them unemployed." Whatever. This is where we are.
That's shitty. But what's really shitty is the way it's done in secret.
I'm in Australia, working for an American company. All of this played out on a US timeline.
My colleagues in the US were gone by the end of their business day. By the time I woke up it was all over.
In Australia we're a little luckier, in that we actually some employee protections. When a role is made redundant there has to be a "consultation" period, where you're informed about the potential job loss. The company is supposed to explore what options are available in terms of other roles, etc; anything that could mean they can actually keep you employed. There's not a lot of requirement around exactly how long the consultation period lasts, what happens, etc - but it's better than the US.
Here's the fun part: a couple of months ago, the (then new) CEO put a hiring freeze in place. Seemed reasonable enough: I've just come into this company, and just want to get a handle on things so let's put stuff like new hires on hold while I get my head around everything.
Bonus side effect: when they announce redundancies because of a hiring freeze there are no open roles that anyone impacted can move in to. Genius.
So, a bunch of people get sacked with no warning. We don't know who, until we try to contact our colleagues and find their Slack accounts have been deactivated. It's all chaos, no one knows what's going on. It's literally going to take months to get back on track.
AND IT'S EXACTLY THE SAME THING THEY DID THREE YEARS AGO.
It was chaos then, and it is chaos now.
The mega stupid thing? If we accept that the whole mass layoff thing has to happen, and if tech companies could pull their heads out of their arses and not feel they have to do everything in secret, the outcome could actually be much better.
"What? Hundreds of people out of work? How could things be better?"
Let's assume it's going to take three months to get things back to some semblance of normal. Take those three months to actually consult with the employees. Be up-front, and say that the company needs to cut whatever number of roles. Offer decent severance packages to those who decide to take a voluntary redundancy. Support them in the transition out. The people who are left know exactly who is leaving, and can plan accordingly. The chaos is avoided. The ill-will is avoided. All it takes is the exec team to decide to not be cunts.
Yeah, I know. That's never going to happen.
]]>I don't specifically have an issue with this: while there was potential for community involvement, most of the content came from Rapid7 labs. The decision to move publishing labs data to the Rapid7 blog is well within their rights.
What I do have issues with:
Let's dive into those...
Rapid7 have provided a month warning that AttackerKB is going away. Not just the website, but the API. Anyone who was using that API has 30 days to find and implement an alternative solution. The claim is usage was very low, only a handful of active users. If that's the case, the cost to maintain it in the status quo is essentially zero.
The particularly irksome piece to this is that the usual process is to announce end-of-sale, and then end-of-life at least 12 months after that. A year rather than a month. Give people time to do something.
Even worse is the removal of all the historical content. The announced plan is to migrate content from attackerkb.com to the Rapid7 blog, with redirects on the original URL.
I don't like this plan.
Even if they maintain links for a while, at some point someone is going to run a project to rebuild the site, and a bunch of link pruning will take place.
The best way to approach this would be to turn the existing site into a static collection. Add a link to the relevant page on rapid7.com to a header or footer or something. But leave the original content there. Preserve the history.
So much content is being lost, leaving behind a mess of link rot. Companies can chose to stop doing this. I wish they would.
]]>If you want your kids to get hands-on with tech, that's cool. But you need to be involved. You need to supervise. To guide. Advise. Teach. In short: you need to be a parent. You can't just shove an iPad in their hands and walk away, and then act surprised when they're doing something you don't like.
Kids are supposed to be curious. They're supposed to explore, to push boundaries. That's one way they learn - and if left alone, pretty much the only way they'll learn.
The boundaries bit is important. If you go erecting artificial boundaries or trying to restrict their activities, I promise you they will find a way around your controls. They are smarter than you are. If you start this war you will lose.
Or, you can be a parent instead of letting the iPad take that role.
]]>One article really stuck with me though: Daniel Stenberg, the founder of cURL and libcurl, had the codebase of cURL audited with Mythos and wrote about the results. It's well worth a read, but the TL;DR is that Mythos claimed five "confirmed" security vulnerabilities. These were triaged down to three false positives, one bug, and one low severity vulnerability. Doesn't seem like a big deal, right?
However, there is some really important context: cURL is probably one of the most heavily audited and reviewed codebases in existence. The project team are well aware of how widely deployed cURL is (it's probably running on dozens of devices in your house and you have no idea). They take security very seriously. Again, read the article for the details.
The point being that cURL is the exception. Not just in the open-source world (although, sure, there's a bunch of crappy open-source code out there), but I'm talking enterprise applications. You know, the things that run business of all sizes. The things that are pushed to market as soon as possible to maximise the revenue.
Is AI-powered discovery going to be weaponised to find and exploit previously unknown vulnerabilities? Probably. But the threat here isn't some new-fangled thing from Anthropic. Just as it's always been, the problem is shitty code written by shitty developers working for shitty companies that don't care about the impact of their MVP crapplications.
]]>Because there's still useful work to be done in cutting through the noise. Because "here's what actually matters" doesn't get said often enough. Because we've got opinions and a text editor.
Expect posts on threat intelligence, detection engineering, cloud security, identity, incident response, and the general state of the industry — written for people who've been around long enough to spot the BS, but also for people just finding their footing and trying to learn what's real.
No vendor relationships to protect. No conference circuit to stay in good standing with. Just the work.
Buckle up.
]]>