Restructure code: split features into separate files

addons/addons.typ

@@ -0,0 +1,3 @@
+#import "cia.typ"
+#import "cvss.typ"
+#import "tlp.typ"

addons/cia.typ

@@ -0,0 +1,32 @@
+#let isUsed = state("isUsed", false)
+
+// Return the table cell formatted according to its content - for use with CIA values
+#let colorize(str) = {
+  if str == "H" {
+    table.cell(str, fill: red, align: center)
+  } else if str == "L" {
+    table.cell(str, fill: yellow, align: center)
+  } else if str == "N" {
+    table.cell(str, fill: lime, align: center)
+  } else {
+    panic("Unknown CIA state: " + str)
+  }
+  context(isUsed.update(true))
+}
+
+#let appendix() = {
+  [
+    == CIA Triad
+
+    The CIA triad is a fundamental framework for information security that encompasses three important principles: confidentiality, integrity, and availability. In this report, each of the three principles is used to highlight specific aspects of the security implications for the area under observation. All three principles are explained in more detail below.
+
+    === Confidentiality (C)
+    The principle of confidentiality means that information is only accessible to authorized users or entities. It protects sensitive data from unauthorized access or disclosure through measures such as encryption, access controls, and data classification. By maintaining confidentiality, companies reduce the risks of data breaches and unauthorized disclosure, thereby preserving the privacy and trustworthiness of their information assets.
+
+    === Integrity (I)
+    Integrity preserves the accuracy, consistency, and reliability of data. It prevents unauthorized changes, deletions, or falsifications through techniques such as checksums, digital signatures, and access controls. By maintaining data integrity, companies ensure the reliability and credibility of their information assets, thereby minimizing the risk of fraud or manipulation.
+
+    === Availability (A)
+    Availability ensures the smooth and reliable provision of information. Potential interruptions to services, systems, or networks are mitigated through redundancy, failover mechanisms, and disaster recovery planning. By maintaining high availability, companies maintain operational continuity and user satisfaction by mitigating the impact of downtime or failures. At the same time, the unavailability of information can have serious consequences, such as lost revenue.
+  ]
+}

addons/cvss.typ

