initial user stories #72
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,125 @@ | ||
| # GLVD User Stories | ||
|
|
||
| # USER-01 | ||
|
|
||
| As a user of Garden Linux I want to know about security issues in Garden Linux so I can operate my systems responsibly. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] The user can query for known CVEs of a list packages | ||
|
There was a problem hiding this comment. Should it not be the other way around? I think it's more important to query a release and get the CVEs back found within a given release? I might be just cherry-picking on the language side here. There was a problem hiding this comment. This might be a misunderstanding (and I see that the sentence is not very precise, thanks for pointing that out) My current api draft looks like this "Give me all CVE for Debian Bookworm": GET https://glvd.gardenlinux.io/v1/cves/debian_linux/bookworm "Give me all CVE for packages vim and firefox-esr in Debian bookworm": GET https://glvd.gardenlinux.io/v1/cves/debian_linux/bookworm/packages/vim,firefox-esr (passing the package list comma separated might be a bad design choice, I have not yet evaluated alternatives like passing them in the request body) Does that make sense? |
||
|
|
||
| ## Additional details | ||
|
|
||
| - This does not yet require a nice user interface, an HTTP API is sufficient | ||
| - This does not yet include knowledge about which packages are included in any given Garden Linux image, the user provides a list of package names and versions | ||
|
|
||
| # USER-02 (lower prio) | ||
|
|
||
| As a user of Garden Linux I want to subscribe to updates on new security issues in the packages I care about. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] The user can get notifications for new known CVEs affecting their list of packages | ||
| - [ ] The user can unsubscribe from notifications | ||
|
|
||
| ## Additional details | ||
|
|
||
| - This might be implemented in an anonymous way where the user gets a tracking url/rss feed they need to bookmark | ||
| - The backend/db needs to keep track of tracking urls | ||
| - Users might want to subscribe with their email address; this introduces a new class of issues legally (data protection) | ||
|
|
||
| # USER-05 | ||
|
|
||
| As a user of Garden Linux I want to be notified of new CVEs in the Garden Linux patch version I'm using. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] I can select the Garden Linux version (like 1443.5) I'm using to be notified on new CVEs for that specific version | ||
| - [ ] I get a notification for new patch releases in that version (like 1443.6) so I can upgrade as soon as possible | ||
| - [ ] I can select a Garden Linux major version (like 1443) to be notified on new and fixed CVEs in that version | ||
|
|
||
| # USER-06 | ||
|
|
||
| As a user of Garden Linux I want to be notified of new major versions of Garden Linux so I can plan to upgrade. | ||
|
|
||
| # USER-07 (higher prio) | ||
|
|
||
| As a user of GLVD I want a simple web interface to work with the service in a convenient way. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] Features described in the previous user stories can be accessed in a minimal web interface, similar to debian security tracker UI | ||
|
|
||
| # USER-08 | ||
|
|
||
| As a user of GLVD I want a CLI tool to interact with the service. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] Features described in the previous user stories can be accessed using a command line tool | ||
|
|
||
| # USER-09 | ||
|
|
||
| As a user of Garden Linux (container images) I want to be informed about additional issues installed packages bring. | ||
|
There was a problem hiding this comment. I might be too much to ask for, but I would love to have a moth type of message in case a given release becomes vulnerable. Ubuntu does this in a more gravy-ish way, by including it with the Please tell me if I want overboard here. There was a problem hiding this comment. Sounds reasonable to me, and I'm not aware of any challenges with this yet.. This would mean that an http request needs to be done each time the motd is shown/updated, maybe caching would be good there and maybe this should be an optional feature.. but I like the idea. Regarding the Gardener use-case of GL I think this is not super common that people login via ssh and will see the motd, but maybe we should also look into more observation tooling such as Prometheus? Just thinking about that now. |
||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] A 'apt install' cli wrapper prints information on additional CVEs introduced by that package | ||
|
|
||
| # De-prioritized user stories | ||
|
|
||
| # USER-03 | ||
|
|
||
| As a user of Garden Linux I want to track security issues in any given Garden Linux *image* so I can make an informed decision about needed actions in my system. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] The user can query for Garden Linux images such as `gardenlinux-gcp-gardener-prod-amd64-1443-5-bfb687a7` | ||
|
|
||
| # USER-04 | ||
|
|
||
| As a user of Garden Linux I want to track security issues that additional packages bring into my image. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] The user can provide additional packages from the Garden Linux APT repo (in the same release as the image in use) | ||
|
|
||
| # GLDEV-01 | ||
|
|
||
| As a developer of Garden Linux I want to assess the security impact of adding packages to Garden Linux images. | ||
|
There was a problem hiding this comment. I do not quite what you are trying to do here? Is this about the mapping for a given vulnerability to our product, or the generic impact assessment of a CVE? There was a problem hiding this comment. This means the 'triage' thing we're currently doing. What we get is something like 'vim in versions before x may have CVE-123', and we might want to add information there like 'we manually applied a patch to resolve this', or 'we have configuration where this can't happen', or 'this is very unlikely to be an issue in the way Garden Linux is run'. |
||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] I can query individual packages within the Garden Linux APT repo for known CVEs, for package versions included in the available releases | ||
| - [ ] I can use released Garden Linux images as a pre-set and add packages to see what additional CVEs are added with the additional packages | ||
|
|
||
| # GLDEV-02 | ||
|
|
||
| As a developer of Garden Linux I want to add context information on CVE that might be fixed or not applicable to Garden Linux. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] I can add a text comment to any package version describing in what condition this security issue applies to Garden Linux | ||
| - [ ] I can add new package versions to account for rebuilt and manually patched packages in Garden Linux | ||
|
|
||
| # GLDEV-03 | ||
|
|
||
| As a developer of Garden Linux I want to generate parts of release notes for new patch and major versions of Garden Linux. | ||
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] GLVD can create markdown output that is suitable for adding it to Github releases page | ||
|
|
||
|
|
||
|
|
||
| # Notes from discussion | ||
|
|
||
| - Get List of vuln by package name and version | ||
| - Get List of vuln packages by distro | ||
| - Get List of vuln packages by image | ||
| - needs manifest files from images (package list with version), generated by builder | ||
| - Get List of vuln packages by ocm descriptor (maybe) | ||
| - Get List of vuln packages by CVE id | ||
| - Triage for GL vuln | ||
| - output ocm (potential issues, immutability, pull/poll, api, ?) | ||
| - outbut bdba (maybe) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the things that I yet not understood is, will this be for ALL Users that GL or just SAP based users?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have intentionally not made this distinction here because I think there is nothing SAP specific about this requirement. I think we can have a separate class of user stories for SAP internal users if we need to, but so far I have not found a case where the needs are so different. Please let me know if you have any.