Dependency security/update checking flow
Debian has a security fix for openSSH. Organizations without GitLab walk into the office and see that 1000 applications need to be updated. Organizations with GitLab walk into the office and see that 999 applications were updated successfully and 1 had to be rolled back. We can do this because we have monitoring integrated into GitLab, we're not deploying into a black hole but can see if the application still meets the service level objectives.
Have a story version of the vision on the direction page.
- Start with container scheduler.
- Use web terminal and local editor to create something.
- See auto deploy with automatic parallel tests and review apps.
- Debian package used in your container has a security fix.
- GitLab auto detects you have that dependency and creates a new build.
- The changelog is updated automatically.
- In the merge request you can see the metrics and SLO (service level objective) was not met and after deploying to 1% it was reverted.
- All this happened automatically after Debian pushed to stable.
- Luckily when you check the next day your application is not vulnerable.
- So you use chat to close the issue that was automatically opened after the failed deploy.
- An early user of your service also emailed GitLab service desk to ask if the Debian security update is addressed.
- You create a blog post via the web terminal that is published with GitLab pages.
I'm not sure this should go on the direction page as it's severely overloaded already, but explaining our vision by using a story/flow is an effective tool.
/cc @sytses
Links
- [meta] VersionEye integration
- New site: shield.gitlab.com
- GitLab License finder
- VersionEye - Display in Merge requests list view
- VersionEye - Display information in the Merge request details view
- VersionEye - Display in Commits list view
- VersionEye - Add option to activate GitLab Version Service to the administration panel of a repository
- VersionEye - Settings panel for GitLab Version Service
-
Developer
This is pretty heavily focused on dependency checking. I wonder if this should be reduced to just cover dependency checking, and then put into a section/issue appropriate for that, rather than as an overall vision for GitLab. e.g. only include 4-11.
-
-
changed title from Dependency checking flow to Dependency security/update checking flow
Toggle commit list -
Owner
@markpundsack I propose that the SLO fails because the request error rate goes above 0.1%
-
Developer@markpundsack Auto created merge request with updated version. I randomly chose eslint because I wasn't sure where to find an update to debian in a file. If you have a better suggestion I would be happy to update.
-
Developer
I am assuming we want to use something more related to security. What would be good to use here in place of eslint?
-
Developer
@tauriedavis Yeah, you're not going to find an update to Debian unless you're looking at Docker images with Debian as a base image, which is going to be hard to find on
gitlab-ce. :) -
Developer
@tauriedavis Maybe a bump to
es6-promise? Or a bump inrailsin Gemfile? -
Developer
Or
jqueryorwebpackorvue... -
Developer
-
Developer
@tauriedavis Looks awesome!
Small thing, but maybe the automerge should be by GitLab Shield or GitLab Bot.
I'm not sure
productionshould have a Stop environment button. That feels like a disaster waiting to happen. :) -
Developer
I'm not sure
productionshould have a Stop environment button. That feels like a disaster waiting to happen. :)hehe Removed! Also updated mockup to show GitLab Bot
-
-
-
-
Owner
@markpundsack I added the following to the top of the description: "Debian has a security fix for openSSH. Organizations without GitLab walk into the office and see that 1000 applications need to be updated. Organizations with GitLab walk into the office and see that 999 applications were updated successfully and 1 had to be rolled back. We can do this because we have monitoring integrated into GitLab, we're not deploying into a black hole but can see if the application still meets the service level objectives."
-
-
-
-
