Spyke

composer/packagist has the exact same dependency security risks as node.js.

(Reposted)

Objectively, they all frustrate validation the same. When comparing with a SLSA3-compliant setup where every installed artifact has a signed checksum in a signed bundle from a signed resource on a signed repository, and the endpoint to this is readily available from something like authenticated SNMP into the single source of truth, they all tends to compare poorly.

The chart below completely ignores that Debs are consolidated into a single source of truth as well, and I feel violating SSoT should cost significantly because of dependency holes when artifact registry is incomplete, but SLSA doesn't care about that part.

Ecosystem / Format	Estimated SLSA Level	Update Reliability / Model	Trust Chain & Provenance Comments
(withheld)	3–4	Very high; repo-based, transactional updates	Strong: signed packages + signed repo metadata + central DB; distros enforce reproducible builds.
OCI containers (hardened pipeline: cosign + Tekton/in-toto)	3	High if using automated CI/CD and policy enforcement	Strong if you use signed images + non-falsifiable provenance; this is rare but achievable.
DEB (distro repos)	2	High; repo-based, APT handles dependencies	Medium: repo metadata signed, but per-package signatures not mandatory; weaker checksum chain.
Flatpak runtimes (Flathub)	2	High; centralized runtimes, predictable updates	Medium: signed OSTree commits; build infra more centralized, but not full end-to-end provenance.
Flatpak apps	1–2	High; repo-based, automatic updates	Mixed: OSTree signing helps, but build provenance varies by publisher; no uniform SLSA guarantees.
Snap (strict confinement)	1–2	High; centralized store, auto-updates	Centralized signing by Canonical, but opaque build pipelines; trust is “trust the store operator.”
OCI containers (typical public images)	0–1	Medium; pull-latest model, tag drift common	Usually unsigned; mutable tags; no guaranteed provenance—trust is mostly social and reputation-based.
Snap (classic confinement)	1	High; same store/auto-update model	Same store trust, but classic snaps bypass sandbox; even more reliance on publisher integrity.
AppImage	0–1	Low–medium; ad-hoc self-update or manual downloads	Almost no chain of custody; signatures optional; no central repo or provenance expectations.
npm (JavaScript)	0–1	High frequency, but low reliability of safety; semver + lockfiles	Registry accounts can publish arbitrary tarballs; no default signed provenance; transitive deps explode risk.
PyPI / pip (Python)	0–1	Similar to npm; pip + requirements/lockfiles	Tarballs/wheels from arbitrary maintainers; no mandatory signing; provenance work (e.g., PEP 740) is emerging but not standard.
Composer / Packagist (PHP)	0–1	Good tooling, but same “trust the registry” model	Packages pulled from Packagist/VCS; no mandatory signatures; dependency graph trust is social, not cryptographic.
CPAN (Perl)	0–1	Mature ecosystem, but manual/legacy in many flows	Historically minimal provenance; mirrors and authors are trusted by convention, not by SLSA-style attestations.
Other language registries (RubyGems, crates.io, etc.)	0–1	Similar to npm/PyPI; lockfiles help reproducibility	Central registries, but no default SLSA provenance; integrity is mostly TLS + registry operator trust.

redsand

infosec.pub

Hot take. Node is cancer. It's the new PHP but worse because it's not just websites and the dev community is more toxic.

macniel reply

feddit.org

You say as if you can't make php shell scripts or GUI apps :)

redsand reply

Stop giving them ideas

Them already did.

realitaetsverlust reply

piefed.zip

PHP was only worse because of the syntax. The ecosystem around it with composer and other tools has always been superb.

lurch (he/him) reply

sh.itjust.works

Ecosystem / Format	Estimated SLSA Level	Update Reliability / Model	Trust Chain & Provenance Comments
(withheld)	3–4	Very high; repo-based, transactional updates	Strong: signed packages + signed repo metadata + central DB; distros enforce reproducible builds.
OCI containers (hardened pipeline: cosign + Tekton/in-toto)	3	High if using automated CI/CD and policy enforcement	Strong if you use signed images + non-falsifiable provenance; this is rare but achievable.
DEB (distro repos)	2	High; repo-based, APT handles dependencies	Medium: repo metadata signed, but per-package signatures not mandatory; weaker checksum chain.
Flatpak runtimes (Flathub)	2	High; centralized runtimes, predictable updates	Medium: signed OSTree commits; build infra more centralized, but not full end-to-end provenance.
Flatpak apps	1–2	High; repo-based, automatic updates	Mixed: OSTree signing helps, but build provenance varies by publisher; no uniform SLSA guarantees.
Snap (strict confinement)	1–2	High; centralized store, auto-updates	Centralized signing by Canonical, but opaque build pipelines; trust is “trust the store operator.”
OCI containers (typical public images)	0–1	Medium; pull-latest model, tag drift common	Usually unsigned; mutable tags; no guaranteed provenance—trust is mostly social and reputation-based.
Snap (classic confinement)	1	High; same store/auto-update model	Same store trust, but classic snaps bypass sandbox; even more reliance on publisher integrity.
AppImage	0–1	Low–medium; ad-hoc self-update or manual downloads	Almost no chain of custody; signatures optional; no central repo or provenance expectations.
npm (JavaScript)	0–1	High frequency, but low reliability of safety; semver + lockfiles	Registry accounts can publish arbitrary tarballs; no default signed provenance; transitive deps explode risk.
PyPI / pip (Python)	0–1	Similar to npm; pip + requirements/lockfiles	Tarballs/wheels from arbitrary maintainers; no mandatory signing; provenance work (e.g., PEP 740) is emerging but not standard.
Composer / Packagist (PHP)	0–1	Good tooling, but same “trust the registry” model	Packages pulled from Packagist/VCS; no mandatory signatures; dependency graph trust is social, not cryptographic.
CPAN (Perl)	0–1	Mature ecosystem, but manual/legacy in many flows	Historically minimal provenance; mirrors and authors are trusted by convention, not by SLSA-style attestations.
Other language registries (RubyGems, crates.io, etc.)	0–1	Similar to npm/PyPI; lockfiles help reproducibility	Central registries, but no default SLSA provenance; integrity is mostly TLS + registry operator trust.

demizerone reply

lemmy.world

I was saying that shit in 2015! Minus PHP, it has a soft spot in my heart ❤️.

🦄🦄🦄

Would be funnier without the LLM slop

zeroConnection

programming.dev

Where's that slop image coming from? Did you seriously generate a slop image to add to this post?

mycodesucks

"npm" is an abbreviation of the package vetting methodology.

No Process, Motherf***er

mogoh

lemmy.ml

Do other packe manager prevent this?

kopasz7 reply

The problem isn't the package manager. Many small dependency packages multuply the attack surface of the "supply chain". (it isn't even a supply chain when a dude opensources his code as-is then a company decides to build their whole business on it)

Aniki reply

it has nothing to do with the package manager and everything with JS being a very widely used language mostly by rather inexperienced web devs.

demizerone

I pulled in a webcomponent at work and got 300 plus deps. Fml.