Add Gitlab template for security issues

.gitlab/issue_templates/Security_issue.md

@@ -0,0 +1,110 @@
+### Summary
+
+<!-- Concisely summarize the bug encountered,
+preferably in one paragraph or less. -->
+
+### BIND versions affected
+
+<!--
+Make sure you are testing with the **latest** supported version of BIND.
+See https://kb.isc.org/docs/supported-platforms for the current list.
+The latest source is available from https://www.isc.org/download/#BIND
+
+Paste the output of `named -V` here.
+-->
+
+### Preconditions and assumptions
+
+<!--
+Is a specific setup needed?
+
+Please check the BIND Security Assumptions chapter in the ARM:
+https://bind9.readthedocs.io/en/latest/chapter7.html#security-assumptions
+
+E.g. DNSSEC validation must be disabled, etc.
+E.g. Resolver must be configured to forward to attacker's server via DNS-over-TLS, etc.
+E.g. Authoritative server must be configured to transfer specific primary zone.
+E.g. Attacker must be in posession of a key authorized to modify at least one zone.
+E.g. Attacker can affect system clock on the server running BIND.
+-->
+
+### Attacker's abilities
+
+<!--
+What resources does an attacker need to have under their control to mount this attack?
+
+E.g. If attacking an authoritative server, does the attacked have to have prior
+relationship with it? "The authoritative server under attack needs to
+transfer a malicious zone from attacker's authoritative server via TLS."
+
+E.g. If attacking a resolver, does the attacker need the ability to send
+arbitrary queries to the resolver under attack? Do they need to _also_ control
+an authoritative server at the same time?
+-->
+
+
+### Impact
+<!--
+Who or what is the victim of the attack and what is the impact?
+
+Is a third party receiving many packets generated by a reflection attack?
+
+If the affected party is the BIND server itself, please quantify the impact
+on legitimate clients:
+E.g. After launching the attack, the answers-per-second metric for legitimate
+traffic drops to 1/1000 within the first minute of the attack.
+-->
+
+
+### Steps to reproduce
+
+<!--
+This is extremely important! Be precise and use itemized lists, please.
+
+Even if a default configuration is affected, please include the full configuration
+files _you were testing with_.
+
+Example:
+1. Use the _attached_ configuration file
+2. Start the BIND server with command: `named -g -c named.conf ...`
+3. Simulate legitimate clients using the command `dnsperf -S1 -d legit-queries ...`
+4. Simulate attack traffic using the command `dnsperf -S1 -d attack-queries ...`
+-->
+
+1.
+2.
+3.
+
+### What is the current *bug* behavior?
+
+<!--
+Examples:
+Legitimate QPS drops 1000x.
+Memory consumption increases out of bounds and the server crashes.
+The server crashes immediately.
+-->
+
+### What is the expected *correct* behavior?
+
+<!--
+If the attack causes resource exhaustion, what do you think the correct behavior should be? Should BIND refuse to process more requests?
+What heuristic do you propose to distinguish legitimate and attack traffic?
+-->
+
+### Relevant logs
+
+<!--
+Please provide log files from your testing. Include full named logs and also
+the output from any testing tools (e.g. dnsperf, DNS Shotgun, kxdpgun, etc.)
+
+If multiple log files are needed, make sure all the files have matching timestamps
+so we can correlate log events across log files.
+
+In the case of resource exhaustion attacks, please _also_ include system monitoring
+data. You can use https://gitlab.isc.org/isc-projects/resource-monitor/ to
+gather system-wide statistics.
+-->
+
+<!-- DO NOT modify the following two lines. -->
+/label ~Bug ~Security
+/confidential