(tooling-agents) branch main updated: ASVS audit: 10.4.11.md (redacted)

[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 f7a87a3  ASVS audit: 10.4.11.md (redacted)
f7a87a3 is described below

commit f7a87a344b162ac7b43b9899d61b4ff5d2ae7f49
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:01:18 2026 +0200

    ASVS audit: 10.4.11.md (redacted)
---
 ASVS/reports/steve/v3/d0aa7e9/all/10.4.11.md | 77 ++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/10.4.11.md b/ASVS/reports/steve/v3/d0aa7e9/all/10.4.11.md
new file mode 100644
index 0000000..534a802
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/10.4.11.md
@@ -0,0 +1,77 @@
+# Security Audit Report: ASVS 10.4.11
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 10.4.11 |
+| **Files Analyzed** | 6 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the authorization server configuration only assigns the required scopes to the OAuth client.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-10.4.11: OAuth Scope Assignment
+
+### Findings for 10.4.11
+
+No findings detected.
+
+The provided codebase is an election management application (Apache Steve) that acts as a **resource server / web application** — not an OAuth Authorization Server. The authentication layer uses `asfquart.auth.require` with roles like `R.committer` and `R.pmc_member`, which appear to be consumed from an external identity provider, but there is no OAuth Authorization Server implementation in this code that assigns scopes to OAuth clients.
+
+There is no:
+- OAuth client registration logic
+- Scope assignment or configuration
+- Token issuance logic
+- Client metadata storage with allowed scopes
+
+### Security Controls Inventory for 10.4.11
+
+No applicable controls in this scope. The code does not implement an OAuth Authorization Server. Authentication is delegated to an external system (`asfquart.auth` / `asfquart.session`), whose implementation is not included in the audited files.
+
+### Positive Patterns for 10.4.11
+
+- The application uses role-based access control decorators (`R.committer`, `R.pmc_member`) that suggest a principle-of-least-privilege approach at the application layer, though this is not OAuth scope management.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **This is not an OAuth Authorization Server**: The entire codebase implements an election management web application (Apache Steve). It is a resource server / web application that *consumes* authentication from an external provider (`asfquart.auth`, `asfquart.session`). None of the ASVS 10.4.x OAuth Authorization Server requirements are applicable to this code.
+
+2. **External Authentication Dependency**: The application delegates authentication to an external system. The security posture of the OAuth/OIDC provider (if one is used) cannot be assessed from this code. The ASVS 10.4.x requirements would need to be audited against the actual authorization server implementation (e.g., an identity provider like Keycloak, Auth0, or a custom AS).
+
+3. **Session-Based Architecture**: The application uses server-side sessions (`asfquart.session.read()`) with role checks (`R.committer`, `R.pmc_member`), which is a fundamentally different authentication architecture than OAuth token-based access. The security of the session mechanism itself is not visible in the provided code.
+
+4. **Application-Level Authorization Gaps**: While not related to the OAuth AS requirements, the code has multiple `### check authz` placeholder comments indicating that fine-grained authorization (e.g., verifying the current user is the election owner before allowing management operations) is not yet implemented. This is a significant application security concern but falls outside the scope of ASVS 10.4.x.
+
+## Cross-cutting Recommendations
+
+**Immediate:**
+- No immediate actions required for ASVS 10.4.x — these requirements are not applicable to the audited codebase.
+- If this application relies on an external OAuth Authorization Server, that server's configuration should be audited separately against these requirements.
+
+**Short-term:**
+- Identify and document the external authentication/authorization provider used by this application.
+- Audit the external OAuth AS (if applicable) against ASVS 10.4.11–10.4.16 requirements directly.
+- If the `asfquart.auth` module interfaces with an OAuth provider, review its client registration to ensure scopes, response modes, and authentication methods are properly configured.
+
+**Long-term:**
+- If this application is intended to become an OAuth-protected resource server (rather than session-based), implement proper token validation including sender-constraint verification (mTLS certificate binding or DPoP proof validation) as required by ASVS 10.4.14.
+- Consider whether the application should enforce scope-based access control if migrating to an OAuth architecture.
+        
\ 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