Security Practices
Last updated: February 13, 2026
This page describes the security controls HAIEC Inc. (“HAIEC”) implements to protect customer data and platform integrity. All statements below are based on the current production system architecture.
Scope & Limitations
- HAIEC has not completed a SOC 2 Type II audit. We are working toward this certification.
- HAIEC does not hold ISO 27001 certification at this time.
- We have not engaged a third-party penetration testing firm. Customers requiring this should contact us.
- This page describes implemented controls, not aspirational goals.
1. Infrastructure
Hosting
- Application: Vercel (serverless, edge network). SOC 2 Type II certified provider.
- Database: Neon (serverless PostgreSQL). SOC 2 Type II certified provider.
- Region: United States (us-east-1 primary).
- CDN: Vercel Edge Network with automatic TLS termination.
Network Security
- All traffic encrypted in transit via TLS 1.2+ (TLS 1.3 preferred).
- HTTPS enforced on all endpoints. HTTP requests are redirected.
- Strict Content Security Policy (CSP) headers applied via middleware.
- HSTS (HTTP Strict Transport Security) enabled.
2. Authentication & Authorization
- Authentication: NextAuth.js with OAuth 2.0 providers (GitHub, Google).
- Session management: Server-side sessions with secure, HttpOnly cookies.
- API authentication: API keys with HMAC signature verification for CI/CD integrations.
- GitHub App: Installation-scoped tokens with minimum required permissions.
- Tenant isolation: All database queries are scoped to the authenticated user's ID. Cross-tenant access is prevented at the query level.
- Webhook verification: GitHub webhook signatures verified using HMAC-SHA256 before processing.
3. Data Protection
Encryption
- In transit: TLS 1.2+ for all connections.
- At rest: Neon PostgreSQL uses AES-256 encryption for data at rest.
- Evidence hashing: SHA-256 content hashing for evidence integrity verification.
- PII handling: NYC LL144 candidate PII is hashed using SHA-256 before storage. Raw PII is not retained.
- Local storage encryption: Sensitive wizard data encrypted client-side before localStorage persistence.
Data Minimization
- Source code is analyzed in-memory during scans and not persisted.
- Only scan findings, metadata, and evidence hashes are stored.
- GitHub App collects repository metadata only (branch protection status, file presence). File contents are not stored.
4. Rate Limiting & Abuse Prevention
- API endpoints: 100 requests per 15 minutes per IP address.
- Authentication endpoints: 50 requests per minute per IP address.
- Contact/newsletter forms: 5 requests per hour per IP address.
- Static pages: 1,000 requests per hour per IP address.
- Implementation: Redis-backed rate limiting at the middleware layer.
- Fail-closed: If Redis is unavailable, rate limiting returns 503 (service unavailable) rather than allowing unlimited requests.
5. Input Validation & Hardening
- Schema validation: Zod schema validation on API inputs (CI/CD scan requests, runtime test configurations).
- Webhook signatures: All incoming webhooks (GitHub, Stripe, Resend) verified via cryptographic signatures before processing.
- SQL injection prevention: Prisma ORM with parameterized queries. No raw SQL.
- XSS prevention: React's built-in escaping plus Content Security Policy headers.
- CSRF protection: NextAuth CSRF tokens on all form submissions.
- File upload restrictions: Documented formats only (PDF, MD, JSON). Size limits enforced.
6. Audit Logging & Monitoring
- Error tracking: Sentry for real-time error monitoring and alerting.
- Webhook logging: All GitHub App webhook deliveries logged with delivery ID, event type, and processing outcome.
- Scan audit trails: Every security scan records: scan ID, user ID, repository, branch, start time, completion time, finding count, and status.
- Evidence provenance: Evidence records include content hash, collection timestamp, commit SHA, and rule version.
- Report access logging: Report views tracked with timestamp, user ID, and IP address.
- API key usage: All API key authentications logged.
7. Determinism & Reproducibility
HAIEC's compliance engines use deterministic, rule-based logic. No machine learning, probabilistic models, or adaptive algorithms are used in compliance evaluation.
- Same input produces same output. All rule evaluation is if-then logic.
- Version-locked rules: Engine versions, rule pack versions, and scoring formulas are versioned and tracked.
- Timestamped assessments: Every assessment records the exact rule version and evaluation time.
- No adaptive behavior: The system does not learn or adjust rules based on usage patterns.
For full technical details, see our Technical Transparency page.
8. Testing & Quality Assurance
- Unit tests: 1,200+ test cases covering security engines, evidence integrity, and determinism contracts.
- Determinism tests: Dedicated test suites verify that identical inputs produce identical outputs across engine versions.
- Evidence integrity tests: Verify content hashing, tamper detection, and provenance chain.
- Tenant isolation tests: Verify that users cannot access other users' data.
- TypeScript: Strict TypeScript compilation with zero errors enforced before deployment.
9. Third-Party Services
HAIEC uses the following third-party services to operate the platform. For the complete list with data processing details, see our Subprocessor List.
| Provider | Purpose | Certification |
|---|---|---|
| Vercel | Application hosting | SOC 2 Type II |
| Neon | PostgreSQL database | SOC 2 Type II |
| Stripe | Payment processing | PCI DSS Level 1 |
| Resend | Transactional email | SOC 2 Type II |
| GitHub | Source code, App integration | SOC 2 Type II |
| Sentry | Error monitoring | SOC 2 Type II |
| Upstash | Redis (rate limiting) | SOC 2 Type II |
Questions?
For security inquiries, vulnerability reports, or to request additional documentation:
- Security issues: security@haiec.com
- General inquiries: contact@haiec.com
- Vulnerability disclosure: Responsible Disclosure Policy