My team guards up front when introducing a new dependency. You fill out a little template with security assessment as well as some other stuff, just to do a dirt simple build vs 'buy' analysis. left-pad for example would fail because the build time cost savings are not worth the ongoing maintenance cost. (In fact doing this assessment at all rarely makes sense for microlibs, by design.)

Once something's in package.json I don't believe anyone who says they can vouch for the security of that over time. We're all doing security theater with npm audit, dependabot, etc. Don't use npm at all if anyone's life depends on your code.

I think formlising an assessment like that makes some sense, but the question was more around what the assurances are. So it probably works like this:

#1 You look at the dependency and do an assessment on whether it's worth including. Check.

#2 You probably require some automated checks. SAST, Depedency Scanning / SCA, maybe some DAST, etc. Check

The outstanding question though...

#1 Did anyone actually read the code of the depedency?

#2 Did anyone actually look at what the depedency itself pulls in?

#3 Are these checks re-done when you update the lock files?

#4 If nobody is doing it, who's updating the lists and rules we use to scan from?

#5 Where possible do you have the monitoring to check when an app is doing something weird? i.e. network ACLs that when they fail, cause an event, that alerts a person to investigate?

I think we're mostly agreeing here, but the wider question is why is it that folks writing the app and including the depdency don't feel responsible for these things?

GH actions doesnt, Azure devops does

I think you mean they're automatically doing SCA and maybe SAST. I don't think there's a human working at microsoft reading the code for you though, is there?