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

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

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/13.1.4.md b/ASVS/reports/steve/v3/d0aa7e9/all/13.1.4.md
new file mode 100644
index 0000000..1ac9de2
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/13.1.4.md
@@ -0,0 +1,164 @@
+# Security Audit Report: ASVS 13.1.4
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 13.1.4 |
+| **Files Analyzed** | 14 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application's documentation defines the secrets that are critical for the security of the application and a schedule for rotating them, based on the organization's threat model and business requirements.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-13.1.4: Secrets Documentation and Rotation
+
+### Findings for 13.1.4
+
+#### [MEDIUM]
+**Finding ID:** ASVS-1314-MED-001
+
+**Title:** No secrets rotation schedule or lifecycle management documentation
+
+**Location:** `v3/docs/schema.md`, `v3/steve/crypto.py`, `v3/server/config.yaml.example`
+
+**Description:** While the application documents what secrets exist and how they are generated, there is no documentation defining a rotation schedule or lifecycle management for any secret.
+
+**Secrets identified in the system:**
+
+1. **Election salts** (`election.salt`, 16 bytes) — generated once at election opening, never rotated:
+```python
+# v3/steve/crypto.py, lines 27-29
+def gen_salt() -> bytes:
+    "Generate bytes to be used as a salt, for hashing."
+    return secrets.token_bytes(SALT_LEN)
+```
+
+2. **Mayvote salts** (`mayvote.salt`, 16 bytes) — generated once at election opening, never rotated
+
+3. **Opened keys** (`election.opened_key`, 32 bytes) — derived once, used for tamper detection:
+```python
+# v3/steve/crypto.py, lines 32-41
+def gen_opened_key(edata: bytes, salt: bytes) -> bytes:
+    # ...
+    return _hash(digest, salt)
+```
+
+4. **TLS certificate private keys** — path documented but no rotation:
+```yaml
+# v3/server/config.yaml.example
+certfile: localhost.apache.org+3.pem
+keyfile: localhost.apache.org+3-key.pem
+```
+
+5. **Session secrets** — managed by `asfquart`, not documented in this codebase
+
+6. **OAuth client credentials** — referenced but not shown or documented
+
+7. **CSRF tokens** — currently placeholder (`'placeholder'`), not a real secret:
+```python
+# v3/server/pages.py, line 83
+basic.csrf_token = 'placeholder'
+```
+
+**What's documented (in `schema.md`):**
+- Salt field purposes and generation method (`secrets.token_bytes()`)
+- Key derivation algorithm (Argon2)
+- Encryption algorithm (Fernet, planned migration to XChaCha20-Poly1305)
+
+**What's missing:**
+- Rotation schedule for TLS certificates
+- Rotation procedures if election salts are compromised
+- Session secret rotation policy
+- OAuth credential rotation
+- Impact assessment if any secret is compromised
+- Classification of secrets by criticality
+
+**Impact:** Without a defined rotation schedule, compromised secrets may remain in use indefinitely. The placeholder CSRF token represents a complete absence of this security control, which could allow cross-site request forgery attacks.
+
+**Remediation:** Create a secrets management document:
+
+```markdown
+# Secrets Inventory and Rotation Schedule
+
+| Secret | Criticality | Rotation Schedule | Rotation Procedure |
+|--------|------------|-------------------|-------------------|
+| TLS private key | Critical | Annual or on compromise | Re-issue certificate, deploy, restart |
+| Session signing key | High | Monthly | Update config, restart server |
+| OAuth client secret | High | Annual | Coordinate with ASF OAuth team |
+| Election salts | Medium | N/A (single-use per election lifecycle) | Cannot rotate once election opened |
+| CSRF tokens | High | Per-session | Automatically generated per session |
+
+## Compromise Response
+- If TLS key compromised: Revoke certificate immediately, re-issue
+- If session key compromised: Rotate key, invalidate all sessions
+- If election salt compromised: Election integrity may be violated; re-run if possible
+```
+
+### Security Controls Inventory for 13.1.4
+
+| Control | Location | Coverage |
+|---------|----------|----------|
+| Salt generation | `v3/steve/crypto.py:27-29` | Implemented — `secrets.token_bytes()` |
+| Key derivation | `v3/steve/crypto.py:32-41` | Implemented — Argon2 |
+| Cryptographic documentation | `v3/docs/schema.md` | Partial — documents fields, not lifecycle |
+| TLS config | `v3/server/config.yaml.example` | Partial — paths only, no rotation |
+| Rotation schedule | None | Not documented |
+| Secret classification | None | Not documented |
+
+### Positive Patterns for 13.1.4
+
+- Cryptographic secrets use appropriate generation methods (`secrets.token_bytes()`, Argon2)
+- `schema.md` thoroughly documents the purpose and generation of each cryptographic field
+- Planned migration from Fernet to XChaCha20-Poly1305 is documented
+- Salt lengths are validated at the database schema level via CHECK constraints
+- Sensitive fields (`salt`, `opened_key`) are explicitly excluded from public-facing queries and API responses
+
+---
+
+
+
+## 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