asf-tooling opened a new issue, #1025: URL: https://github.com/apache/tooling-trusted-releases/issues/1025
**ASVS Level(s):** [L1] **Description:** ### Summary ASVS 6.1.1 explicitly lists 'adaptive response' as a control that should be documented. The authentication security documentation describes static rate limits but does not document any adaptive or progressive response mechanisms. What is NOT documented: what happens when rate limits are repeatedly hit by the same actor, whether rate limit windows escalate, whether there are alerting or monitoring thresholds, or whether there is automated account protection beyond rate limiting. The documentation stops at 'return 429 with retry_after' with no described escalation or adaptive behavior. ### Details Affected locations: - `security/ASVS/audit_guidance/authentication-security.md`: No adaptive response documentation - `atr/storage/writers/tokens.py` lines 106-130: Static rate limiting only The documentation describes static rate limits but no adaptive or progressive response mechanisms. ### Recommended Remediation Document the adaptive response strategy in authentication-security.md. If the project's position is that static rate limits plus OAuth delegation are sufficient, this should be explicitly stated with rationale: ```markdown ## Adaptive Response Strategy ATR uses a defense-in-depth approach combining static rate limits with OAuth delegation for adaptive response: ### Static Rate Limits - API endpoints: 500 requests/hour per IP - Web endpoints: 100 requests/minute per IP - Admin endpoints: 30 requests/minute per IP ### OAuth Delegation Password authentication is delegated to ASF OAuth provider which implements: - Progressive delays on failed attempts - Account lockout after repeated failures - CAPTCHA challenges for suspicious patterns - IP-based reputation scoring ### PAT Security - PATs are 256-bit cryptographically random tokens - Brute force is computationally infeasible - Rate limiting prevents systematic enumeration ### JWT Security - JWT signing uses server-controlled secrets - Token expiration limits exposure window - Revocation mechanisms exist for compromised tokens ### Monitoring Thresholds (Recommended) While not currently implemented, operators should monitor: - Rate limit violations per IP (threshold: >10/hour) - Failed authentication attempts per user (threshold: >5/hour) - Unusual geographic patterns - Concurrent session anomalies ### Future Considerations - Application-level adaptive delays (Issue #XXX) - Automated IP blocking for persistent abuse (Issue #XXX) - Integration with ASF-wide abuse detection systems ``` Include recommended monitoring thresholds and future considerations. ### Acceptance Criteria - [ ] Adaptive response strategy is documented - [ ] Rationale for current approach is explained - [ ] Monitoring thresholds are recommended - [ ] Future considerations are documented - [ ] Unit test verifying the fix ### References - Source reports: L1:6.1.1.md - Related findings: FINDING-245 - ASVS sections: 6.1.1 ### Priority Medium --- --- **Triage notes:** documentation - add docs saying we do not have adaptive response -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
