[6/6] I'm curious about what others think. I think it would be a great OSS project (and potentially it could join OSSF)

ofc it will never be as good as Socket or Snyk, but it should still be a decent line of defense. A lot will integrate with existing tools, e.g., Guarddog

[5/6] I have a very solid (and exciting) vision for it and clear & measurable goals written down, and a roadmap. Most things are ready, if all goes well a MVP could likely be done within weeks

Biggest concern: it flops or goals aren't being achieved
I'm most excited about: modularity (→ plugins)

[4/6] Security shouldn't be a blocker for growth, it should be affordable without scarifying quality and visibility, especially when supply chain attacks keep going up: we need powerful tools to be accessible to everyone

[3/6] Free versions of these products are too basic and create a huge gap in observability, auditing, and capabilities

On top, they are fairly vendor-locked as they are companies trying to sell security products (⇒ for obvious reasons they don't integrate w/ tools from their competition)

[2/6] Target audience: small businesses (non-Enterprise) who need visibility (SIEM) & need to protect their developers

There are paid tools on the market for this: Socket, Sonar, Vera Code (and they look amazing!) while their price is right, they cost an arm for small businesses.

Recording: www.youtube.com/watch?v=TK5T...

We disclosed two new RSC vulnerabilities:
- Denial of Service (High): CVE-2025-55184
- Source Code Exposure (Medium): CVE-2025-55183

Patches are available now, please update immediately.

react.dev/blog/2025/12...

That post was an unexpected (pleasant) rabbithole:
- mcp-scan uses invariant
- Invariant is a tool to write rules (tiny bit similar to Semgrep) to scan MCPs
- Can create rules that detect PIIs
- PIIs are found using the PyPI project presidio

Full of TILs, and tons of neat to play with! Thanks!

The main danger though is being unable to fix CVEs without fixing breaking changes first (rushing breaking change fixes because of a CVE are one of the worst thing to do), but urllib3 has a good track record: v1 didn't reach EOL for a very long time thus users have ample time to migrate

I think the answer lies in the last paragraph of your article: force the change, otherwise a large portion of users will never do the change

Unfortunately with teams with very limited time it can be difficult to address all warnings, they often get dealt with once it breaks (i.e., the breaking change actually occurs).

I learned that opening tickets simply doesn't work, work will never be picked up

Looks great!

If it's intended for full-screen viewing: text could be a tiny bit smaller so we can see more code at once (feels a tiny bit too big & I'm able to read the text easily despite my poor eyesight 😉)

If it's meant to be projected or viewed in non-fullscreen mode then don't touch it IMO 👌

That's quite interesting, we can find the list of flatpaks having such permission here: github.com/search?q=org...

Thank you for sharing! That was an amazing talk. This is really saddening, I hope we manage to slam on the brakes

Clever way of making it interesting! Instead of "Ugh, another cookie popup!" :D

Props on them!

Darn, you were so healthy in yesterday's FireSide chat! Hope you get well soon!

Should we call 911? Are you still alive?

Rough start but I'm sure it will get much better, good luck!