(tooling-agents) branch main updated: ASVS audit: 13.2.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 f1a3225  ASVS audit: 13.2.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
f1a3225 is described below

commit f1a3225c5be68dbb2f3a576705f4afe9cf463277
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:52:48 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/13.2.1.md b/ASVS/reports/steve/v3/d0aa7e9/all/13.2.1.md
new file mode 100644
index 0000000..9b3ad46
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/13.2.1.md
@@ -0,0 +1,145 @@
+# Security Audit Report: ASVS 13.2.1
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 13.2.1 |
+| **Files Analyzed** | 14 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that communications between backend application components that don't support the application's standard user session mechanism, including APIs, middleware, and data layers, are authenticated. Authentication must use individual service accounts, short-term tokens, or certificate-based…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 2 |
+
+---
+
+## ASVS-13.2.1: Backend Communication Authentication
+
+### Findings for 13.2.1
+
+#### [LOW]
+**Finding ID:** ASVS-1321-LOW-001
+
+**Title:** SQLite database access lacks authentication mechanism
+
+**Location:** `v3/steve/election.py:35-37`, `v3/steve/persondb.py:25-26`
+
+**Description:** Communications between application components and the SQLite database do not use any authentication mechanism. The database is accessed via file path with no credentials:
+
+```python
+# v3/steve/election.py, lines 35-37
+@staticmethod
+def open_database(db_fname):
+    return asfpy.db.DB(db_fname, yaml_fname=QUERIES, yaml_section='election')
+```
+
+```python
+# v3/steve/persondb.py, lines 25-26
+@classmethod
+def open(cls, db_fname):
+    return cls(asfpy.db.DB(db_fname, yaml_fname=QUERIES, yaml_section='person'))
+```
+
+SQLite is a file-based database and does not natively support user authentication. Access control depends entirely on file system permissions.
+
+**Note:** This is classified as LOW because SQLite's embedded nature means it runs in-process and is not a network service. However, the requirement applies to "data layers" which includes databases. The application relies solely on OS file permissions rather than cryptographic authentication.
+
+**Data Flow:** Application process → file system → `steve.db` → no authentication layer
+
+**Impact:** If the file system permissions are misconfigured, any process on the same host could read or modify election data, cryptographic salts, and encrypted votes.
+
+**Remediation:** For SQLite specifically:
+- Document that file system permissions serve as the authentication mechanism
+- Ensure the database file has restrictive permissions (e.g., `0600`, owned by the application service account)
+- Consider SQLite encryption extensions (e.g., SQLCipher) for data-at-rest protection
+- If migrating to a networked database, implement service account authentication with short-term credentials
+
+#### [LOW]
+**Finding ID:** ASVS-1321-LOW-002
+
+**Title:** Email service communication lacks documented authentication configuration
+
+**Location:** `v3/server/bin/mail-voters.py:67-73`
+
+**Description:** The email sending function does not show explicit SMTP authentication:
+
+```python
+# v3/server/bin/mail-voters.py, lines 67-73
+asfpy.messaging.mail(
+    sender='Apache Election Platform <vo...@apache.org>',
+    recipient=voter.email,
+    subject=f'Vote in Election: {metadata.title}',
+    message=rendered_body,
+    # Add other parameters as needed (e.g., auth, headers)
+)
+```
+
+The comment `# Add other parameters as needed (e.g., auth, headers)` suggests authentication is not yet configured. The `asfpy.messaging` library may handle this internally, but it is not documented or visible in this codebase.
+
+**Impact:** If SMTP authentication is not configured, the application may be relying on network-level trust (e.g., sending from within the same network as the mail relay) which could be spoofed or abused.
+
+**Remediation:** Document SMTP authentication method and ensure it uses short-term tokens or certificate-based authentication rather than static passwords.
+
+### Security Controls Inventory for 13.2.1
+
+| Control | Location | Coverage |
+|---------|----------|----------|
+| ASF OAuth authentication | `v3/server/main.py:36-40` | User-facing authentication (not backend-to-backend) |
+| Database access | `v3/steve/election.py:35-37` | No authentication — file-based access |
+| Email sending | `v3/server/bin/mail-voters.py:67-73` | Authentication not configured/documented |
+| TLS for HTTPS | `v3/server/config.yaml.example` | Covers transport encryption, not backend auth |
+
+### Positive Patterns for 13.2.1
+
+- The application uses ASF OAuth (external authentication service) for user authentication rather than storing credentials locally
+- TLS certificates are configured for HTTPS communication
+- The architecture uses SQLite (embedded, in-process) which inherently avoids network-based attack vectors on the database
+- No hardcoded API keys or passwords were found in the source code
+- The `config.yaml.example` separates secrets (cert paths) from source code
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Documentation vs. Implementation Gap**: The application has good architectural documentation (`ARCHITECTURE.md`, `schema.md`) covering design intent, but lacks operational documentation required by ASVS Level 2-3 (communication inventories, resource management strategies, secrets rotation schedules).
+
+2. **Single Database Pattern**: The use of SQLite as an embedded database simplifies many backend communication concerns (no network authentication needed, no connection pool management) but makes it impossible to apply traditional service-account or role-based database access controls.
+
+3. **Trust Boundary Ambiguity**: The `TODO.md` file acknowledges multiple unimplemented security controls (`### check authz` placeholders, CSRF placeholder). The system currently relies primarily on the ASF OAuth committer-level authentication as its sole access control boundary, with no fine-grained authorization distinguishing election owners from other committers.
+
+4. **Operational Tooling Without Controls**: CLI scripts (`create-election.py`, `mail-voters.py`) operate with the same privileges as the web server but without any authentication or authorization layer, creating a potential privilege escalation path for anyone with shell access.
+
+5. **Consistent Cryptographic Approach**: The cryptographic design (Argon2 key derivation, separate salts per voter-issue pair, encrypted votes, anti-tamper keys) is well-documented and consistently applied, representing a strength in the security architecture.
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (Address within current sprint)
+1. **Create a Communications Inventory document** listing all external services (OAuth, SMTP, LDAP), protocols, authentication methods, and network requirements — satisfies ASVS 13.1.1 at minimal implementation cost
+2. **Document existing secrets** and their criticality in a secrets inventory, even without rotation automation — satisfies ASVS 13.1.4 documentation requirement
+
+### Short-term (1-3 months)
+3. **Add resource management documentation** defining timeouts, connection limits, and failure handling for SQLite, OAuth, and SMTP — satisfies ASVS 13.1.2 and 13.1.3
+4. **Implement read-only database connections** for components that only need read access (mail script, voter-facing queries) — improves ASVS 13.2.2 compliance
+5. **Implement TLS certificate rotation procedures** and document the rotation schedule
+
+### Long-term (3-6 months)
+6. **Evaluate migration from SQLite** to a database that supports role-based access control if the application scales beyond single-server deployment — would fully satisfy ASVS 13.2.1 and 13.2.2
+7. **Implement connection lifecycle management** with explicit open/close patterns (context managers) for all database access paths to prevent resource leaks
+8. **Add circuit breaker patterns** for OAuth and SMTP communication with documented fallback behavior
+9. **Implement proper CSRF tokens and session-based secrets** with defined rotation (currently placeholder) — prerequisite for ASVS 13.1.4 compliance on session secrets
+        
\ 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