cloudfoundry / cloudfoundry/stratos

Feature Request: Highlight apps using deprecated buildpacks

Open
#3,128 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

community feature-request
Dominant language
TypeScript
Stars
267
Forks
137
Avg merge
5h 14m
Merged PRs (30d)
77

Description

Detailed Description

An additional 'needs maintenance' status that would be used to indicate when an application is running on a buildpack which is no longer present on the platform.

Context

It is good practice to ensure that applications running on CloudFoundry are running on an up-to-date buildpack. Many platform teams will roll out new buildpacks as they become available to ensure protection against CVE vulnerability threats and will then deprecate the older less-secure buildpacks. This practice of removing older buildpacks ensures that newly-pushed apps will consume the newer buildpack, but unfortunately any apps already running on the platform will be unaffected and may continue to run indefinitely using a potentially vulnerable buildpack. In order to remain protected against vulnerabilities applications need to be re-staged or re-pushed against the new buildpack.

Stratos already shows a number of different status (Online, Updating, Crashed etc) - And additional status type to indicate that an application is using an obsolete buildpack would help app teams to become aware that their app needs a restage or re-push to keep it up to date with newer buildpacks. This would generally enhance security for everyone.

Possible Implementation

Stratos is already reporting buildpack information obtained from the /v2/apps api endpoint using a combination of the 'buildpack' and 'detected_buildpack' fields.
If this was tallied up with the buildpack names from the /v2/buildpacks endpoint then it would be possible to identify which apps are reporting using versions which are not listed by the buildpacks endpoint.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the existing /v2/apps data, especially the buildpack and detected_buildpack fields, then inspect how /v2/buildpacks data is loaded and how application statuses are rendered. Done means applications using buildpacks absent from /v2/buildpacks are visibly identified as needing maintenance, with the behavior covered by the relevant existing tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
angular, typescript
Domain
api, cloud, frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.