@@ -0,0 +1,176 @@
+#import "../aux/valval.typ": panicOnInvalid
+#import "cia.typ"
+
+#let isUsed = state("isUsed", false)
+
+// Statistics, used e.g. for the management summary
+#let riskCategoryStats = (
+  Critical: state("riskCriticalStat", 0),
+  High: state("riskHighStat", 0),
+  Medium: state("riskMediumStat", 0),
+  Low: state("riskLowStat", 0),
+  None: state("riskInformativeStat", 0),
+  Other: state("riskOtherStat", 0)
+)
+
+// Function to update the statistics
+#let updateRiskCategoryStats(status) = {
+  // Update status
+  if status == "Critical" {
+    context(riskCategoryStats.Critical.update(v => v + 1))
+  } else if status == "High" {
+    context(riskCategoryStats.High.update(v => v + 1))
+  } else if status == "Medium" {
+    context(riskCategoryStats.Medium.update(v => v + 1))
+  } else if status == "Low" {
+    context(riskCategoryStats.Low.update(v => v + 1))
+  } else if status == "None" {
+    context(riskCategoryStats.None.update(v => v + 1))
+  } else if status == "Other" {
+    context(riskCategoryStats.Other.update(v => v + 1))
+  } else {
+    panic("Unknown state: " + status)
+  }
+}
+
+// Return the table cell formatted according to its content - for the CVSS result
+#let colorize(str) = {
+  if str == "Critical" {
+    table.cell(str, fill: red, align: center)
+  } else if str == "High" {
+    table.cell(str, fill: orange, align: center)
+  } else if str == "Medium" {
+    table.cell(str, fill: yellow, align: center)
+  } else if str == "Low" {
+    table.cell(str, fill: lime, align: center)
+  } else if str == "None" {
+    table.cell(str, fill: white, align: center)
+  } else {
+    panic("Unknown CVSS state: " + str)
+  }
+}
+
+// Create a small CIA table to be included for every finding
+#let createTable(attackVector: "N", attackComplexity: "L", privilegesRequired: "N", userInteraction: "N", scope: "U", confidentiality: "H", integrity: "H", availability: "H") = {
+  // Check values
+  panicOnInvalid(attackVector, ("N", "A", "L", "P"))
+  panicOnInvalid(attackComplexity, ("L", "H"))
+  panicOnInvalid(privilegesRequired, ("N", "L", "H"))
+  panicOnInvalid(userInteraction, ("N", "R"))
+  panicOnInvalid(scope, ("U", "C"))
+  panicOnInvalid(confidentiality, ("H", "L", "N"))
+  panicOnInvalid(integrity, ("H", "L", "N"))
+  panicOnInvalid(availability, ("H", "L", "N"))
+
+  // Calculate base result, see https://www.first.org/cvss/v3-1/specification-document#7-1-Base-Metrics-Equations
+  let issLookup = ("H": 0.56, "L": 0.22, "N": 0)
+  let attackVectorLookup = ("N": 0.85, "A": 0.62, "L": 0.55, "P": 0.2)
+  let attackComplexityLookup = ("L": 0.77, "H": 0.44)
+  let privilegesLookup = ("N": 0.85, "L": if scope == "U" { 0.62 } else { 0.68 }, "H": if scope == "U" { 0.27 } else { 0.5 })
+  let userInteractionLookup = ("N": 0.85, "R": 0.62)
+  let iss = 1 - ((1 - issLookup.at(confidentiality)) * (1 - issLookup.at(integrity)) * (1 - issLookup.at(availability)))
+  let impact = if scope == "U" { 6.42 * iss } else { 7.52 * (iss - 0.029) - 3.25 * (iss - 0.02)}
+  let exploitability = 8.22 * attackVectorLookup.at(attackVector) * attackComplexityLookup.at(attackComplexity) * privilegesLookup.at(privilegesRequired) * userInteractionLookup.at(userInteraction)
+  let baseScore = if impact <= 0 { 0 } else { if scope == "U" { calc.round(calc.min(impact + exploitability, 10), digits: 1) } else { calc.round(calc.min(1.08 * (impact + exploitability), 10), digits: 1) } }
+
+  let status = "?"
+  if baseScore >= 9.0 {
+    status = "Critical"
+  } else if baseScore >= 7.0 {
+    status = "High"
+  } else if baseScore >= 4.0 {
+    status = "Medium"
+  } else if baseScore >= 0.1 {
+    status = "Low"
+  } else {
+    status = "None"
+  }
+
+  block(
+    [
+      #block(
+        spacing: 0.4em,
+        table(
+          columns: (1fr, 1fr, 1fr, 1fr, 1fr, 1fr, 1fr, 1fr, 1fr),
+          align: center,
+          stroke: 1pt,
+          table.cell(colspan: 5)[*Exploitability Metrics*],
+          table.cell(colspan: 3)[*Impact Metrics*],
+          table.cell(rowspan: 2, align: bottom)[*#sym.sum*],
+          [*AV*], [*AC*], [*PR*], [*UI*], [*S*], [*C*], [*I*], [*A*],
+          attackVector, attackComplexity, privilegesRequired, userInteraction, scope, cia.colorize(confidentiality), cia.colorize(integrity), cia.colorize(availability), colorize(status),
+        )
+      )
+      #align(right)[
+        #text(
+        size: 10pt,
+        fill: gray,
+        "CVSS:3.1/AV:" + attackVector +
+        "/AC:" + attackComplexity +
+        "/PR:" + privilegesRequired +
+        "/UI:" + userInteraction +
+        "/S:" + scope +
+        "/C:" + confidentiality +
+        "/I:" + integrity +
+        "/A:" + availability
+      )]
+    ]
+  )
+
+  updateRiskCategoryStats(status)
+  isUsed.update(true)
+}
+
+#let appendix() = {
+  [
+    == Common Vulnerability Scoring System (CVSS)
+
+    The Common Vulnerability Scoring System (CVSS) provides a standardized, vendor- and platform-agnostic methodology for quantifying the technical severity of software, hardware, and firmware vulnerabilities. Its outputs deliver numerical scores that contextualize a vulnerability’s risk relative to others, facilitating consistent prioritization across diverse systems. CVSS is structured around three interdependent metric groups: *Base*, *Temporal*, and *Environmental*. The Base Score captures the inherent characteristics of a vulnerability (e.g., exploitability, impact), assigning it a severity rating under idealized conditions. Temporal Metrics dynamically adjust this base score based on time-sensitive factors like exploit availability or the existence of patches. Finally, Environmental Metrics tailor the severity assessment to an organization’s specific deployment, accounting for mitigations, criticality of affected assets, and other contextual factors unique to the environment.
+
+    The only metric group that can be calculated without deep knowledge of the environment and situation is the Base Score, as the Base Score reflects intrinsic vulnerability characteristics (e.g., exploit complexity, impact on confidentiality/integrity) and is designed to be vendor-neutral and environment-agnostic. It does not account for the specific client’s infrastructure, patch status, or operational context. Since a penetration test reports on a single target environment, the Base Score represents the objective severity of the flaw within the scope of the test (e.g., "this flaw could be exploited in this network").
+
+    The version of the Common Vulnerability Scoring System used in this report is 3.1#footnote("https://www.first.org/cvss/v3-1/user-guide").
+
+    === Attack Vector (AV)
+
+    This metric quantifies how remotely an attacker can exploit a vulnerability, directly influencing the Base Score:
+
+    - *Network (N)*: Highest severity. Attack possible from anywhere on the internet (e.g., sending a malicious packet across routers).
+    - *Adjacent (A)*: Moderate severity. Exploit limited to local networks (e.g., same subnet, Bluetooth/Wi-Fi, or secure VPN).
+    - *Local (L)*: Lower severity. Requires local access (console/SSH) or user interaction (e.g., phishing a document).
+    - *Physical (P)*: Lowest severity. Requires direct physical contact (e.g., evil-maid attacks, cold boot, DMA via USB).
+
+    === Attack Complexity (AC)
+
+    This metric quantifies the technical difficulty of exploiting a vulnerability, independent of user interaction. It directly impacts the Base Score:
+
+    - *Low (L)*: Attack is repeatable and predictable with no special conditions. Example: Exploiting a buffer overflow in a service accessible via network.
+    - *High (H)*: Exploit requires attacker preparation or external factors, reducing reliability. This may include:
+      - Gathering target-specific knowledge (e.g., configuration settings, shared secrets).
+      - Overcoming mitigations (e.g., race conditions, anti-exploit techniques).
+      - Network manipulation (e.g., man-in-the-middle attacks).
+      - Example: Exploiting a flaw requiring a victim’s browser to accept a malicious file.
+
+    === Privileges Required (PR)
+
+    This metric measures the attacker’s initial access level needed to exploit a vulnerability, directly impacting the Base Score:
+
+    - *None (N)*: Highest severity. Exploitable by unauthorized attackers with no prior access (e.g., unauthenticated web attack).
+    - *Low (L)*: Moderate severity. Requires basic user privileges (e.g., standard account access to non-sensitive resources).
+    - *High (H)*: Lowest severity. Needs administrative privileges to access critical system settings/files (e.g., root/superuser access).
+
+    === User Interaction (UI)
+
+    This metric assesses whether a vulnerability requires human involvement (beyond the attacker) to be exploited, directly influencing the Base Score:
+
+    - *None (N)*: Highest severity. Exploitable without user action (e.g., automated network attack).
+    - *Required (R)*: Lower severity. Requires user interaction (e.g., clicking a malicious link or installing software).
+
+    === Scope (S)
+
+    This metric determines if a vulnerability breaches security boundaries, allowing impact on components outside its original security scope (e.g., an app exploiting a database). Directly impacts Base Score severity:
+
+    - *Unchanged (U)*: Lowest severity. Vulnerability only affects resources within the same security authority (e.g., a web app affecting its own files).
+    - *Changed (C)*: Highest severity. Vulnerability crosses security boundaries, impacting components under different authorities (e.g., a compromised web server accessing a database).
+  ]
+}

