I still think metadata associated with packages (like stars, download count and more) are easy to fake and not the best metric. OpenSSF scorecard has some adoption among project maintainers but hardly any adoption in terms of making security decision based on it.
IMHO code is the source of truth. It may seem infeasible to mass analyse OSS code, but given the recent incidents (Shai-Hulud et.al) I think that’s the way forward. Personally am more bullish on SLSA or other artefact provenance technology adoption. Till that happens, metadata will be misused by attackers.
Thank you for this thoughtful critique—you're absolutely right about metadata manipulation risks.
To be clear: OSS Sustain Guard is not a security tool. I have deep respect for OpenSSF Scorecard, SLSA, and supply chain security work. That's the critical path forward.
We're solving a different problem: maintainer well-being and sustainability. Not "Is this code secure?" but "Are the humans behind it okay?" I want to surface which projects might need community support.
You're right about the limitations:
- Metadata can be gamed
- Private work is invisible
- These are proxies, not truth
Where we're complementary:
- SLSA/Scorecard: "Is this artifact secure?"
- OSS Sustain Guard: "Does the maintainer need support?"
A solo maintainer with perfect security practices can still burn out without funding. That's the conversation I want to start--not to criticize, but to encourage support.
I'd genuinely value your input: Given your expertise in supply chain security, what would you want to see from a sustainability-focused tool that would make it more useful alongside provenance technologies? Are there signals that would be harder to manipulate?
Thank you for taking the time to engage with this project. These conversations help me stay grounded and improve.
This is crazy. The internet has so much direct and transitive dependency on Cloudflare today. Pretty much the #1 dev slacking excuse today is no longer code compiling but cloudflare is down.
Building vet. The goal is to automate open source package vetting beyond just CVE but actually identify code capabilities, malicious code and other security sensitive attributes through code analysis.
Good idea. Just the other day I was thinking of writing a templatized generator for coding agent instructions for various agents like Claude Code, GitHub Copilot and others that use their own unique file convention.
- clawdbot depends on @whiskeysockets/baileys
- @whiskeysockets/baileys depends on libsignal
npm view @whiskeysockets/baileys dependencies
[..] libsignal: 'git+https://github.com/whiskeysockets/libsignal-node.git', [..]
libsignal is not a regular npm package but a GitHub repository, which need to be cloned and built locally.
So suddenly, my sandbox profile, tuned for npm package installation no longer works because npm decides to treat my system as a build environment.
May be genuine use-case but its hard to keep up.
reply