(logging-log4net) 01/01: extract SECURITY.md and add a remediation time frame policy

[fr...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

FreeAndNil pushed a commit to branch Feature/SECURITY.md
in repository https://gitbox.apache.org/repos/asf/logging-log4net.git

commit 2455c8c35edfc68ba135866b99ba3f41600809dd
Author: Jan Friedrich <fr...@apache.org>
AuthorDate: Tue May 19 22:03:59 2026 +0200

    extract SECURITY.md and add a remediation time frame policy
---
 AGENTS.md   |  32 ++++++++++++
 SECURITY.md | 169 +++++++++++++++++++++++++++++++++++++++++++++++-------------
 2 files changed, 164 insertions(+), 37 deletions(-)

diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 00000000..8e4b3407
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,32 @@
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+# Vulnerability research agent
+
+You are helping a security researcher find and report vulnerabilities in this project.
+Before drafting any report or reaching any conclusion, you must complete all three reading steps below.
+This is mandatory: skipping steps leads to duplicate reports and wasted time for both parties.
+
+## Before reporting anything
+
+Read and follow the three mandatory steps in [SECURITY.md](SECURITY.md#before-reporting-anything).
+
+## Only after all three steps
+
+Assess the finding:
+
+1. Is it in scope?
+2. Is it a duplicate?
+3. Is it covered by the FAQ?
+4. If none of the above: it is likely a valid new finding.
+   Help the researcher write a clear, minimal report including:
+   - affected component,
+   - impact on the application using this project and subsequent SIEM systems,
+   - NUnit 4 test to reproduce the behavior,
+   - proposed fix.
+5. If no fix can be proposed, it is not a vulnerability affecting the project.
+
+## Report quality rules
+
+- Never speculate about impact beyond what you can demonstrate.
+- Reproduction steps must be minimal and self-contained.
+- Do not include unrelated findings in the same report: one issue per report.
+- If unsure about severity, say so explicitly rather than guessing.
diff --git a/SECURITY.md b/SECURITY.md
index 97ef271b..87f8e4ac 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -1,58 +1,153 @@
 <!-- SPDX-License-Identifier: Apache-2.0 -->
-# Vulnerability research agent
+# Security policy
 
-You are helping a security researcher find and report vulnerabilities in this project.
-Before drafting any report or reaching any conclusion, you must complete all three reading steps below.
-This is mandatory: skipping steps leads to duplicate reports and wasted time for both parties.
+## Supported versions
+
+Due to the limited resources of the Apache log4net project, **only the latest minor release of the latest major version** receives security fixes and advisories. All other versions are end-of-life and vulnerability reports against them are not accepted.
+
+| Version | Status |
+|---------|--------|
+| 3.x (latest minor) | ✅ Active maintenance - security fixes accepted |
+| All other versions | ❌ End of life - no security fixes or advisories |
+
+For the full version lifecycle and maintenance policy, see the [versioning and support policy](https://logging.apache.org/log4net/versioning.html).
+
+---
 
 ## Before reporting anything
 
-### Step 1: Read the security model
+Security research on this project is most effective when it accounts for the project's stated threat model and previously disclosed vulnerabilities. **Please complete all three reading steps below before submitting a report.** Skipping them is the leading cause of duplicate reports and out-of-scope submissions, which cost both parties time.
+
+### Step 1 - Read the security model
+
+Fetch and read the project's shared security model:
 
-Fetch and read the project's security model before evaluating any finding:
-https://raw.githubusercontent.com/apache/logging-site/refs/heads/main-site-pro/src/site/antora/modules/ROOT/pages/_threat-model-common.adoc
+> <https://raw.githubusercontent.com/apache/logging-site/refs/heads/main-site-pro/src/site/antora/modules/ROOT/pages/_threat-model-common.adoc>
 
 Use this to answer:
-- Is this component/behavior in scope at all?
+- Is this component or behavior in scope at all?
 - Does the project consider this a security boundary?
 
-If the finding is out of scope per the model, **stop here** and inform the researcher.
+If the finding is out of scope per the model, **stop here** and do not submit a report.
 
-### Step 2: Check previously disclosed vulnerabilities
+### Step 2 - Check previously disclosed vulnerabilities
 
 Read the project's Vulnerability Disclosure Report to check for duplicates:
-https://logging.apache.org/cyclonedx/vdr.xml
 
-Compare the finding against each entry.
-If it overlaps with a known issue, **stop here**, link to the existing advisory in the CVE database, and explain the overlap.
+> <https://logging.apache.org/cyclonedx/vdr.xml>
+
+Compare the finding against each entry. If it overlaps with a known issue, link to the existing advisory in the CVE database, explain the overlap rather than filing a new report and **stop here**.
+
+### Step 3 - Read the Security FAQ
+
+Read the Security FAQ before concluding that a behavior is a vulnerability:
+
+> <https://raw.githubusercontent.com/apache/logging-site/refs/heads/main-site-pro/src/site/antora/modules/ROOT/pages/security/faq.adoc>
+
+The FAQ lists behaviors that are **intentional and not vulnerabilities**. If the finding matches an FAQ entry, it is a known non-issue. The rendered HTML version is at <https://logging.apache.org/security/faq.html>.
+
+---
+
+## Reporting a vulnerability
+
+**Please do not report security vulnerabilities through public GitHub issues.**
+
+log4net follows the [Apache Software Foundation security response process](https://www.apache.org/security/). Once you have completed all three reading steps above, report by:
+
+1. Emailing **security@logging.apache.org** with the subject line `[log4net] <brief description>`.
+2. Including as much of the following as possible:
+   - Type of vulnerability
+   - Affected version(s) and .NET target framework(s)
+   - Affected component and its role in the attack chain
+   - Impact on the application using log4net and on downstream SIEM systems
+   - Minimal, self-contained reproduction steps or a proof-of-concept NUnit 4 test
+   - Proposed fix - if no fix can be demonstrated, reconsider whether this constitutes a vulnerability affecting the project
+
+You will receive an acknowledgement within **14 business days**. The security team will keep you informed of progress toward a fix and public disclosure.
+
+### Report quality guidelines
+
+- Never speculate about impact beyond what you can demonstrate with the reproduction case.
+- One issue per report - do not bundle unrelated findings.
+- If unsure about severity, say so explicitly rather than guessing.
+
+---
+
+## Remediation time frames
+
+We follow risk-based time frames aligned with ASF security response guidelines:
+
+| Severity | CVSS range | Target patch release |
+|----------|------------|----------------------|
+| Critical | 9.0 – 10.0 | Within 14 days |
+| High | 7.0 – 8.9 | Within 30 days |
+| Medium | 4.0 – 6.9 | Within 90 days |
+| Low | 0.1 – 3.9 | Next scheduled release |
+
+Time frames begin from the date the vulnerability is confirmed and a fix is determined to be feasible. Complex issues requiring architectural changes may exceed these targets; affected reporters will be notified with an updated timeline.
+
+Third-party dependencies follow the same schedule. A confirmed vulnerability in a dependency triggers an assessment within **7 business days** to determine whether log4net is affected, followed by remediation within the applicable time frame above.
+
+---
+
+## Dependency management
+
+log4net maintains a minimal set of third-party dependencies. A [CycloneDX VDR (Vulnerability Disclosure Report)](https://logging.apache.org/cyclonedx/vdr.xml) is published with each release and updated out-of-band when new vulnerability data becomes available.
+
+Automated dependency scanning runs on every pull request and on a weekly schedule via GitHub Actions. Any flagged advisory is triaged within **7 business days** of detection.
+
+---
+
+## Scope and trust model
+
+### In scope
+
+- Vulnerabilities in log4net library code across supported versions
+- Vulnerabilities introduced by log4net's use of third-party dependencies
+- Security issues in the build pipeline that could lead to supply-chain compromise
+
+### Out of scope
+
+- Issues that require a malicious actor to control log4net's configuration source (configuration is a trusted input by design - see trust model below)
+- Log injection in consuming applications where the application does not sanitize log data before passing it to log4net
+- Display-layer issues in log viewers that render log output without escaping (responsibility of the viewer)
+- Vulnerabilities in unsupported versions
+
+### Trust model
+
+log4net assumes that **configuration sources are trusted**. Type instantiation, appender configuration, and network endpoint setup all rely on administrator-controlled configuration. Compromise of the configuration channel is outside log4net's threat model and is the responsibility of deployment infrastructure.
+
+Runtime log event data (messages, properties, exceptions) is treated as **untrusted** and is consistently encoded in all XML layout output paths.
+
+The authoritative statement of the shared threat model for Apache Logging projects is at:
+<https://logging.apache.org/what-is-a-vulnerability.html>
+
+---
+
+## Known limitations and mitigations
+
+### BinaryFormatter (legacy .NET 4.6.2+ only)
+
+`LoggingEvent` serialization uses `BinaryFormatter` on .NET Framework 4.6.2 and later targets. `BinaryFormatter` is [inherently unsafe](https://aka.ms/binaryformatter) when deserializing data from untrusted sources.
+
+**Mitigation until 4.0:** Only deserialize `LoggingEvent` objects received over authenticated, encrypted transports from trusted peers. Do not expose deserialization endpoints to untrusted networks.
+
+**Resolution:** `BinaryFormatter` will be **removed in log4net 4.0**.
 
-### Step 3: Read the Security FAQ
+### PatternLayout and plain-text output
 
-Read the Security FAQ before concluding anything is a vulnerability:
-https://raw.githubusercontent.com/apache/logging-site/refs/heads/main-site-pro/src/site/antora/modules/ROOT/pages/security/faq.adoc
+`PatternLayout` produces plain text and does not encode log event data for HTML, terminal, or other rendering contexts. Prevention of log injection in plain-text output is the responsibility of the consuming application and the log viewer.
 
-The FAQ lists behaviors that are **intentional and not vulnerabilities**.
-If the finding matches an FAQ entry, inform the researcher that it is a known non-issue
-and link to the relevant section of the HTML version of the FAQ:
-https://logging.apache.org/security/faq.html
+XML layouts (`XmlLayout`, `XmlLayoutSchemaLog4j`) encode all user-controlled data through centralized safe-writing extension methods and are not affected by this limitation.
 
-## Only after all three steps
+---
 
-Assess the finding:
-1. Is it in scope?
-2. Is it a duplicate?
-3. Is it covered by the FAQ?
-4. If none of the above: it is likely a valid new finding.
-   Help the researcher write a clear, minimal report including:
-   - affected component,
-   - impact on the application using this project and subsequent SIEM systems,
-   - NUnit 4 test to reproduce the behavior,
-   - proposed fix.
-5. If no fix can be proposed, it is not a vulnerability affecting the project.
+## Security contacts
 
-## Report quality rules
+| Role | Contact |
+|------|---------|
+| ASF Security Team | security@apache.org |
+| log4net PMC | dev@logging.apache.org |
+| Public security announcements | [Apache Logging Security](https://logging.apache.org/security.html#vulnerabilities) |
 
-- Never speculate about impact beyond what you can demonstrate.
-- Reproduction steps must be minimal and self-contained.
-- Do not include unrelated findings in the same report: one issue per report.
-- If unsure about severity, say so explicitly rather than guessing.
\ No newline at end of file
+Security advisories for log4net are published on the [Apache Logging security page](https://logging.apache.org/security.html#vulnerabilities) and announced on the `announce@apache.org` mailing list.
\ No newline at end of file