toolshed/docs.coopcloud.tech
3
3
Fork 32
Code Issues 12 Pull Requests 7 Packages Releases Activity

added resolution for security advisories

Browse Source
This commit is contained in:
hex
2026-10-27 16:38:56 +01:00
parent 2151d22737
commit bd6e901cb8
1 changed files with 225 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/federation/resolutions/draft/049.md
+225
View File
@@ -0,0 +1,225 @@
## Resolution 047: Security Event Management - 2026-09-14
- Deadline: Date
- Size: Medium
### Summary
Create a federation wide Security Event Management process to address the following concerns:
- end users and security researchers need a mechanism to report security vulnerabilities in Co-op Cloud maintained recipes
- operators need to know if the version they are deploying or have deployed is vulnerable, or if there are security related actions they need to take
- maintainers needed to know if a recipe they maintain needs a(n emergency) security update
### Details
#### Background
We have created a Co-op Cloud Security room on Matrix to coordinate on security improvements, and have discussed security concerns during kite flying on [2026-08-27](https://docs.coopcloud.tech/federation/kite-flying-pad-archive/#2026-08-27-12-utc), [2026-08-06-19](https://docs.coopcloud.tech/federation/kite-flying-pad-archive/#2026-08-06-19-utc), and [2026-07-30](https://docs.coopcloud.tech/federation/kite-flying-pad-archive/#2026-07-30-12-utc) (the later related to maturity models). We have also worked on at least one [document](https://cloud.klasse-methode.it/s/aNitMQjeo5QpHs4?dir=/&editing=false&openfile=true) outlining the security domains we are working within and to help focus on the most critical areas.
Over the course of the past month, we have identified the most critical gaps as described by the following user stories.
#### User Stories
- US1: As a Security Researcher, I have found a vulnerability in a Co-op Cloud recipe. I would like to responsibly disclose this vulnerability to a Co-op Cloud Security Contact so that users can be protected.
- US2: As an operator, I would like to be actively informed as soon as possible when an exploitable vulnerability is detected in a recipe I am using so that I can keep my end users safe.
- US3: As an operator, I would like to be able to find out if any recipes I'm currently using have known vulnerabilities so that I can upgrade them in order to keep my customers safe.
- US4: As a maintainer, I would like to be informed of vulnerabilities in recipes I maintain so that I can update recipe definitions and tell consumers to upgrade.
- US5: As an operator or maintainer, I would like to be able to run my own vulnerability scans to identify new vulnerabilities so that I can keep ahead of security team latency. Vulnerability scanners tend to produce a lot of noise, so I'd like to be able to leverage security team pre-filtering for all *known* issues so that I can focus on only *net new* issues.
#### Co-op Cloud Security Advisories (CCSA) feed
Security advisories are the foundation of any project's security program. They allow a project to announce security events, including, but not limited to, vulnerabilities that require upgrades, security incidents such as compromised hosts, and security program changes.
The primary function of an advisory is to fulfill US2 by announcing vulnerabilities as soon as there are actions that an end user can take to mitigate the issue.
Feeds generally come in the form of an email list. Often the email list is replicated to an RSS for easier tracking.
Within the Co-op Cloud recipe set, there are currently known issues with recipes. Unfortunately the current way to alert users is to post in the general channel. This is easy to miss and is not easily searchable.
The creation of a CCSA email list and RSS feed allows operators to quickly learn about issues, as information becomes available, without needing to filter through other chatter. With an RSS feed, additional automation (such as a Matrix bot) becomes significantly easier.
#### Co-op Cloud Security Advisories (CCSA) catalog and Abra Integration
While email/RSS can fulfill US2, a catalog can help fulfill UC3. CCSA can be written using a simple format such as yaml, toml, or json (so they can be searched based on recipe, CVE, or other metadata), and output to email, RSS, and a json vulnerability catalog. Such a catalog can be easily searched using automated tooling, can be rendered into a searchable page, or can be integrated into the abra deployment tool.
One specific request that multiple operators have repeated is for some kind of "abra vulnerability check." This is a sequence diagram for populating feeds and catalogs:
```
,--. ,---------. ,-----. ,-------. ,----.
|SE| |CCSA tool| |email| |catalog| |feed|
`-+' `----+----' `--+--' `---+---' `--+-'
| security advisory tml | | | |
|- - - - - - - - - - - ->| | | |
| | | | |
| | send from ccsa@security.coopcloud.tech | | |
| |---------------------------------------->| | |
| | | | |
| | build security.coopcloud.tech/ccsa.json | |
| |------------------------------------------------->| |
| | | | |
| | publish to security.coopcloud.tech/rss.xml| |
| |---------------------------------------------------------->|
| | | | |
,-+. ,----+----. ,--+--. ,---+---. ,--+-.
|SE| |CCSA tool| |email| |catalog| |feed|
`--' `---------' `-----' `-------' `----'
```
Once in a catalog, a user could run abra to test their own servers:
```
,----. ,----. ,----------. ,---------.
|user| |abra| |swarm host| |ccsa.json|
`--+-' `--+-' `-----+----' `----+----'
| abra sec_check | | |
|- - - - - - - - - - - - ->| | |
| | | |
| | get recipes | |
| |- - - - - - - - - - - - - - >| |
| | | |
| | deployed recipe/image list | |
| |< - - - - - - - - - - - - - -| |
| | | |
| | download if not cached |
| |- - - - - - - - - - - - - - -|- - - - - >|
| | | |
| | check against recipes |
| |- - - - - - - - - - - - - - -|- - - - - >|
| | | |
| | vulnerable matches| |
| |< - - - - - - - - - - - - - -|- - - - - -|
| | | |
| list of vulnerable apps | | |
|< - - - - - - - - - - - - | | |
| | | |
,--+-. ,--+-. ,-----+----. ,----+----.
|user| |abra| |swarm host| |ccsa.json|
`----' `----' `----------' `---------'
```
CCSA can provide a mechanism to alert users about issues outside of just CVEs. Supply chain attacks could poison docker images, requiring upgrades or downgrades for images downloaded during certain times. Compromise of member accounts could result in malicious code in abra or other tools. A CCSA can provide a key outlet for incident response actions that require public reporting.
##### Abra Mockups
Check one host, find vulnerabilities:
```
$ abra ccsa_check example.coopcloud.tech
Downloading latest Co-op Cloud Security Advisories
|================================================| 100%
Checking........ complete!
[thisapp.example.coopcloud.tech]
CRITICAL: RCE in ThisApp 1.2.3+3.4.5 -> ThisApp 1.2.4+3.4.6
CVE-4321-12345, CVE-2033-12346, CVE-2033-12347
https://security.coopcloud.tech/CCSA-20260914-2.html
[thatapp.example.coopcloud.tech]
WARNING: Denial of Service ThatApp 3.2+2.2.3
CVE-4321-12111
https://security.coopcloud.tech/CCSA-20260914-6.html
```
Check for vulnerabilities across all managed hosts:
```
$ abra server ls -m
[{"host":"foo.coopcloud.tech","name":"foo"},
{"host":"bar.coopcloud.tech","name":"bar"}]
$ abra ccsa_check example.coopcloud.tech --all
Using cached Co-op Cloud Security Advisories
Checking...
foo
bar
...complete!
[thisapp.foo.coopcloud.tech]
CRITICAL: RCE in ThisApp 1.2.3+3.4.5 -> ThisApp 1.2.4+3.4.6
CVE-4321-12345, CVE-2033-12346, CVE-2033-12347
https://security.coopcloud.tech/CCSA-20260914-2.html
[thatapp.foo.coopcloud.tech]
WARNING: Dangerous configuration in OtherApp 332.1+1.2.3
Read advisory to make sure this deployment isn't vulnerable
https://security.coopcloud.tech/CCSA-20260914-6.html
[bar.coopcloud.tech]
No vulnerabilities detected!
```
#### Maintainer
In order to be able to provide updates to fulfill UC2 and UC3, we first need to have actionable information. It isn't enough to tell an operator that an application has a vulnerability if they can't do anything about it. Unactionable information manifests apathy. We must have a clear path from vulnerable to (more) secure.In most cases, this will require working with a recipe maintainer to upgrade a recipe to a version that isn't vulnerable.
Unfortunately, there is no automated mechanism to identify a recipe maintainer point of contact. There are few acceptable options for this:
1. Include a maintainer contact (email or matrix id) in the recipe.
2. Include a link to a maintainer support matrix channel.
3. Create a matrix channel in the coop cloud space for maintainers.
4. create a mailing list for maintainers.
Option 1 is optimal since it provides the highest level of ownership and accountability. Option 2 makes a support rotation easier and more accessible, but has no clear and specific point of contact. Option 3 is not optimal since it would be a bit noisy. Option 4 would also make a support rotation easier (as option 2) but would make it harder to find a specific person during a security event.
#### Reporting Contact
Today we are able to identify new security issues. Once a new vulnerability is identified within a recipe, someone needs to triage the vulnerability. This includes reading the description, understanding how it does or does not impact the specific image and associated network as deployed via the recipe, and determining the level of additional actions.
For important vulnerabilities, maintainers need to be alerted. Someone needs to coordinate with those maintainers to make sure there's a safe upgrade path. Someone needs to write up a security advisory ([demo](https://0x29a.codeberg.page/CCSA-DEMO/), publish that advisory, and, optimally, answer questions related to the advisory.
This is part of the work of a Security Analyst in the field of Vulnerability Management. This needs to be staffed in accordance with our event response time. This doesn't need to be a task that takes up all someone's time, but there do need to be contacts in various time zones to be able to respond in case something comes up.
#### VEX
Triage work can be recorded using the Vulnerability Exploitability eXchange format (VEX). By also publishing this information as we review findings, we can coordinate with operators who may wish to run their own scans, or who are doing internal security work. We may also want to consume VEX from operators or other analysis teams. Hestia does not currently support VEX ingestion, but Trivy does. Code and infrastructure adjustments to hestia could allow authorized users to coordinate on vulnerability management.
#### Recommendations
1. Create a "Security@" email mailing list to which coop members and authorized security engineers can subscribe.
2. Repurpose the existing "Security" room for public (operator, maintainer, and external) facing security support.
1. Create a "Security Team" room in the "Co-op Cloud" matrix space specifically for people working on security problems (triaging, security engineering, etc).
2. Allocate infrastructure (two swarm hosts, one subdomain) for security team related work and testing.
3. Create a "scanner" bot ([PoC here](https://codeberg.org/0x29a/hestia)) to find new vulnerabilities for triage. Run this daily, increase to hourly if needed.
4. Create a matrix bot for the "Security Team" room to alert on new vulnerabilities.
6. Create a "Recipe Maintainer" room specifically for identifying maintainers to coordinate with.
7. Create a "support" object for each recipe entry in "recipes.json"
a. Add a (mandatory) "maintainer" field to this support object to identify a maintainer contact (could be a mailing list maintainers are on).
b. Add an (optional) SLA field to the "support" field that lists the maintainer response time.
c. Decrease the "status" to "basic" for all recipes that lack the support object.
d. Decrease the "status" to "ok" for all recipes that lack an SLA or for which the SLA has been missed in the last month.
9. Create a security.coopcloud.tech subdomain for security related information
b. link from docs.coopcloud.tech to security.coopcloud.tech
a. list security contact information here
#### Resource Requirements
##### Tasks
1. Writing specification, workflow documentation, and Security.coopcloud.tech content generation, security stakeholder feedback
36 hours of work
2. Security.coopcloud.tech web design
8 hours of work
3. Testing and stability improvements for Hestia
16 hours of work
4. Hestia operationalization (make a recipe, deploying to a host, setting up regular running, adding monitoring, code modifications as needed)
36 hours of work
5. Operationalization of CCSATool output into Security.coopcloud.tech
8 hours of work
6. Code changes to abra (adding abra ccsa-check )
40 hours of work
7. Maintenance (patching and other OS maintenance for the year)
12 months x 2 hours per month = 24 hours of work
Non-labor expense estimate
- Hosting for 1 year (1984.is: VPS #3 - 4gb ram, 2cpu, 80gb disk, 4tb tx/rx).
12 months x 34.88/mo = €418.56
1. security.coopcloud.tech domain connected to a bucket and a build (same as docs.*). This is trivial.
2. s3 compatible storage for ~20 gb of SBOMs
3. Triaging, process refinement, and security fixes. This is something we're doing anyway, but it would be nice to have people compensated for the work (if possible).
#### Follow up
1. Consider compensating maintainers of recipes with low SLAs and high scores
2. Determine how to staff Triage team
3. Apply for funding from nlnet to staff the security team for the first year.
4. Create generic incident response plans for different incident types
5. Identify an appropriate security contact method
6. Determine if we should use OCI VEX attestation against a Co-op Cloud docker mirror, or put VEX docs in a repos.