From 48d1168146755face9f2fa1993349e6d63f7739e Mon Sep 17 00:00:00 2001 From: PHADAR Date: Tue, 29 Sep 2026 18:44:04 +0100 Subject: [PATCH 1/3] security: Add a security severity rubric for TeachLink Backend (#1617) --- Governance/CHANGELOG.md | 3 +- Governance/SECURITY_SEVERITY_RUBRIC.md | 98 ++++++++++++++++++++++++++ 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644 Governance/SECURITY_SEVERITY_RUBRIC.md diff --git a/Governance/CHANGELOG.md b/Governance/CHANGELOG.md index ec55a53d..a1a74331 100644 --- a/Governance/CHANGELOG.md +++ b/Governance/CHANGELOG.md @@ -10,6 +10,7 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). ### Added +- `Governance/SECURITY_SEVERITY_RUBRIC.md` — severity levels, criteria per level, and response SLA per level (issue #1617) - `Governance/policies/LICENSING.md` — project licensing framework, inbound-equals-outbound rule, and license change procedures - `Governance/policies/GOOD_FIRST_ISSUE.md` — criteria for the `good first issue` label, who may apply it, and mentorship expectations (issue #1610) - `Governance/processes/VULN_DISCLOSURE.md` — private reporting channels, triage steps, and coordinated-disclosure timeline (issue #1612) @@ -27,7 +28,7 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - `Governance/domains/DATA_RETENTION.md` — initial data-retention policy covering: - Retention periods for all data types (users, courses, payments, audit logs, notifications, analytics, messages, media, sessions, consent records, backups) - - Automated and manual deletion processes, including GDPR Article 17 right-to-erasure and CCPA §1798.105 right-to-delete flows + - Automated and manual deletion processes, including GD@R Article 17 right-to-erasure and CCPA §798.105 right-to-delete flows - Legal-hold exceptions: how to place, verify, lift, and handle emergency preservation - Compliance mapping to GDPR, CCPA, and SOX requirements - Roles and responsibilities diff --git a/Governance/SECURITY_SEVERITY_RUBRIC.md b/Governance/SECURITY_SEVERITY_RUBRIC.md new file mode 100644 index 00000000..ba65828d --- /dev/null +++ b/Governance/SECURITY_SEVERITY_RUBRIC.md @@ -0,0 +1,98 @@ +# Security Severity Rubric + +All security vulnerabilities reported against TeachLink Backend are assigned a severity level using the rubric below. This document is the authoritative, versioned reference for severity classification and response SLAs. It complements `Governance/SECURITY_POLICY.md`, `Governance/processes/VULN_DISCLOSURE.md`, and `Governance/policies/EMBARGO.md`. + +--- + +## 1. Severity Levels + +TeachLink uses four severity levels. Each level is defined by the impact of exploitation on confidentiality, integrity, and availability (CIA) of the TeachLink Backend and its users. + +| Level | Name | Definition | +|-------|------|------------| +| P0 | Critical | Exploitation is trivial or already occurring, and leads to widespread compromise of user data, funds, or service integrity. | +| P1 | High | Exploitation is realistic and leads to significant loss of confidentiality, integrity, or availability for a substantial set of users or a core service. | +| P2 | Medium | Exploitation requires specific conditions or privileges and leads to limited impact on confidentiality, integrity, or availability. | +| P3 | Low | Exploitation is difficult, requires significant preconditions, or results in minimal or no measurable impact. | + +--- + +## 2. Criteria per Level + +The following criteria are used to assign a severity level. At least one criterion from a level must be met to assign that level. When multiple levels apply, the highest applicable level is assigned. + +### P0 — Critical + +- Remote unauthenticated code execution on production infrastructure. +- Authentication bypass affecting all users or administrator accounts. +- Exposure of signing keys, secrets, or database credentials used in production. +- Mass extraction or corruption of user personal data, payment data, or course content. +- Payment or ledger manipulation resulting in financial loss or double-spending. +- Denial of service that fully disrupts the platform with no workaround. + +### P1 — High + +- Authenticated code execution or privilege escalation within a tenant or service. +- Authorization flaw allowing access to another user's data or administrative functions. +- SQLi or noSQL injection with measurable impact on data integrity or confidentiality. +- Stored cross-site scripting (XSS) or cross-site request forgery (CSRF) with session or account impact. +- Exposure of a limited set of credentials or personal data not intended for public consumption. +- Sustained denial of service against a core service with a partial workaround. + +### P2 — Medium + +- Exploitation requiring an authenticated account with non-default privileges. +- Information disclosure of low-sensitivity metadata or internal system details. +- Integrity issues that require a specific configuration or user interaction to trigger. +- Business logic flaws with limited financial or operational impact. +- Denial of service against a non-core service or with a workaround. +- Missing security headers or weak cryptographic parameters with a demonstrable but limited exploit path. + +### P3 — Low + +- Information disclosure with no security impact or only publicly available information. +- Theoretical issues requiring attacker control of the client, network, or server already compromised. +- Best-practice deviations with no demonstrable exploit path. +- Denial of service against a single non-critical endpoint with negligible user impact. +- Issues already mitigated by existing controls or defense-in-depth measures. + +--- + +## 3. Response SLA per Level + +SLAs are measured from the moment a report is received by the Security Response Team (see `Governance/SECURITY_RESPONSE_TEAM.md`). All times are in calendar hours and refer to acknowledgement, triage, and remediation targets. + +| Level | Acknowledgement | Triage | Mitigation | Permanent Fix | Public Disclosure | +|-------|---------------|-------|------------|---------------|------------------| +| P0 | <= 2 hours | <= 4 hours | <= 24 hours | <= 72 hours | <= 7 days | +| P1 | <= 8 hours | <= 24 hours | <= 72 hours | <= 14 days | <= 30 days | +| P2 | <= 2 business days | <= 5 business days | <= 14 days | <= 45 days | <= 90 days | +| P3 | <= 5 business days | <= 10 business days | Not required | Next regular release | <= 180 days | + +### SLA notes + +- Acknowledgement means the reporter receives a confirmation that the report was received and is being triaged. +- Triage means a severity level is assigned and the reporter is informed of the classification. +- Mitigation means a workaround, hotfix, or configuration change is deployed to reduce exploitability. +- Permanent fix means the root cause is remediated and verified in the main branch. +- Public disclosure is governed by `Governance/processes/COORDINATED_DISCLOSURE.md` and `Governance/policies/EMBARGO.md`. +- Slas may be extended by the Security Response Team when a fix requires dependency upgrades, external coordination, or upgrade windows. Extensions must be documented in the advisory or triage record. + +--- + +## 4. Assignment and Review + +- Severity is initially assigned by the Security Response Team during triage. +- Severity may be re-assigned as technical details emerge; the reporter is notified of any change. +- Any change to this rubric requires a governance review and a changelog entry in `Governance/CHANGELOG.md`. + +--- + +## 5. References + +- `Governance/SECURITY_POLICY.md` — supported versions and reporting channels. +- `Governance/SECURITY_RESPONSE_TEAM.md` — team membership and on-call rotation. +- `Governance/processes/VULN_DISCLOSURE.md` — private reporting and triage steps. +- `Governance/processes/COORDINATED_DISCLOSURE.md` — coordinated disclosure timing. +- `Governance/policies/EMBARGO.md` — default embargo durations by severity. +- `Governance/templates/ADVISORY_TEMPLATE.md` — security advisory format. From 8f4af0c9767997995c83af1cd1b5d57af4f07670 Mon Sep 17 00:00:00 2001 From: PHADAR Date: Tue, 29 Sep 2026 21:15:47 +0100 Subject: [PATCH 2/3] security: Add a security severity rubric for TeachLink Backend (#1617) --- Governance/CHANGELOG.md | 4 +- Governance/SECURITY_SEVERITY_RUBRIC.md | 140 ++++++++++++++----------- 2 files changed, 82 insertions(+), 62 deletions(-) diff --git a/Governance/CHANGELOG.md b/Governance/CHANGELOG.md index a1a74331..102a116a 100644 --- a/Governance/CHANGELOG.md +++ b/Governance/CHANGELOG.md @@ -10,7 +10,6 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). ### Added -- `Governance/SECURITY_SEVERITY_RUBRIC.md` — severity levels, criteria per level, and response SLA per level (issue #1617) - `Governance/policies/LICENSING.md` — project licensing framework, inbound-equals-outbound rule, and license change procedures - `Governance/policies/GOOD_FIRST_ISSUE.md` — criteria for the `good first issue` label, who may apply it, and mentorship expectations (issue #1610) - `Governance/processes/VULN_DISCLOSURE.md` — private reporting channels, triage steps, and coordinated-disclosure timeline (issue #1612) @@ -20,6 +19,7 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - `Governance/templates/ADVISORY_TEMPLATE.md` — security advisory sections including severity, CVSS, and remediation fields (issue #1615) - `Governance/policies/EMBARGO.md` — default embargo durations by severity, embargo list membership, and early-disclosure exceptions (issue #1613) - `Governance/policies/DCO.md` — Developer Certificate of Origin sign-off requirement, verification, and remediation (issue #1609) +- `Governance/SECURITY_SEVERITY_RUBRIC.md` — severity levels, per-level criteria, and response SLAs for security issues ## [1.0.0] – 2026-09-27 @@ -28,7 +28,7 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - `Governance/domains/DATA_RETENTION.md` — initial data-retention policy covering: - Retention periods for all data types (users, courses, payments, audit logs, notifications, analytics, messages, media, sessions, consent records, backups) - - Automated and manual deletion processes, including GD@R Article 17 right-to-erasure and CCPA §798.105 right-to-delete flows + - Automated and manual deletion processes, including GDPR Article 17 right-to-erasure and CCPA §1798.105 right-to-delete flows - Legal-hold exceptions: how to place, verify, lift, and handle emergency preservation - Compliance mapping to GDPR, CCPA, and SOX requirements - Roles and responsibilities diff --git a/Governance/SECURITY_SEVERITY_RUBRIC.md b/Governance/SECURITY_SEVERITY_RUBRIC.md index ba65828d..ec7caeb3 100644 --- a/Governance/SECURITY_SEVERITY_RUBRIC.md +++ b/Governance/SECURITY_SEVERITY_RUBRIC.md @@ -1,98 +1,118 @@ # Security Severity Rubric -All security vulnerabilities reported against TeachLink Backend are assigned a severity level using the rubric below. This document is the authoritative, versioned reference for severity classification and response SLAs. It complements `Governance/SECURITY_POLICY.md`, `Governance/processes/VULN_DISCLOSURE.md`, and `Governance/policies/EMBARGO.md`. +All security issues reported against TeachLink Backend are assigned a severity level using the rubric below. The rubric is the authoritative reference for triage, remediation prioritization, and disclosure timing. It is versioned and maintained by the Security Response Team (See `Governance/SECURITY_RESPONSE_TEAM.md`). + +This document is normative. Where it conflicts with any other governance document, this rubric takes precedence for severity classification and response SLAs. --- ## 1. Severity Levels -TeachLink uses four severity levels. Each level is defined by the impact of exploitation on confidentiality, integrity, and availability (CIA) of the TeachLink Backend and its users. +A severity level is assigned based on the combined impact of **exploitability** and **business/data impact**. When a finding spans multiple levels, the highest applicable level is assigned. -| Level | Name | Definition | -|-------|------|------------| -| P0 | Critical | Exploitation is trivial or already occurring, and leads to widespread compromise of user data, funds, or service integrity. | -| P1 | High | Exploitation is realistic and leads to significant loss of confidentiality, integrity, or availability for a substantial set of users or a core service. | -| P2 | Medium | Exploitation requires specific conditions or privileges and leads to limited impact on confidentiality, integrity, or availability. | -| P3 | Low | Exploitation is difficult, requires significant preconditions, or results in minimal or no measurable impact. | +| Level | Label | Description | +| --- | --- | --- | +| S0 | Critical | Exploitable with minimal effort, with direct impact on funds, identity, or system integrity at scale. | +| S1 | High | Exploitable with moderate effort or specific pre-texts, with serious impact on a subset of users or systems. | +| S2 | Medium | Exploitable with significant effort or uncommon conditions, with limited impact. | +| S3 | Low | Hard to exploit or impact is minimal; defense-in-depth or hardening only. | --- ## 2. Criteria per Level -The following criteria are used to assign a severity level. At least one criterion from a level must be met to assign that level. When multiple levels apply, the highest applicable level is assigned. +### S0 — Critical + +A finding is S0 if **any** of the following hold: + +- Remote code execution or command injection in a production path without authentication or with a low-privilege account. +- Authentication bypass or full account takeover (e.g., JWT signing key leak, session fixation, password reset token predictability). +- Direct access to or exfiltration of secrets, credentials, or private keys used in production. +- Integrity compromise of financial or payment flows (e.g., arbitrary transfer amounts, double-spend, prize manipulation). +- Sql injection or deserialization vector leading to database read/write or RCE. +- Breach of tenant isolation exposing other organizations' data at scale. -### P0 — Critical +### S1 — High -- Remote unauthenticated code execution on production infrastructure. -- Authentication bypass affecting all users or administrator accounts. -- Exposure of signing keys, secrets, or database credentials used in production. -- Mass extraction or corruption of user personal data, payment data, or course content. -- Payment or ledger manipulation resulting in financial loss or double-spending. -- Denial of service that fully disrupts the platform with no workaround. +A finding is S1 if **any** of the following hold and no S0 criteria are met: -### P1 — High +- Privilege escalation from a normal user to administrator or system role. +- Authenticated remote code execution or command injection. +- Stored CRSS or XSS in a privileged context (e.g., admin dashboard) affecting other users. +- Unauthorized read or write of another user's private data (PII, messages, course assignments) without an exploit chain. +- Bypass of authorization controls (IDBOR, forced browsing) on sensitive resources. +- Denial of service that fully takes down a production service with a single request or small burst. +- Supply-chain compromise of a build or deployment pipeline. -- Authenticated code execution or privilege escalation within a tenant or service. -- Authorization flaw allowing access to another user's data or administrative functions. -- SQLi or noSQL injection with measurable impact on data integrity or confidentiality. -- Stored cross-site scripting (XSS) or cross-site request forgery (CSRF) with session or account impact. -- Exposure of a limited set of credentials or personal data not intended for public consumption. -- Sustained denial of service against a core service with a partial workaround. +### S2 — Medium -### P2 — Medium +A finding is S2 if **any** of the following hold and no S0/S1 criteria are met: -- Exploitation requiring an authenticated account with non-default privileges. -- Information disclosure of low-sensitivity metadata or internal system details. -- Integrity issues that require a specific configuration or user interaction to trigger. -- Business logic flaws with limited financial or operational impact. -- Denial of service against a non-core service or with a workaround. -- Missing security headers or weak cryptographic parameters with a demonstrable but limited exploit path. +- Reflected CRSS/XSS in a non-privileged context requiring user interaction. +- Information disclosure of low-sensitivity metadata (e.g., username enumeration, email existence). +- Authenticated denial of service affecting a single tenant or service with moderate effort. +- Missing or weak cryptography for at-rest data with a realistic attack path. +- CSRF or state-changing GET on a sensitive endpoint without additional conditions. +- Logic flaws in business rules with limited financial impact (e.g., incorrect discount application). +- Partial bypass of rate limiting or abuse prevention controls. -### P3 — Low +### S3 — Low -- Information disclosure with no security impact or only publicly available information. -- Theoretical issues requiring attacker control of the client, network, or server already compromised. -- Best-practice deviations with no demonstrable exploit path. -- Denial of service against a single non-critical endpoint with negligible user impact. -- Issues already mitigated by existing controls or defense-in-depth measures. +A finding is S3 if **all** of the following hold: + +- Impact is limited to defense-in-depth hardening or informational findings. +- Exploitation requires privileged access, rare conditions, or significant user interaction. +- No direct confidentiality, integrity, or availability impact in production. +- Examples: missing security headers, verbose error messages without sensitive data, dependency vulnerability with no reachable path, debug endpoints not reachable in production. --- ## 3. Response SLA per Level -SLAs are measured from the moment a report is received by the Security Response Team (see `Governance/SECURITY_RESPONSE_TEAM.md`). All times are in calendar hours and refer to acknowledgement, triage, and remediation targets. +SLAs are measured from the time the report is received by the Security Response Team via a private channel defined in `Governance/SECURITY_POLICY.md`. All SLAs are calendar-time commitments. -| Level | Acknowledgement | Triage | Mitigation | Permanent Fix | Public Disclosure | -|-------|---------------|-------|------------|---------------|------------------| -| P0 | <= 2 hours | <= 4 hours | <= 24 hours | <= 72 hours | <= 7 days | -| P1 | <= 8 hours | <= 24 hours | <= 72 hours | <= 14 days | <= 30 days | -| P2 | <= 2 business days | <= 5 business days | <= 14 days | <= 45 days | <= 90 days | -| P3 | <= 5 business days | <= 10 business days | Not required | Next regular release | <= 180 days | +| Level | Acknowledge | Triage | Fix deployed | Public advisory | +| --- | --- | --- | --- | --- | +| S0 | 4 hours | 24 hours | 72 hours | 7 days after fix | +| S1 | 24 hours | 3 business days | 14 days | 30 days after fix | +| S2 | 3 business days | 7 business days | 45 days | 90 days after fix | +| S3 | 5 business days | 10 business days | Next release cycle | Not required | -### SLA notes +Notes: -- Acknowledgement means the reporter receives a confirmation that the report was received and is being triaged. -- Triage means a severity level is assigned and the reporter is informed of the classification. -- Mitigation means a workaround, hotfix, or configuration change is deployed to reduce exploitability. -- Permanent fix means the root cause is remediated and verified in the main branch. -- Public disclosure is governed by `Governance/processes/COORDINATED_DISCLOSURE.md` and `Governance/policies/EMBARGO.md`. -- Slas may be extended by the Security Response Team when a fix requires dependency upgrades, external coordination, or upgrade windows. Extensions must be documented in the advisory or triage record. +- **Acknowledge** means the reporter receives a response confirming receipt and a tracking identifier. +- **Triage** means a severity level is assigned and an initial impact assessment is shared with the reporter. +- **Fix deployed** means the remediation is merged and released to all affected supported versions. +- **Public advisory** is published per `Governance/processes/COORDINATED_DISCLOSURE.md`. +- Embargo durations follow `Governance/policies/EMBARGO.md` and are derived from the assigned severity level. +- Supported versions are defined in `Governance/SECURITY_POLICY.md`. --- -## 4. Assignment and Review +## 4. Severity Assignment Process + +1. The Security Response Team traiges the report and assigns a preliminary severity level using the criteria in Section 2. +2. The assigned level determines the SLA in Section 3 and the embargo duration in `Governance/policies/EMBARGO.md`. +3. Severity may be re-assigned if new information changes the impact or exploitability assessment. Re-assignment must be recorded in the internal tracking issue and communicated to the reporter. +4. If the reporter disagrees with the assigned severity, they may request a review by the Security Response Team lead. The lead's decision is final and documented. + +--- + +## 5. Versioning + +This rubric is versioned. Material changes to criteria or SLAs require a minor version bump and a changelog entry in `Governance/CHANGELOG.md`. Clarifications that do not change meaning may be made without a version bump but must still be recorded. -- Severity is initially assigned by the Security Response Team during triage. -- Severity may be re-assigned as technical details emerge; the reporter is notified of any change. -- Any change to this rubric requires a governance review and a changelog entry in `Governance/CHANGELOG.md`. +| Rubric version | Date | Change | +| --- | --- | --- | +| 1.0.0 | 2026-09-27 | Initial rubric: severity levels, criteria, and response SLAs. | --- -## 5. References +## 6. Related Documents -- `Governance/SECURITY_POLICY.md` — supported versions and reporting channels. -- `Governance/SECURITY_RESPONSE_TEAM.md` — team membership and on-call rotation. +- `Governance/SECURITY_POLICY.md` — supported versions and private reporting channels. +- `Governance/SECURITY_RESPONSE_TEAM.md` — triage ownership and on-call rotation. - `Governance/processes/VULN_DISCLOSURE.md` — private reporting and triage steps. -- `Governance/processes/COORDINATED_DISCLOSURE.md` — coordinated disclosure timing. -- `Governance/policies/EMBARGO.md` — default embargo durations by severity. -- `Governance/templates/ADVISORY_TEMPLATE.md` — security advisory format. +- `Governance/processes/COORDINATED_DISCLOSURE.md` — disclosure timing and credit. +- `Governance/policies/EMBARGO.md` — embargo durations by severity. +- `Governance/templates/ADVISORY_TEMPLATE.md` — advisory format including severity and CVSS. From da9815394f0a546936cf5fabd4da3b223230674e Mon Sep 17 00:00:00 2001 From: PHADAR Date: Tue, 29 Sep 2026 21:17:00 +0100 Subject: [PATCH 3/3] security: Add a security severity rubric for TeachLink Backend (#1617) --- Governance/CHANGELOG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Governance/CHANGELOG.md b/Governance/CHANGELOG.md index 102a116a..7aa09c20 100644 --- a/Governance/CHANGELOG.md +++ b/Governance/CHANGELOG.md @@ -19,7 +19,7 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - `Governance/templates/ADVISORY_TEMPLATE.md` — security advisory sections including severity, CVSS, and remediation fields (issue #1615) - `Governance/policies/EMBARGO.md` — default embargo durations by severity, embargo list membership, and early-disclosure exceptions (issue #1613) - `Governance/policies/DCO.md` — Developer Certificate of Origin sign-off requirement, verification, and remediation (issue #1609) -- `Governance/SECURITY_SEVERITY_RUBRIC.md` — severity levels, per-level criteria, and response SLAs for security issues +- `Governance/SECURITY_SEVERITY_RUBRIC.md` — severity levels, criteria per level, and response SLAs per level (issue #1617) ## [1.0.0] – 2026-09-27