(tooling-agents) branch main updated: ASVS audit: 16.1.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]

[as...@apache.org]

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

asf-tooling pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tooling-agents.git


The following commit(s) were added to refs/heads/main by this push:
     new 00230f5  ASVS audit: 16.1.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
00230f5 is described below

commit 00230f5ca5e876171b264860898d303a44cb6255
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:54:11 2026 +0200

    ASVS audit: 16.1.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
---
 ASVS/reports/steve/v3/d0aa7e9/all/16.1.1.md | 144 ++++++++++++++++++++++++++++
 1 file changed, 144 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/16.1.1.md b/ASVS/reports/steve/v3/d0aa7e9/all/16.1.1.md
new file mode 100644
index 0000000..72eb172
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/16.1.1.md
@@ -0,0 +1,144 @@
+# Security Audit Report: ASVS 16.1.1
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 16.1.1 |
+| **Files Analyzed** | 5 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled, and for how long logs are kept.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 1 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-16.1.1: Security Logging Documentation
+
+### Findings for 16.1.1
+
+### [HIGH]
+
+**Finding ID:** ASVS-1611-HIGH-001
+
+**Title:** No Logging Inventory Document Exists
+
+**File:** Entire codebase (all files reviewed)
+
+**Evidence:**
+
+The codebase contains logging statements across multiple layers but no inventory document describing:
+- What events are logged at each layer
+- Log formats used
+- Where logs are stored
+- How logs are used for monitoring/incident response
+- How access to logs is controlled
+- Retention policies
+
+Logging is present in:
+- `v3/server/pages.py` — Application-level action logging (user actions)
+- `v3/steve/election.py` — Library-level operation logging (election operations)
+- `v3/server/main.py` — Infrastructure-level logging configuration
+- `v3/server/bin/mail-voters.py` — Script-level logging
+
+**Impact:** Without a logging inventory, security teams cannot verify coverage, incident responders cannot locate relevant logs quickly, and compliance auditors cannot validate that logging meets regulatory requirements. There's also no way to verify that logs aren't being sent to undocumented destinations (see the `print()` statements in pages.py).
+
+**Remediation:** Create a `LOGGING_INVENTORY.md` document:
+
+```markdown
+# Logging Inventory
+
+## Application Layer (pages.py)
+- **Events**: User login, election CRUD, vote submission, access denials
+- **Format**: `[{asctime}|{levelname}|{name}] {message}`
+- **Storage**: stdout/stderr → [define destination]
+- **Access Control**: [define who can access]
+- **Retention**: [define retention period]
+
+## Library Layer (election.py)
+- **Events**: Election state changes, issue CRUD, database errors
+- **Format**: Same as application layer
+- **Storage**: Same handler hierarchy
+
+## Infrastructure Layer (main.py)
+- **Events**: Server startup/shutdown, configuration loading
+- **Format**: Same format string
+- **Storage**: stdout/stderr
+
+## Script Layer (mail-voters.py)
+- **Events**: Email sending attempts and results
+- **Format**: Default logging format
+- **Storage**: stdout/stderr
+```
+
+### Security Controls Inventory for 16.1.1
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Logging inventory document | Not present | **MISSING** |
+| Log format documentation | Implicit in `main.py` DATE_FORMAT | **INADEQUATE** |
+| Log storage documentation | Not present | **MISSING** |
+| Log access control documentation | Not present | **MISSING** |
+| Log retention policy | Not present | **MISSING** |
+| Event catalog | Not present | **MISSING** |
+
+### Positive Patterns for 16.1.1
+
+- Consistent use of Python's `logging` module across all files
+- Logger instances are module-scoped (`_LOGGER = logging.getLogger(__name__)`)
+- Logging configuration is centralized in `main.py`
+- Security-relevant actions (create, open, close, vote, delete) are logged in `pages.py`
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Logging Architecture Maturity**: The application has basic logging in place with consistent patterns (module loggers, action logging), but lacks the maturity markers expected for ASVS Level 2/3: no documentation, no structured format, no correlation IDs, and insufficient timestamp precision.
+
+2. **Async/Sync Impedance Mismatch**: The application uses Quart (async) but all database operations via `asfpy.db`/`sqlite3` are synchronous. This creates a fundamental architectural issue affecting both concurrency fairness (15.4.4) and potentially logging reliability (if the event loop is blocked, log writes may also be delayed).
+
+3. **Centralized Logging Configuration with Gaps**: While `main.py` centralizes logging configuration, the `print()` statements in `pages.py` and the separate `basicConfig()` in `mail-voters.py` create inconsistencies that undermine all logging requirements simultaneously.
+
+4. **Security Event Coverage**: The application logs the right categories of events (CRUD operations, state changes, access decisions) but the metadata quality (missing source IP, missing correlation ID, imprecise timestamps) significantly reduces the investigative value of these logs.
+
+5. **No Separation of Security vs. Operational Logs**: All logs go to the same destination with the same format. There's no differentiation between security-relevant events (votes, election state changes, access denials) and operational events (loading elections, rendering templates).
+
+## Cross-cutting Recommendations
+
+### Immediate (Sprint 1)
+
+1. **Fix timestamp format** — Change `DATE_FORMAT` to `'%Y-%m-%dT%H:%M:%S%z'` and set `logging.Formatter.converter = time.gmtime` for UTC. Single-line fix with highest impact on 16.2.2.
+
+2. **Remove `print()` statements** — Replace the two `print('FORM:', form)` calls in `pages.py` with `_LOGGER.debug()` or remove entirely. Fixes 16.2.3 compliance.
+
+3. **Add source IP to log messages** — Include `quart.request.remote_addr` in security-relevant log entries. Improves 16.2.1 metadata.
+
+### Short-term (1-2 Sprints)
+
+4. **Implement request correlation IDs** — Add a `before_request` hook that generates and propagates a request ID through all log entries. Addresses 16.2.4 correlation.
+
+5. **Create logging inventory document** — Document all event types, destinations, formats, access controls, and retention. Addresses 16.1.1 entirely.
+
+6. **Adopt structured logging format** — Migrate to JSON logging format (e.g., `python-json-logger`) for machine parseability. Addresses 16.2.4.
+
+### Long-term (Next Quarter)
+
+7. **Implement async database layer** — Use `aiosqlite` or wrap synchronous calls in `asyncio.to_thread()` with a bounded thread pool to prevent event loop starvation. Addresses 15.4.4.
+
+8. **Add request timeout middleware** — Configure Hypercorn's `keep_alive_timeout` and add application-level timeouts for database operations. Further addresses 15.4.4.
+
+9. **Implement log access controls** — Define and enforce who can access logs, implement log rotation with retention policies, and consider separating security logs from operational logs. Addresses 16.1.1 comprehensively.
+        
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org