Notices by Marc Rogers ? ?? ⚠️ (cj@chaos.social)

@howelloneill the insider in this case didn’t just slide into the dev’s DM’s. They worked with each other for two years. How many companies would be able to defend against a trusted senior employee of two years suddenly becoming a covert insider threat? I’d argue very few.

@howelloneill its when the conversation stops that I worry. It would be naïve not accept there are unique risks in different development models. Sunlight is the best disinfectant.

Theres a lot of talk about what the OSS community needs to do to prevent future interference. Suggestions like restricting code updates to devs with “good reputations”, even going so far as sating once a project is “critical” in some way it should be taken over or restricted.

The OSS community is not responsible for how their code is used. Hobby and passion projects are not corporations, they generally aren’t even businesses and they certainly aren’t your employees.

Supporting good development practices, funding projects and reinforcing the OSS community are all things that we should be doing already - and are still largely failing at.

So while I agree that projects which become “critical” do need extra defences. I just don’t believe its’s the developers problem. It’s whoever is using that software in a critical way’s problem.

If we want to prevent future incidents like this we also have to recognise that this was as much a human cantered operation as it was a technical one.

If we want to have nice things we also have to protect OSS. It’s passion projects originally written by hobbyists that power your portable game systems or drive your cars. Eliminate them and you eliminate innovation.

Let’s not forget we have struggled to solve human risks for a long time. We have worked to perfect offensive HUMINT for even longer. There is no magical solution to a Dev being coerced, forced or bought.

Defence needs to be in-depth. Detection of human and technical red flags. Full adoption development processes that cryptographically prove committer identity and which use technology to ensure code is verified, examined and tested.

But none of this is really new is it? None of it applies to just OSS. This isn’t an OSS problem, its a problem with people, processes and technology :)

@howelloneill some of the parameters are more pronounced in the OSS ecosystem but are certainly not unique. This is just a sparkling insider threat problem. Companies face the same risks from employees who are coerced, threatened or bribed. I kkownof several cases where nation states applied “pressure” to developers for exactly that reason.

@howelloneill Totally agree. OSS is unique in that a thing some hobbyist built can become a building block that has to be maintained for decades. Corporations get to retire “unsupported code” but this is much harder to do in OSS, and creates its own set of risks. An abandoned open codebase is arguably just as much of a risk.

Someone asked for an explanation about the Xz backdoor in simpler terms.

This was a highly targeted yet massively distributed backdoor. Only systems running the right Xz version with the right systemd/openssh config could be abused. Even then, the attacker had to use the right key at the right time in the right way. 1/3

This attack is not a mass “vulnerability” in the traditional sense. Rather it was specific lock designed to work on a narrow subset of systems with a specific key. The backdoor was cast as wide possible to ensure it reached that subset of systems. All to lay the groundwork for that lock to be in the right systems at the right time for the person with the key. Most of the systems it landed in were just incidental. 2/3

The flaw it exploited was both human and technical: Devs supporting ubiquitous blocks of software. Blocks of software on which everything else is built. Its not a new vector, we’ve seen malicious code commits before. Weve seen entire repos taken over or even sold.

Yet its not one we have a neat solution for. It cant be fixed with donations or SDLCs alone. You cant fix it without addressing both human and technical. 3/3

@malwaretech Good post a couple of things:

Per my post earlier, it seems that following isn’t enough to get ALL of someone’s posts. Some never leave the instance that user calls home. Important for people who follow/monitor for intel etc

You only get organic content from the instance you are on. Its a bit like slack in that regards. I highly recommend dipping in and put of more than one instance. Its the cleanest way to get a good organic stream on a particular subject.

@malwaretech I think its a bug. I noticed first when there was a discrepancy between the post count someone I followed had and the posts I could see. So I joined their instance and there they were.

At least one person in my feed tested it by following their own alt account and confirmed: not all posts seem to get federated to other servers. As yet we can’t see any logic why one post propagates but another doesn’t. Seems to be random though some servers seem worse. Maybe load?