Skip to content
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.

Sign up for GitHub

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

Jump to bottom

docs: Disabling Security Monitoring #202

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

docs: Disabling Security Monitoring #202

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5c68fa4
docs: Disabling Security Monitoring
cav72 Jun 11, 2024
145daea
docs: fix security monitoring typo
cav72 Jun 23, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions IMAGE_MAINTAINER_AGREEMENT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -171,6 +171,23 @@ and stating:
- **if** the Ubuntu Rock is based on other upstream source code, it **must** also include a security manifest. Currently, there is no convention for what this security manifest should look like. You **must** reach out to the Security team and discuss this on a case per case basis. As an example, the (now deprecated) [ubuntu/cortex](https://hub.docker.com/r/ubuntu/cortex) image [produces](https://git.launchpad.net/~ubuntu-docker-images/ubuntu-docker-images/+git/utils/tree/golang-manifest-builder.py) this custom security
[manifest](https://git.launchpad.net/~ubuntu-docker-images/ubuntu-docker-images/+git/cortex/tree/oci/Dockerfile.ubuntu?h=1.7-21.04#n58).

### Disable security monitoring

To disable security monitoring for an Ubuntu Rock, the Maintainer must:
- contact the Security Team (either directly, or via [email protected]) with the subject being "Disable security monitoring", and stating:
- the Ubuntu Rock name;
- the URL for the corresponding repository in Docker Hub;
- the contact information of the recipients who are getting current notifications;

To disable security monitoring for **specific tags** of an Ubuntu Rock, the Maintainer must:
- populate the table under the "Deprecated channels & tags" section in the rock description.

In this table, the values under `Track` are used as a filter. As an example, the (now deprecated) [ubuntu/cortex](https://hub.docker.com/r/ubuntu/cortex) includes a deprecated track of ~~`1.10-21.10`~~. Tags with this track in their name such as:
- `1.10-21.10_edge`
- `1.10-21.10_beta`

are omitted from security monitoring updates.

### Acknowledge the delay to address issues

The infrastructure provided by the ROCKS team will progressively become more autonomous when it comes to addressing the “need to update an Ubuntu Rock”. Nonetheless, and mainly in the event of a security patch (e.g. USN), the Maintainer **must** be able to address and update if needed, the affected Ubuntu Rocks in less than 24h. The build and publish process are designed to allow for a quick response delay to Maintainer-driven build requests (builds are triggered as soon as the build request is accepted). This very short timeline is designed to target a 24h average response time to critical CVEs from CVE fix available to the patched image availability.
Expand Down
Loading