ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Tweak security incident handling checklists

Browse Source 
Add an item to the CVE issue template which calls for drafting the
security advisory early in the security incident handling process.  The
intention is to ensure there is enough time to review and polish ISC
security advisories before they get published.

Tweak the release checklist to make sure we carefully consider all
confidential issues before opening them up to the public.  This change
is intended as a safeguard against accidentally disclosing too much
information about a security vulnerability before our users get a chance
to patch it.
This commit is contained in:
Michał Kępień
2021-05-17 14:07:27 +02:00
parent f2b297a37d
commit ba1145c017
2 changed files with 4 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.gitlab/issue_templates/CVE.md
View File

@@ -13,6 +13,7 @@ email to [security-officer@isc.org](security-officer@isc.org).
- [ ] Determine CVSS score
- [ ] Determine the range of BIND versions affected (including the Subscription Edition)
- [ ] Determine whether workarounds for the problem exists
- [ ] Create a draft of the security advisory and put the information above in there
- [ ] Prepare a detailed description of the problem which should include the following by default:
- instructions for reproducing the problem (a system test is good enough)
- explanation of code flow which triggers the problem (a system test is *not* good enough)

4
.gitlab/issue_templates/Release.md
View File

@@ -85,7 +85,9 @@
- [ ] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [ ] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [ ] ***(QA)*** Prepare empty release notes for the next set of releases.
- [ ] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [ ] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [ ] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [ ] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.