Been tracking this project for a while https://github.com/chains-project/ghasum . It creates a verifiable checksum manifest for all actions - still in development but looks very promising.
Will be a good compliment to Github's Immutable Actions when they arrive.
Inertia is "dumb" in that a component can't request data, but must rely on that the API knows which data it needs.
RSC is "smarter", but also to it's detriment in my opinion. I have yet to see a "clean" Next project using RSC. Developers end up confused about which components should be what (and that some can be both), and "use client" becomes a crutch of sorts, making the projects messy.
Ultimately I think most projects would be better off with Inertia's (BFF) model, because of its simplicity.
Great question! PyPI already supports Trusted Publishers [1], which gets you most of the benefits of SLSA build provenance (provable link between artifacts and a public software repository). Implementing Trusted Publishers is the recommended first step for ecosystems looking to implement build provenance [2].
> Next step ist to establish good tooling around publishing VEX statements (Vulnerability Exploitability Exchange). That is currently not easy.
Agreed.
Tooling is needed for creating/publishing/consuming both VEX statements for applications (i.e. exploitability of a dependency in context), but also VEX statements from library authors (many times the actual experts, like the OP) as a way dispute the weakness/exploitability.
Currently working hard on this [1]. When the tooling is in place the next step for the industry will be discoverability of SBOM/VEX/VDR attestations. Sigstore/Rekor [2] looks to be a viable alternative here.
> Vulnerabilities are reported (using CPE, pURL etc.) at the "library" or "application" level but they really exist at a much more granular level (e.g. a single function is affected and if that's not used there's no problem).
Again, agreed. Reachability info needs to be commoditized, standardized and shared. The current situation where it's a feature used by vendors to compete is not ideal.
The best kind of "problem" to have. Expect to build features, integrations and other customizations, and factor in the costs. You can do that with a higher "base" price, or include professional services into the contract (but be careful with IP rights). Use a per-seat model internally (more users = more support etc) and offer fixed price point per year. Expect to them to want to negotiate a large discount on the "list" price, so start higher than you might think.
DISCLOSURE: I'm working on commercial tooling for this exact problem [1]
> 1) What would your expectations be towards a software vendor in terms of what issues to "fix"?
I would want the vendor to communicate their analysis for all CVEs, i.e. letting us know which are exploitable or not, and what kind of response they are planning, or any fixes released.
There are efforts to standardize this workflow with Vulnerability Disclosure Reports (VDRs)[2] and Vulnerability Exploitability eXchange VEXs[3]. Both these use cases are covered by OWASP CycloneDx[4].
> 2) Is anyone aware of a security database & evaluation tool geared for vendors not for end-users?
IMHO, there are not any good tools available that solve the complete workflow. We are certainly aiming to fix that with[1], but it will take some time.
Good to see some OSS alternatives showing up!