You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by fr...@apache.org on 2026/05/19 20:08:15 UTC
(logging-log4net) branch Feature/SECURITY.md updated (2455c8c3 -> 976b8095)
This is an automated email from the ASF dual-hosted git repository.
FreeAndNil pushed a change to branch Feature/SECURITY.md
in repository https://gitbox.apache.org/repos/asf/logging-log4net.git
discard 2455c8c3 extract SECURITY.md and add a remediation time frame policy
new 976b8095 extract SECURITY.md and add a remediation time frame policy
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (2455c8c3)
\
N -- N -- N refs/heads/Feature/SECURITY.md (976b8095)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
SECURITY.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
(logging-log4net) 01/01: extract SECURITY.md and add a remediation time frame policy
Posted by 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 976b809591e9ed87cbd041ed48a22663066e8324
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 | 168 +++++++++++++++++++++++++++++++++++++++++++++++-------------
2 files changed, 163 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..3ea50129 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -1,58 +1,152 @@
<!-- 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 |
+|------|---------|
+| Apache Logging Security Team | security@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