Most IAM policies start as "whatever made the deploy pass." Need rds:CreateDBInstance? Fine, rds:* it is. Ship it. Months later that same role can wipe the cluster and nobody remembers why it ever had that permission.

Separate accounts help, but only if someone actually goes back and cleans it up, which… yeah, doesn't really happen.

There's a GitHub issue for the freeze thing. Their security scanner passes the full dep list as CLI arguments, large monorepo on Linux and you blow past ARG_MAX. Spawn silently hangs, no error, --ignore-scripts doesn't help because the scanner is separate from postinstall. Been broken since 1.3.5 at least.

designed, but never tested

We went through the same switch. Half our alerts had been firing for a while and nobody ever acted on them.

Firefox at least randomizes extension IDs per install. Chrome hands all of that to extension devs, basically a "your problem now".

Stale training data is part of it. But even a current model can't tell what setup.py is going to run on your box. Nothing actually inspects the package before it executes. You'd want something that pulls the metadata and checks what hooks are in there before anything runs.

Built Packj [1] to do exactly this.

1. Packj (https://github.com/ossillate-inc/packj) detects malicious PyPI/NPM/Ruby/PHP/etc. dependencies using behavioral analysis. It uses static+dynamic code analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect bad actors (e.g., typo squatting).

Common mistake is trusting the repo instead of the workflow. Then any workflow inherits the same cloud access.

Browsers already treat the same SVG differently depending on how you embed it. <img> strips scripts and external resource loads. <object> and inline don't. People test with img tags, looks fine, then someone switches the embed method and everything opens up.

it'd be nice if there was a way to declare in the URL that a given SVG could only be treated as an image so that you could safely open SVG urls, etc without exposing yourself to the dangers of embed/inline.

Couldn’t you do that using Content-Security-Policy?

If you control the domain then yes you could. But if I want to put a link on my website to some SVG hosted elsewhere and I want it to be safe for you to open that link in a new tab then there's not really a way for CSP to protect you the user from the host deploying a malicious SVG.

Like opening a PNG in a new tab is harmless but opening an SVG in a new tab is opening a pretty substantial can of worms.

If your threat model is “I don’t want the image I’m hotlinking to be replaced with something else when opened in a new tab”, then no image format is safe.

That's not particularly true?

A malformed JPEG or PNG might have potential vulnerabilities but they are considered a failure of the browser or parser lib to mitigate.

An SVG however has vulnerabilities and those are directly built into the spec of well formed SVGs.

What vulnerabilities do you have in mind?

Well as an example: Lets say I maintain a hypothetical appview for an atproto service and we support SVGs. Users can upload SVGs via our appview or directly to their PDS and we pick them up when the network propagates record updates.

So users can view SVGs embedded in our site and they are regular vanilla SVG images. But say the user copies a link to this image (which we serve via our site or a CDN).

They share the image to a friend via URL and their friend clicks the link opening it directly in firefox or chrome. Now all the scripts in the SVG can execute and the image can rewrite the DOM to present itself as a fake website prompting them to log into their bluesky/atproto account to view the content. So said friend types their credentials in and the script in the SVG sends that back to their C&C server.

We added a preflight curl against registry.npmjs.org before the install step in CI. Not surprising they went down together.

Downtime is one thing. Silently reverting commits on your default branch is something else entirely.