This is tied to the TeamPCP activity over the last few weeks. I've been responding, and keeping an up to date timeline. I hope it might help folks catch up and contextualize this incident:

https://ramimac.me/trivy-teampcp/#phase-09

This is fantastic, thank you. Your reporting has been great. But also, damn, the playlist.

Thanks for putting this together. I've been seeing the name TeamPCP pop up all over, but hadn't seen everything in one place.

This is interesting. How do you keep this up to date so quickly?

Blood, sweat, and tears.

The investment compounds! I have enough context to quickly vet incoming information, then it's trivial to update a static site with a new blurb

> Upon issue creation another workflow spins up three independent coding agents to analyze the finding.

I'm curious

1) what the current statistics are for consensus

2) how the agents may/may not perform independently

3) what the agent profiles are and how they differ (model, harness, prompt/persona, all three?)

1. I dont have hard metrics at hand but with the latest Sonnet I'd say we reach consensus around 80% of the time, with Opus is almost always but we are not using it due to cost

2. The difference I see in agent behavior when they don't reach consensus is usually either

- when one of them didn't explore enough and lack context

- and/or when their risk assessment is off

The latest happen often, in other workflows based on agents we are now giving clear instruction on how to assess risk and where to draw a line to consider something a true positive.

3. validation is on Sonnet, we don't use persona based prompts but all the 3 validators get's the same task and context. The agent orchestrating them will take their output and make the final decision. We use an internal fork of the claude code github action for now.

Reach out if you'd like me to check - I did the same for the trigger.dev team in fact[1].

(personal site linked in bio, who links you onward to my linkedin)

[1] https://x.com/ramimacisabird/status/1994598075520749640?s=20

Probably, but you can check out a more robust list here: https://blog.cloudflare.com/tag/acquisitions/

* BastionZero

* Kivera

* Baselime

* PartyKit

* Area 1

* Vectrix

* Zaraz

* Linc

* S2 Systems Corporation

* Neumob

* Eager

* CryptoSeal

* StopTheHacker

Not everything seems to be tagged as acquisition. Dyte.io was acquired, and announced here: https://blog.cloudflare.com/introducing-cloudflare-realtime-...

Always a funny title, see previously: Announcing the New AWS Secret Region (2017) [1]

[1] https://news.ycombinator.com/item?id=15741108

It's not a coincidence - this attack is directly downstream of s1ngularity

Hi! Author here who added the VSCode stat :)

I thought it was useful to include because:

* it can inform triage, if you use the extension you're more likely to be impacted * because it was VSCode, Workplace Trust actually partially mitigated this in at least 38 cases

The vocoder extension does not contain any affected packages, it‘s just misleading

I have evidence of at least 250 successes for the prompt. Claude definitely appears to have a higher rejection rate. Q also rejects fairly consistently (based on Claude, so that makes sense).

Context: I've been responding to this all day, and wrote https://www.wiz.io/blog/s1ngularity-supply-chain-attack

In case it's helpful, I also collate quality blog posts in this genre over at https://rami.wiki/soc2/

I get a 404 currently, fwiw.

Fixed! Pages drops the custom domain whenever I push right now, have been putting off debugging it - apologies

If I understand the issue correctly, you just need a file called CNAME in the root of your repo containing your custom domain, like this: https://github.com/justusthane/justusthane.github.io/blob/ma...

Thanks! Unfortunately, I've somehow fallen off the paved road :) https://github.com/ramimac/wiki/blob/main/CNAME

GH Pages is particular about how your apex and www records are set up. I believe you need apex A records pointing to

185.199.108.153 185.199.109.153 185.199.110.153 185.199.111.153

which you already have. Your CNAME record at www.rami.wiki needs to point to "ramimac.github.io/wiki", and your CNAME file in the root of your repo needs to contain "www.rami.wiki" (www is necessary).

At this point, https://rami.wiki should automatically redirect to https://www.rami.wiki.

At least, that's more or less how mine is set up and it works for me :) I had the same issue as you until I got that all straightened out.

It's not available in this case, or every case. When available, you can search "The data was provided by" in https://haveibeenpwned.com/PwnedWebsites

Thanks! Slight correction: only 2 breaches say "provided by" with a source, but a ton of breaches say "provided to" HIBP with a source.