securesaml

Nice find. The tokens being leaked in actions log was not one of the security implications I thought of when they released the feature.

How many other actions/libraries do you think are vulnerable?

there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?

it is less of a problem for revoking attacker's keys (but maybe it has access to victim's contents?).

agreed it shouldn't be used to revoke non-malicious/your own keys

I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint. Alternatively do this in a private repo and enable token revocation (if it exists)

I'm not too sure about the root cause about tj-actions. IIRC there are some libraries that compromised by actions injections vulnerabilities, where a security specialist could have helped.

I have seen small utility libraries like tj-actions get compromised because there aren't any security specialists looking at the library.

My main concern is supply chain compromise.

The problem is lots of open source is unmaintained/insecure, and there aren't any security engineers on those open source libraries.

For the library to be secure, there needs to be funding, not by magic and expecting maintainers will do stuff on there free will.

Correct, maintainers can say that and get shamed.

And it leads to unmaintained libraries, since companies don't want to pay.

At some point, is open sourcing your work a liability?

The problem is more so maintenance.

The expectation of FOSS is that the users and maintainer work together to resolve bug fixes/features/security issues.

However many companies will dump these issues to the maintainer and take it for granted when they are resolved.

It's not a sustainable model, and will lead to burnout/unmaintained libraries.

If the companies don't have the engineering resources/specialization to complete bug fixes/features, they should sponsor the maintainers.

I agree MSFT should have paid way more.

My point is if that FFmpeg, tried to raise more awareness of the issue, say talk to news outlets, they could get much more funding from MSFT.

Furthermore, big companies like Google, Microsoft care a lot about security. So they could raise money for security engineering like fixing memory corruption issues. Of course, FFmpeg could complain Google, Microsft doesn't care about all the high severity vulnerabilities in FFmpeg. That would be much more of an eye catcher.

It's usually the more user-facing products that can thrive on this freemium model (probably full web apps or a lot of code). For example, laravel might get a lot of funding from this.

However, the underlying infrastructure libraries, will not get any funding from this, even though they have much more users. For example, libxml2, xzutils, http parser ...

You can't build any product off of an infrastructure library, purchasing support doesn't make sense, and there are little bonus features to be made.

One way to remedy this, is to have well funded open source projects take ownership of its dependencies.