search

denoland / deploy_feedback

For reporting issues with Deno Deploy
https://deno.com/deploy
74 stars 5 forks source link

Immutable deployments like jsr does with packages #683

Open inverted-capital opened 2 months ago

inverted-capital commented 2 months ago

What problem are you trying to solve?

JSR automatically creates provenance statements for each package that is published from GitHub Actions giving strong guarantees as to the connection between the package and the source code:

image

Deno deploy projects do not have this but seem incredibly close to being able to do so - the act of publishing should be optionally taken out of the hands of the developer after the push to source code so we could deliver a web app into a users browser with provenance guarantees.

This would be like SLSA compliance but for our actual web app, not just the packages we consumed to make it.

Describe the solution you'd like

Deno Deploy projects should allow a one way only lockdown mode that makes the project go immutable (as in, no more changes from the developer except for source code pushes).

The leakiness in Deno Deploy step is the last and seemingly tiny step in realizing that subtle but profound provenance state - being able to easily and rapidly trace the provenance of a web page back to source code. I could then pass the security and compliance guarantees of Deno Deploy DIRECTLY to my customers. This is a very compelling reason to drop whatever else you're doing and build on Deno Deploy.

The page for the deployment can then become much like the jsr.io page for a package, where it provides the audit trail, and can give it a score for all its consumed packages in terms of their provenance scores, and any known vulnerabilities, plus provable association with respective source code. The source code need not be public for this page to exist and be useful, as a private repo can be pointed to, and then access shared to interested parties.

To sketch this out further, the immutable hosting score could be comprised of:

  1. what permissions have been allowed to the hosting deno runtime
  2. what outbound network connections are allowed - blanket net permissions is bad, restricted is less bad, none is best
  3. use of eval anywhere, which could run user uploaded payloads
  4. use of env vars, where a perfect score is no env or public envs as these can inject unauditable behaviour (obviously this would require at rest encryption to be built in to deno kv or something else to safely inject a seed for a key)
  5. lockdown of kv store for external reading, or external writing
  6. immutability score of all the dependencies, which if using jsr, can be derived from their score

The ideal publication would be an app with no env vars, no outbound network, kv store only readable to the app, and only fully provenance attested jsr.io packages used as dependencies.

Describe alternatives you've considered

The closest thing is a blockchain type of smart contract, but even this does not have attestation of build back to source. Original comment: https://github.com/kitsonk/kv-toolbox/issues/13#issuecomment-2089296461

Documentation, Adoption, Migration Strategy

No response

ry commented 2 months ago

This is a very interesting feature that we’ve been pondering already. Glad to have an issue to track it.