Skip to main content

​
Overview

CaseBender uses automated static analysis, secret detection, dependency, infrastructure, container, and release supply-chain controls. Authenticated staging DAST is supported when a dedicated target and test identity are configured.
Automated scanning is not an independent penetration test. CaseBender cannot currently claim a completed third-party penetration test; an authenticated assessment and remediation retest are planned.

​
Security Scan Workflow

Authorized repository reviewers can inspect the Security Scan workflow, including its job results and retained artifacts.
Because the source repository is private, GitHub workflow badge images return 404 Not Found when embedded in public documentation without an authorized GitHub session. A workflow result is evidence of configured automation, not certification or proof that the application has no vulnerabilities.

​
Static Application Security Testing (SAST)

​
ESLint Security Rules

Every pull request is scanned with ESLint security rules that detect:
  • Dynamic eval() expressions
  • Unsafe regular-expression patterns (reported for review)
  • Dynamic file, module, and object access patterns
  • Insecure Buffer and pseudorandom-number usage
  • Potential timing-attack patterns

​
Semgrep Deep Analysis

Semgrep provides deep taint analysis across the TypeScript and Next.js codebase:
  • OWASP Top 10 Rules: Injection, broken authentication, sensitive data exposure, XSS, insecure deserialization
  • TypeScript-Specific Rules: Type confusion, unsafe type assertions, prototype pollution
  • Next.js-Specific Rules: Server-side request forgery, open redirects, insecure API routes
  • Custom Rules: CaseBender-specific patterns for common security mistakes

​
Secret Detection

Gitleaks scans every commit for accidentally committed secrets:
  • API keys and tokens
  • Database connection strings
  • Private keys and certificates
  • Cloud provider credentials
  • Generic high-entropy strings
Gitleaks scans both the current commit and the full git history to catch secrets that may have been committed and later removed.

​
Dynamic Application Security Testing (DAST)

​
OWASP ZAP

OWASP ZAP is configured to perform an authenticated active scan against a dedicated staging application:
  • Schedule: Weekly (every Sunday at 2 AM UTC)
  • Scan Type: Full active scan (not just passive observation)
  • Target: A required non-placeholder DAST_TARGET_URL
  • Authentication: A dedicated test identity supplied through masked repository secrets
  • Preflight: CaseBender identity and authenticated session are verified before scanning
  • Results: Preserved as workflow artifacts; SARIF ingestion is used only where GitHub Code Security is licensed
The workflow fails closed when the target or credentials are missing. A successful run must not be interpreted as complete API or business-logic coverage.

​
What ZAP Tests

  • SQL injection
  • Cross-site scripting (XSS)
  • Cross-site request forgery (CSRF)
  • Server-side request forgery (SSRF)
  • Directory traversal
  • Remote code execution
  • Authentication bypass
  • Session management flaws
  • Information disclosure

​
Vulnerability Management

​
Continuous Scanning

Vulnerabilities are detected through multiple channels: For private repositories without GitHub Code Security, the production pnpm audit and Trivy filesystem gates provide the merge-blocking dependency path.

​
Vulnerability SLAs

When vulnerabilities are discovered, they must be remediated within defined SLAs:

​
Risk Acceptance

When a vulnerability cannot be immediately remediated (e.g., no patch available), CaseBender follows a formal risk acceptance process:
  1. Documentation: Vulnerability details, affected components, and business impact
  2. Justification: Why remediation is not immediately possible
  3. Mitigation: Compensating controls in place to reduce risk
  4. Review Date: Mandatory review date (maximum 90 days)
  5. Approval: Security team approval required
Current Trivy IaC exceptions are tracked in .trivyignore.yaml with a scoped path, justification, and mandatory expiry date. This file is not a complete register for every class of accepted product risk.

​
Penetration Testing

CaseBender includes a penetration testing management module. This product capability does not demonstrate that CaseBender itself has completed an independent assessment. No completed third-party penetration-test report or retest letter was found during the July 2026 security review. The planned external scope includes tenant isolation, API authorization, integrations and SSRF, uploads and parsers, secrets, audit integrity, on-premise deployment, and container hardening. See Independent Penetration Test Scope for the proposed rules of engagement and required deliverables.

​
Engagement Management

  • Engagement Tracking: Schedule and track penetration testing engagements
  • Scope Definition: Define testing scope, rules of engagement, and authorized techniques
  • Finding Management: Track findings with severity, status, and remediation progress
  • Remediation SLAs: Findings must be remediated within severity-based SLAs

​
Remediation SLAs

​
License Compliance

​
Automated License Scanning

Every dependency’s license is checked automatically:
  • Blocked Licenses: GPL, AGPL, and other strong-copyleft licenses are blocked by default
  • Allowed Licenses: MIT, Apache 2.0, BSD, ISC, and other permissive licenses
  • Review Required: LGPL, uncommon, and unknown licenses require legal and distribution review
  • No License: Dependencies without a declared license are blocked
Exceptions are package-specific and must document their basis. The current policy recognizes lightGallery’s commercial dual license and sharp’s dynamically linked libvips binaries; it does not suppress those license identifiers for unrelated packages.

​
License Scanning Pipeline

Trivy performs license scanning as part of the security scan workflow:

​
Input Validation

CaseBender includes layered input-validation controls intended to reduce injection risk:

​
HTML Sanitization

  • Rich-text input paths should sanitize user-provided HTML before rendering
  • Allowlisted tags and attributes only
  • Script tags, event handlers, and data URIs are stripped

​
File Upload Validation

  • MIME type verification (not just extension checking)
  • Blocked extensions: .exe, .bat, .cmd, .ps1, .sh, .dll, .so
  • Maximum file size enforcement (configurable per upload type)
  • Evidence uploads have separate, stricter validation

​
URL Validation (SSRF Prevention)

  • External URLs are validated before any server-side requests
  • Private IP ranges (10.x, 172.16-31.x, 192.168.x, 127.x) are blocked
  • Internal hostnames and cloud metadata endpoints are blocked
  • DNS rebinding protection via pre-resolution validation

​
Request Sanitization

  • Null byte stripping from all string inputs
  • Unicode normalization to prevent homograph attacks
  • Zod schemas are used for API input validation
  • Prisma parameterized queries are preferred; any raw query requires focused review

​
Security Gate

All jobs required by the aggregate Security Gate must pass before code can be merged to the protected main branch:
The security gate is enforced through GitHub branch protection. Direct pushes are rejected when required checks are missing. Authorized repository administrators can change branch-protection policy; those governance changes are separate from a successful security result and should be reviewed through GitHub audit records.

​
Related Documentation