addons/tlp.typ

@@ -0,0 +1,101 @@
+#import "../aux/valval.typ": panicOnInvalid
+
+#let isUsed = state("isUsed", false)
+
+// maps TLP status, color, title, and subtitle
+#let tlpLightMap = (
+  "RED": (color: rgb("#FF2B2B"), title: "TLP:RED", content: "recipient only"),
+  "AMBER": (color: rgb("#FFC000"), title: "TLP:AMBER", content: "organisation\nand its clients"),
+  "AMBER+STRICT": (color: rgb("#FFC000"), title: "TLP:AMBER+STRICT", content: "organisation only"),
+  "GREEN": (color: rgb("#33FF00"), title: "TLP:GREEN", content: "within community"),
+  "CLEAR": (color: rgb("#FFFFFF"), title: "TLP:CLEAR", content: "public")
+)
+
+// label draws an inline TLP label with appropiate color and black background
+// light may be one of "RED", "AMBER", "AMBER+STRICT", "GREEN", or "CLEAR"
+#let label(light) = {
+  light = upper(light)
+  // check argument
+  panicOnInvalid(light, tlpLightMap.keys())
+
+  highlight(
+    fill: black,
+    text(
+      weight: "semibold",
+      fill: tlpLightMap.at(light).color,
+      tlpLightMap.at(light).title
+    )
+  )
+}
+
+// mark draws a Traffic Light Protocol mark, used on the cover page
+// light may be one of "RED", "AMBER", "AMBER+STRICT", "GREEN", or "CLEAR"
+#let mark(light) = {
+  light = upper(light)
+  // check argument
+  panicOnInvalid(light, tlpLightMap.keys())
+
+  rect(
+    height: 100%,
+    width: 100%,
+    stroke: (paint: tlpLightMap.at(light).color.darken(10%), thickness: 2pt, dash: "solid"),
+    align(center + horizon,
+      grid(
+        columns: (80%),
+        rows: (18pt, auto),
+        gutter: 8pt,
+        [
+          #set text(size: if light == "AMBER+STRICT" { 13pt } else { 18pt })
+          #label(light)
+        ],
+        text(
+          size: 12pt,
+          fill: if light == "CLEAR" { black } else { tlpLightMap.at(light).color.darken(10%) },
+          tlpLightMap.at(light).content
+        )
+      )
+    )
+  )
+
+  isUsed.update(true)
+}
+
+// appendix explains the different values (RED, AMBER, ...) of the Traffic Light protocol, to be included in the appendix of a report
+#let appendix() = {
+  [
+    == Traffic Light Protocol
+
+    The Traffic Light Protocol (TLP) is a standardised system designed to accelerate collaborative response to security incidents by clarifying sharing boundaries for sensitive information. Information flows from an information source (e.g., a pentesting team) to recipients (e.g., clients or partners), with TLP labels governing permissible dissemination. The TLP labels standardised by FIRST#footnote("https://www.first.org/tlp/") are *RED*, *AMBER* and *AMBER+STRICT*, *GREEN*, and *CLEAR*.
+
+    === TLP Label #label("RED")
+
+    TLP:RED means _for the eyes of individual recipients only._
+    The purpose is to protect highly sensitive information where unauthorized disclosure risks privacy, reputation, or operations.
+    Sharing is strictly prohibited outside the recipient - even within the recipients organisation.
+
+    For example: an unauthenticated RCE vulnerability in a payment gateway API is classified TLP:RED. Sharing this internally (e.g., within a client’s incident response team or development team) is allowed; sharing anywhere else violates the classification.
+
+    === TLP Label #label("AMBER") and #label("AMBER+STRICT")
+
+    TLP:AMBER limits sharing to the recipient’s organization and its clients on a need-to-know basis. TLP:AMBER+STRICT restricts this further to the organisation, excluding clients.
+    The purpose is to allow collaboration with controlled exposure. Recipients may share with their own organization (and clients or partners if not using AMBER+STRICT), but must not share publicly or with non-authorized third parties.
+
+    For example: a session fixation flaw in a client’s SaaS platform is TLP:AMBER. Their security team may share with their provider for patching, but cannot share it with unaffiliated parties.
+
+    === TLP Label #label("GREEN")
+
+    TLP:GREEN means _Restricted to the recipient’s community; not public._
+    The purpose is to share awareness within a trusted community without public risk.
+    This allows recipients to share it with peers and partners within their defined community.
+
+    For example: a misconfigured AWS S3 bucket exposing anonymized test data is TLP:GREEN. The testing team may share this within the cybersecurity community (e.g., via ISACs or industry forums) to improve collective awareness, but cannot publish it on the internet.
+
+    === TLP Label #label("CLEAR")
+
+    TLP:CLEAR means _No restrictions on disclosure._
+    The purpose is to publicly share low-risk findings with no foreseeable misuse or patched vulnerabilities for transparency.
+    While sharing is unrestricted, the information may still be subject e.g. to copyright rules like attribution.
+
+    For example: a server running an outdated but non-vulnerable SSL/TLS library qualifies as TLP:CLEAR. The testing team may publish this in a blog post to demonstrate tooling for automatic detection and general security practice.
+  ]
+}