EDDI

Repository on GitHub, which uses git. git is distributed.

The GitHub organization (labsai) enforces two-factor authentication for all members. Both core maintainers (@ginccc, @rolandpickl) have 2FA enabled on their GitHub accounts. GitHub enforces 2FA for repository push access and organization membership.
Also: GitHub requires 2FA as of March 2023. [osps_ac_01_01]

Both core maintainers use cryptographic 2FA mechanisms (TOTP authenticator apps and/or hardware security keys) for GitHub access. GitHub supports TOTP, WebAuthn/FIDO2, and GitHub Mobile as cryptographic 2FA methods. SMS-only 2FA is not used.

https://github.com/labsai/EDDI/blob/main/docs/code-review-standards.md

The project documents its code review requirements in docs/code-review-standards.md. This includes:

• Mandatory peer review for all changes to main (enforced by CODEOWNERS)
• Security-sensitive review areas (VaultSecretProvider, SafeHttpClient, auth guards)
• AI-assisted code review requirements (all AI-generated code must be reviewed by a human)
• Merge policy (squash-and-merge, CI must pass)
  The CODEOWNERS file assigns @ginccc and @rolandpickl as default reviewers for all files.

Branch protection on main requires at least one approving review before merge. The CODEOWNERS file assigns both core maintainers (@ginccc, @rolandpickl) as required reviewers. All changes go through pull requests with mandatory CI status checks. This is enforced by GitHub branch protection rules.

https://github.com/labsai/EDDI/blob/main/docs/build-reproducibility.md

EDDI builds are reproducible via Maven Wrapper (pinned Maven version), explicit dependency versions in pom.xml, Quarkus BOM for transitive dependency management, and SHA-pinned CI action versions. Docker images use digest-pinned base images. The build process is documented in docs/build-reproducibility.md. Published images are Cosign-signed and verifiable.

https://github.com/labsai/EDDI/blob/main/pom.xml

Tests are invoked using the standard Maven command: ./mvnw test (unit tests) or ./mvnw verify (unit + integration tests). This is the standard test invocation for Java/Maven projects. The project uses JUnit 5 with Surefire (unit) and Failsafe (integration) plugins, both configured in pom.xml.

https://github.com/labsai/EDDI/actions/workflows/ci.yml

The project uses GitHub Actions for continuous integration. Every push to main and every pull request triggers automated builds and tests (5,100+ tests). The CI pipeline includes: Maven build + unit tests, integration tests with Testcontainers (MongoDB, PostgreSQL), CodeQL SAST, Trivy container scanning, Gitleaks secret scanning, and ZAP DAST. See .github/workflows/ci.yml.

https://github.com/labsai/EDDI/blob/main/docs/security.md#tls-requirements

EDDI supports and encourages secure protocols for all network communications:

1. External API calls: All LLM provider integrations (OpenAI, Anthropic, Google, Azure, AWS, etc.) use HTTPS exclusively. UrlValidationUtils blocks non-HTTP/HTTPS schemes (file://, ftp://, gopher://, jar://).
2. TLS termination: The docs/security.md TLS Requirements section documents both reverse-proxy TLS termination (recommended production pattern) and direct Quarkus TLS configuration via quarkus.http.ssl.* properties.
3. Database connections: MongoDB and PostgreSQL connection strings support TLS natively. The compliance documentation (docs/hipaa-compliance.md) requires encrypted database connections for regulated deployments.
4. No insecure protocols enabled by default: HTTP is the only unencrypted protocol available, intended for localhost development or behind a TLS-terminating reverse proxy. FTP, telnet, and other insecure protocols are not supported.

EDDI runs on Java 25, which defaults to TLS 1.3 and supports TLS 1.2 as a minimum. The Quarkus framework (3.34.3) uses the JVM's built-in TLS implementation via Vert.x/Netty, which enforces TLS 1.2+ by default. TLS 1.0 and TLS 1.1 are disabled in modern JVMs. No configuration in the project downgrades the minimum TLS version. For outbound connections to LLM providers, Java's HttpClient defaults to TLS 1.3 with TLS 1.2 fallback.

https://github.com/labsai/EDDI/blob/main/docs/security-review.md

A comprehensive security review was performed in April 2026, documented in docs/security-review.md. The review covered:

• SAST remediation: 9 CodeQL findings across 6 files (regex injection, path traversal, error exposure)
• SSRF protection: SafeHttpClient introduction, UrlValidationUtils for IP validation
• Secrets management: VaultSecretProvider with encrypted storage and salt rotation
• Container security: Base image digest pinning, Trivy CVE remediation, Cosign signing
• Dynamic analysis: ZAP API scanning, ClusterFuzzLite fuzzing with Jazzer
  The review considered the security boundary (REST API, LLM tool execution, secrets, templating, container runtime) and the threat model (prompt injection, SSRF, secret exfiltration, supply chain, unauthorized access).

https://github.com/labsai/EDDI/blob/main/docs/security.md

EDDI implements multiple hardening mechanisms:

1. Security headers: X-Content-Type-Options (nosniff), X-Frame-Options (DENY), Content-Security-Policy configured out of the box via Quarkus HTTP filter.
2. SSRF protection: SafeHttpClient wraps all outbound HTTP calls with URL re-validation after redirects, preventing SSRF via redirect chains.
3. Rate limiting: Token-bucket rate limiter on all LLM tool calls prevents resource exhaustion.
4. Cost tracking: Per-conversation and per-tenant budget caps prevent runaway LLM costs.
5. Queue capacity management: ConversationCoordinator throws RejectedExecutionException (HTTP 429) when queue capacity is exhausted, preventing unbounded resource consumption.
6. Log injection protection: All user-provided values in log statements are sanitized to prevent log forging.
7. Dependency banning: Maven Enforcer Plugin blocklists known-vulnerable dependency groups.
8. Startup guards: AuthStartupGuard fails startup if production runs without authentication. ComplianceStartupChecks warns about missing TLS and database encryption.
9. No dynamic code execution: Architecturally eliminated — no eval(), no ScriptEngine, no reflection-based execution.
10. Memory safety: Java provides automatic memory management (garbage collection) and bounds checking, eliminating buffer overflow and use-after-free vulnerabilities.

Multiple dynamic analysis tools are applied before release:

1. OWASP ZAP API Scan (DAST) — runs against a live EDDI instance in CI on every push to main. Performs passive analysis of all REST API endpoints using the OpenAPI spec.
2. ClusterFuzzLite — continuous fuzzing via Jazzer targeting PathNavigator and MatchingUtilities. Runs on PRs touching src/ and weekly batch runs.
3. Integration tests with Testcontainers — 550+ integration tests run against real MongoDB and PostgreSQL instances in CI, exercising full request/response cycles through the REST API.
4. Smoke tests — Docker container is started in CI and health/readiness endpoints are verified before release.
   All tools run in GitHub Actions CI on every push to main, ensuring dynamic analysis is applied before any release.

Java runtime assertions are enabled during all test execution via the -ea JVM flag in the Maven Surefire plugin configuration (pom.xml):
<argLine>-ea ${argLine}</argLine>
This ensures that all assert statements in production code are checked during unit and integration test runs. The ${argLine} preserves JaCoCo agent instrumentation. Java assertions are used throughout the codebase for precondition checks and invariant validation.