chore: sync files with Jahia/.github [skip ci]

.github/ISSUE_TEMPLATE/epic.md

@@ -13,13 +13,6 @@ type: Epic
 **In order to** 
 
 ### Non-functional requirements
-- Security
-  - Identity management
-  - Authentication
-  - Authorization
-  - Session management
-  - Data validation
-  - Error handling
 - Performances
 - Migration
 - Documentation

.github/ISSUE_TEMPLATE/release.md

@@ -75,7 +75,7 @@ After Testing
 - [ ] The release changelog was prepared
 - [ ] In case of a major release, a **Breaking Changes** section is present in the Changelog
 - [ ] The artifact was released on Nexus
-- [ ] If the module is included in Jahia distribution, [jahia-pack-private](https://github.com/Jahia/jahia-pack-private/blob/master/core-modules/pom.xml) was updated with the released version
+- [ ] If the module is included in Jahia distribution, [jahia-pack-private](https://github.com/Jahia/jahia-pack-private/blob/main/core-modules/pom.xml) was updated with the released version
 - [ ] ⚠️ If the module has a dependency to a recent release of [graphql-dxm-provider](https://github.com/Jahia/graphql-core), [server-availability-manager](https://github.com/Jahia/server-availability-manager) or [personal-api-tokens](https://github.com/Jahia/personal-api-tokens), contact the Cloud team to require their approval before publication.
 - [ ] If applicable, corresponding academy pages were published
 - [ ] The module was published on the store

.github/ISSUE_TEMPLATE/security-checks.md

@@ -0,0 +1,102 @@
+---
+name: Security checks
+about: Create a security checklist
+title: ''
+type: Task
+projects: ["Jahia/22"]
+---
+
+> [!TIP]
+> **Focus:** Risks that might be introduced by this feature's code, data flows, and business logic.
+> **Expected time:** 30–60 minutes
+> **When:** At the best time decided by the team and in all cases before the release.
+>
+> **TL;DR:** Fill in the feature summary, go through each of the 6 STRIDE sections, check off items (or mark N/A), document outcomes, and create issues for anything High or Critical. If your feature has no new inputs, APIs, data access, or permission changes, document why and close.
+---
+### How to Use This Checklist
+1. Fill in the **Feature Summary** section below first.
+2. For each checkbox in the **Feature Scope** section: assess whether it applies to your feature.
+- If it applies → check the box and document your finding/mitigation in the "Outcome" section.
+- If it doesn't apply → check the box and write "N/A — [brief reason]".
+- If you're unsure → leave unchecked and flag for discussion with the team.
+3. Create issues for any finding rated **High** or above.
+4. This issue can be closed when all checkboxes are addressed, outcomes are documented, and issues are linked.
+> [!NOTE]
+> **Fast path:** If this feature introduces **no new inputs, no new data access, no new APIs, and no permission changes** (e.g., purely cosmetic/CSS), document why below and close this issue.
+---
+### ⚠️ Platform Baseline Gate
+> Does your feature modify any of the following? Authentication, session management, logging infrastructure, rate limiting, or platform access controls.
+> **If yes → escalate to architecture before proceeding.**
+These are established once and inherited by all stories. Assume they are in place unless your story explicitly modifies them:
+- Authentication infrastructure (credential attack protections, session/token lifecycle, MFA for admin).
+- Platform rate limiting, quotas, and DoS protections.
+- Log infrastructure (integrity, log access controls, retention, alerting).
+- Time synchronization and audit infrastructure.
+- Regular privileged role review and access governance processes.
+---
+### Feature Summary (fill before reviewing)
+- **What does this feature do (one sentence)?**
+- **What data does it read/write?**
+- **What external systems does it interact with?**
+- **Who can trigger it?** (anonymous / authenticated / admin)
+---
+### Feature Scope (STRIDE)
+Review the 6 risk areas below for threats your feature introduces or changes.
+#### 1. Spoofing Identity (Authentication)
+- [ ] Does this feature check user identity or delegated permissions before sensitive actions?
+- [ ] Are authorization checks enforced at object/record level? *(e.g., can user A access user B's content by changing an ID in the URL — IDOR/BOLA)*
+- [ ] Does this feature create service-to-service calls or machine identities? If yes, are they authenticated and authorized?
+- [ ] Is tenant/domain isolation maintained if applicable?
+> [!IMPORTANT]
+> **Outcome / Identified actions / Issues:**
+> - ...
+#### 2. Tampering with Data (Integrity)
+- [ ] What untrusted inputs does this feature accept (params, files, payloads, config)? Are they validated and sanitized?
+- [ ] What injection risks exist? *(e.g., does a search field get interpolated into a JCR/SQL query? Is user input rendered unescaped in JSP/React?)*
+- [ ] If this feature calls other services, are responses validated?
+- [ ] If files are handled, are type/content verified and stored safely (not just extension)?
+> [!IMPORTANT]
+> **Outcome / Identified actions / Issues:**
+> - ...
+#### 3. Repudiation (Auditing)
+- [ ] What security-relevant actions should be logged (auth failures, data changes, admin actions)?
+- [ ] Are logs correlated/traceable (who, what, when, from where)?
+- [ ] Can audit data be replayed or spoofed?
+> [!IMPORTANT]
+> **Outcome / Identified actions / Issues:**
+> - ...
+#### 4. Information Disclosure (Confidentiality)
+- [ ] What sensitive data does this feature handle (PII, tokens, keys, config)?
+- [ ] Is it minimized, classified, and access-restricted?
+- [ ] Is it protected in transit and at rest per policy?
+- [ ] Can it leak via errors, debug output, headers, caches, or logs?
+> [!IMPORTANT]
+> **Outcome / Identified actions / Issues:**
+> - ...
+#### 5. Denial of Service (Availability)
+- [ ] Does this feature call remote services? Are there timeouts and backoff?
+- [ ] Are there expensive operations (queries, file processing, regex, loops)? Can they be bounded or rate-limited?
+- [ ] Can this feature's endpoints or async workers be starved or overloaded? Design graceful degradation.
+> [!IMPORTANT]
+> **Outcome / Identified actions / Issues:**
+> - ...
+#### 6. Elevation of Privilege (Authorization)
+- [ ] Does this feature grant or check permissions? Are they least-privilege for the feature's scope?
+- [ ] Can business logic be bypassed through parameter, state, or workflow manipulation?
+- [ ] Are authorization checks consistent across UI, API, background jobs, and internal service calls?
+> [!IMPORTANT]
+> **Outcome / Identified actions / Issues:**
+> - ...
+---
+### Severity Guidance for Findings
+| Severity | Description | Action |
+|----------|-------------|--------|
+| **Critical** | Auth bypass, RCE, data leak at scale | Block release, fix immediately |
+| **High** | IDOR, stored XSS, privilege escalation | Create Issues, fix before release |
+| **Medium** | Missing rate-limit, verbose errors | Create Issues, plan for future fix |
+| **Low** | Minor info disclosure in headers | Backlog |
+---
+### Completion Checklist
+- [ ] All STRIDE sections reviewed (checked or marked N/A)
+- [ ] Issues created and linked for any High/Critical findings
+- [ ] Discussed with team if anything is High or Critical

.github/ISSUE_TEMPLATE/tech-day.md

@@ -34,20 +34,20 @@ When creating such tickets, try to provide details about complexity of such an i
 
 ## Checklist
 
-This checklist is there to help you but is not exaustive, if some items are not relevant or should be added, [please request a change](https://github.com/Jahia/.github/blob/master/.github/ISSUE_TEMPLATE/custom_product/tech-day.md).
+This checklist is there to help you but is not exaustive, if some items are not relevant or should be added, [please request a change](https://github.com/Jahia/.github/blob/main/.github/ISSUE_TEMPLATE/custom_product/tech-day.md).
 
 ### General
 - [ ] 🚨 I reviewed all OPEN tickets planned for an upcoming release (using codebase-X.Y.Z milestone)
 - [ ] 🚨 I reviewed older tech day tickets / ownership activities for that codebase
 - [ ] 🔝 I submitted updates to the [tech-day template](https://github.com/Jahia/.github/blob/maintain-list/.github/ISSUE_TEMPLATE/custom_product/tech-day.md) if I noticed incorrect elements
 - [ ] 🟠 Standards have been discussed in a tech kumite in the past semester
-- [ ] 🙏 Module's license is up-to-date (see https://github.com/Jahia/open-source/blob/master/README.md#licenses)
+- [ ] 🙏 Module's license is up-to-date (see https://github.com/Jahia/open-source/blob/main/README.md#licenses)
 ### Dependency management
 - [ ] 🔝 I've identified the process/tools to handle dependency updates (ex: [renovate](https://jahia-confluence.atlassian.net/wiki/spaces/PR/pages/2071358/3rd-party+libraries+-+Ref+ISPOL08.A14024#%5BinlineExtension%5DRenovate))
 - [ ] 🟠 Ensure licenses used by the libraries are [Jahia compliant](https://jahia-confluence.atlassian.net/wiki/spaces/PR/pages/2068350/License+check+-+Ref+ISSOP08.A14020)
 - [ ] 🙏 Remove unused libraries
 ### Jahia Modules
-- [ ] 🚨 If the codebase is a module shipped with the distribution, the latest version with changes is configured in jahia-pack ([core](https://github.com/Jahia/jahia-pack-private/blob/master/core-modules/pom.xml) or [additional-modules](https://github.com/Jahia/jahia-pack-private/blob/master/additional-modules/pom.xml))
+- [ ] 🚨 If the codebase is a module shipped with the distribution, the latest version with changes is configured in jahia-pack ([core](https://github.com/Jahia/jahia-pack-private/blob/main/core-modules/pom.xml) or [additional-modules](https://github.com/Jahia/jahia-pack-private/blob/main/additional-modules/pom.xml))
 - [ ] 🟠 Make sure dependencies (and appropriate version if needed) are declared in **jahia-depends**
 ### Static Analysis and code quality
 - [ ] 🚨 No Blocker issues on [Sonarqube](https://sonarqube.jahia.com/projects) for the module
@@ -57,7 +57,7 @@ This checklist is there to help you but is not exaustive, if some items are not
 - [ ] 🟠 I reviewed opportunities to remove dead/unused/unreachable code
 - [ ] 🙏 No Minor/Info issues on [Sonarqube](https://sonarqube.jahia.com/projects) for the module
 ### Javascript
-- [ ] 🔝 The module's webpack config is correct ([sample](https://github.com/Jahia/jcontent/blob/master/webpack.config.js))
+- [ ] 🔝 The module's webpack config is correct ([sample](https://github.com/Jahia/jcontent/blob/main/webpack.config.js))
 - [ ] 🔝 The module is using a supported LTS version of ([NodeJS](https://nodejs.org/en/about/previous-releases))
 - [ ] 🟠 The module is using React v18+
 - [ ] 🟠 The module is using Moonstone v2+
@@ -83,7 +83,7 @@ This checklist is there to help you but is not exaustive, if some items are not
 - [ ] 🔝 Automated tests are using jahia-cypress for all utils functions
 - [ ] 🔝 The test framework is using page-object models published by other modules
 - [ ] 🔝 The test framework is publishing its own page-object models for use by others
-- [ ] 🟠 A manual-run workflow is available (ex: [manual-run.yml](https://github.com/Jahia/jcontent/blob/master/.github/workflows/manual-run.yml))
+- [ ] 🟠 A manual-run workflow is available (ex: [manual-run.yml](https://github.com/Jahia/jcontent/blob/main/.github/workflows/manual-run.yml))
 - [ ] 🟠 Instructions and [test cases](https://jahia.testrail.net/index.php?/dashboard) are available to document how a release should be tested (how to do the "sanity check" of this module)
 - [ ] 🙏 Automated tests are using a recent version of Cypress
 - [ ] 🙏 Automated tests are only relying on supported modules

.github/workflows/chachalog-comment-pr.yml

@@ -6,7 +6,6 @@ on:
   pull_request_target:
     branches:
       - main
-      - master
 
 jobs:
   comment-pr:

.github/workflows/chachalog-prepare-changelog.yml

@@ -6,7 +6,6 @@ on:
   push:
     branches:
       - main
-      - master
   workflow_dispatch: null
 
 jobs: