Skip to content

Consider support for auto-restaging of vulnerable droplets.TUF helpful ? #231

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gberche-orange opened this issue Sep 16, 2015 · 6 comments

Comments

@gberche-orange
Copy link

In addition to cloudfoundry/java-buildpack-dependency-builder#6 to prevent injection of malicous code into the binary repository, I'm wondering how much The
Update Framework (TUF)
can be beneficial to the java buildpack when running in the easy or expert mode, especially to protect against the following attacks.

Is the HTTPS transport and high availability/throughput/Dos prevention of AWS S3 sufficient ? What about in the case of the expert mode, how hard is it reach such level in a private setting ?

Let me know if you prefer this discussion to happen over cf-dev@ instead.

@gberche-orange
Copy link
Author

Thinking it through, I now realize that the link between TUF and the java-buildpack artifact downloading is a bit streched: even though the repository is designed so that the latest available libs are visible as candidate when staging a java app, droplets are immutable, and therefore don't really update under the responsibility of the java buildpack.

Therefore CF apps are hardly exposed to TUF targetted attacks, unless we consider an app restaging as an update process that could suffer from these attacks and benefit from TUF mechanisms.

However, currently the restaging of an app is a manual operation, and cloudfoundry does not yet automate the detection that new updates are available in the java-buildpack easy mode, and that a staging could be desireable.

So while related to the java-buildpack and its "easy mode" that provides ability to serve new dependencies, this discussion should rather be made wider with MEGA/runtime/buildpacks team as a way to autodetect droplets that would require a restaging to benefit from pending available updates of some of their dependencies.

@gberche-orange gberche-orange changed the title Consider securing java-buildpack dependencies. TUF helpful ? Consider support for auto-restaging of vulnerable droplets.TUF helpful ? Sep 16, 2015
@cgfrost
Copy link
Contributor

cgfrost commented Sep 18, 2015

Added tracker issue - https://www.pivotaltracker.com/story/show/103661354

@nebhale
Copy link
Contributor

nebhale commented Sep 21, 2015

@gberche-orange The wider buildpacks team is reviewing this. I'm tempted to close this and simply handle it once a platform-wide system is delivered. Thoughts?

@gberche-orange
Copy link
Author

Thanks @nebhale for your review of this suggestion. Do you have a pointer to a story on the buildpacks / MEGA tracker that could be followed ? If so, then sure it makes sense to close this conversation here.

@nealmcb
Copy link

nealmcb commented May 26, 2017

These problems are tricky, asTUF's list of attacks illustrates, and as the events of the last few years underscore. So I'm glad to see TUF brought into a conversation of secure Java packaging, installation, building and deployment.

Any updates on updating? Any pointers to a broader platform discussion of this?

@nebhale
Copy link
Contributor

nebhale commented Jan 8, 2019

At this point we're not going to deal with this problem in the Java Buildpack. With the advent of Cloud Native Buildpacks and their more explicit dependency management future concerns about this will be handled there.

@nebhale nebhale closed this as completed Jan 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants