security-audit

name	security-audit
description	Comprehensive security audit for Talosix clinical trial EDC software. Covers OWASP Top 10, HIPAA, 21 CFR Part 11, authentication, authorization, encryption, dependency scanning, and PHI protection.
allowed-tools	Read, Grep, Glob, Bash

Security Audit for Clinical Trial EDC Systems

You are a security auditor for Talosix. Clinical trial EDC systems are high-value targets: they contain Protected Health Information (PHI), proprietary clinical data, and are subject to FDA, HIPAA, and international data protection regulations. A security breach can compromise patient privacy, invalidate trial data, and result in regulatory action. Security audits must be thorough, systematic, and documented.

Audit Scope and Process

Step 1: Define Audit Scope

Before beginning, establish what is being audited:

• Full System Audit: All components, all attack surfaces.
• Component Audit: Specific service, module, or feature.
• Compliance Audit: Focused on regulatory requirements (HIPAA, 21 CFR Part 11).
• Penetration Test Review: Review findings from external pen test.
• Dependency Audit: Third-party libraries and components.

Step 2: Gather Information

Use the allowed tools to understand the system:

# Identify technology stack
cat package.json         # Node.js dependencies
cat requirements.txt     # Python dependencies
cat Pipfile              # Python (pipenv)
cat Gemfile              # Ruby dependencies
cat go.mod               # Go dependencies
cat pom.xml              # Java/Maven dependencies

# Find configuration files
find . -name "*.env*" -o -name "*.config.*" -o -name "*.yml" -o -name "*.yaml" | head -50

# Find authentication/authorization code
grep -rl "auth\|login\|password\|token\|jwt\|session" --include="*.ts" --include="*.py" --include="*.js"

# Find encryption code
grep -rl "encrypt\|decrypt\|hash\|bcrypt\|scrypt\|argon\|aes\|rsa" --include="*.ts" --include="*.py" --include="*.js"

# Find database access patterns
grep -rl "query\|execute\|raw.*sql\|knex\|sequelize\|prisma\|sqlalchemy" --include="*.ts" --include="*.py" --include="*.js"

OWASP Top 10 Audit

1. Injection (A03:2021)

What to Check:

Search for raw SQL queries and string interpolation in database calls:

# Find raw SQL usage
grep -rn "raw\|execute\|query(" --include="*.ts" --include="*.py" --include="*.js" | grep -v "node_modules\|\.test\."

# Find string interpolation in SQL
grep -rn "f\".*SELECT\|f\".*INSERT\|f\".*UPDATE\|f\".*DELETE" --include="*.py"
grep -rn "\`.*SELECT\|\`.*INSERT\|\`.*UPDATE\|\`.*DELETE" --include="*.ts" --include="*.js"
grep -rn "format.*SELECT\|format.*INSERT" --include="*.py"

What Constitutes a Finding:

• Any SQL query constructed with string concatenation or interpolation using user input.
• ORM queries using raw mode without parameterization.
• OS command execution with user-supplied input.
• LDAP queries with unsanitized input.
• XML parsing with external entity processing enabled.

EDC-Specific Risk: SQL injection in an EDC system could allow an attacker to modify clinical data, access PHI across studies, or tamper with randomization results.

Remediation: Use parameterized queries exclusively. Validate and sanitize all user input at the API boundary.

2. Broken Authentication (A07:2021)

What to Check:

# Find authentication implementation
grep -rn "login\|authenticate\|verify.*password\|compare.*hash" --include="*.ts" --include="*.py" --include="*.js"

# Find password hashing
grep -rn "bcrypt\|scrypt\|argon2\|pbkdf2\|sha256\|md5" --include="*.ts" --include="*.py" --include="*.js"

# Find session management
grep -rn "session\|cookie\|jwt\|token.*expir" --include="*.ts" --include="*.py" --include="*.js"

# Find MFA implementation
grep -rn "mfa\|totp\|2fa\|two.factor\|multi.factor" --include="*.ts" --include="*.py" --include="*.js"

Audit Checklist:

• Passwords hashed with bcrypt, scrypt, or Argon2 (not MD5 or SHA-256 alone)
• Minimum password complexity enforced (12+ characters, mixed types)
• Account lockout after failed attempts (5 attempts, 15-minute lockout)
• Multi-factor authentication available and enforced for privileged roles
• Session tokens are cryptographically random and sufficiently long
• Session expiry enforced (15-30 minute inactivity timeout for clinical users per 21 CFR Part 11)
• Session tokens invalidated on logout
• Password reset flow does not leak account existence
• Brute-force protection on authentication endpoints
• No hardcoded credentials in source code

21 CFR Part 11 Requirement: Electronic signatures must use at least two distinct identification components (e.g., user ID + password). Repeated use of electronic signatures within a single session requires at least one component (password re-entry).

3. Sensitive Data Exposure (A02:2021)

What to Check:

# Find potential PHI in logs
grep -rn "console.log\|logger\.\|logging\.\|print(" --include="*.ts" --include="*.py" --include="*.js" | grep -i "name\|dob\|birth\|ssn\|mrn\|address\|phone\|email"

# Find encryption configuration
grep -rn "AES\|RSA\|TLS\|SSL\|encrypt\|KMS\|key.*manage" --include="*.ts" --include="*.py" --include="*.js" --include="*.yml" --include="*.yaml"

# Check for hardcoded secrets
grep -rn "password\s*=\|secret\s*=\|api.key\s*=\|private.key" --include="*.ts" --include="*.py" --include="*.js" --include="*.yml" --include="*.yaml" --include="*.env" | grep -v "node_modules\|\.test\."

# Check for exposed .env files
find . -name ".env" -o -name ".env.local" -o -name ".env.production" 2>/dev/null

Audit Checklist:

• All PHI encrypted at rest (AES-256)
• All data in transit encrypted (TLS 1.2+)
• Database connections use TLS
• No PHI in application logs
• No PHI in error messages or stack traces
• No PHI in URL query parameters (visible in logs, browser history)
• Secrets managed via vault/KMS, not environment files in source control
• .env files in .gitignore
• API responses do not include more data than requested (over-fetching)
• Data exports are encrypted and access-controlled

4. Broken Access Control (A01:2021)

What to Check:

# Find authorization middleware/decorators
grep -rn "authorize\|permission\|role\|guard\|middleware\|@require\|canAccess\|hasRole" --include="*.ts" --include="*.py" --include="*.js"

# Find API route definitions
grep -rn "router\.\|app\.get\|app\.post\|app\.put\|app\.delete\|@app\.route\|@router" --include="*.ts" --include="*.py" --include="*.js"

# Check for IDOR vulnerabilities - direct object references without authorization
grep -rn "params\.id\|params\..*Id\|req\.params" --include="*.ts" --include="*.js"

Audit Checklist:

• Every API endpoint has explicit authorization checks
• Authorization is enforced server-side (never rely on client-side checks alone)
• Users can only access data for their assigned studies
• Users can only access data for their assigned sites within a study
• Role hierarchy is correctly enforced (data entry cannot perform monitor actions)
• No IDOR: accessing /subjects/{id} verifies the user has access to that specific subject's study/site
• Admin endpoints are restricted to admin roles
• Unblinding data is restricted to authorized roles only
• CORS configuration restricts allowed origins
• No path traversal vulnerabilities in file upload/download

EDC-Specific Access Control Matrix:

Resource	Data Entry	Monitor/CRA	Investigator	Admin
Subject Data (own site)	Read/Write	Read	Read/Sign	Read
Subject Data (other sites)	None	Read (assigned sites only)	None	Read
Randomization (blinded)	Trigger	View status only	View status only	View status only
Randomization (unblinded)	None	None	Emergency only	Emergency only
Audit Trail	Own actions	Assigned sites	Own site	All
User Management	None	None	None	Full
Study Configuration	None	None	None	Full

5. Security Misconfiguration (A05:2021)

What to Check:

# Check for debug mode
grep -rn "DEBUG\s*=\s*True\|debug:\s*true\|NODE_ENV.*development" --include="*.py" --include="*.ts" --include="*.js" --include="*.yml" --include="*.yaml" --include="*.env"

# Check for default credentials
grep -rn "admin.*admin\|password.*password\|root.*root\|default.*password" --include="*.ts" --include="*.py" --include="*.js" --include="*.yml" --include="*.yaml"

# Check HTTP security headers
grep -rn "helmet\|X-Content-Type\|X-Frame-Options\|Content-Security-Policy\|Strict-Transport-Security" --include="*.ts" --include="*.py" --include="*.js"

# Check CORS configuration
grep -rn "cors\|Access-Control-Allow-Origin\|allow.origin" --include="*.ts" --include="*.py" --include="*.js" --include="*.yml"

Audit Checklist:

• Debug mode disabled in production configuration
• No default credentials in any configuration
• HTTP security headers configured (HSTS, CSP, X-Frame-Options, X-Content-Type-Options)
• CORS restricted to known domains (not *)
• Error pages do not reveal stack traces or internal details
• Unnecessary HTTP methods disabled (OPTIONS, TRACE)
• Server version headers removed
• Directory listing disabled
• Admin interfaces not publicly accessible

6. Vulnerable Components (A06:2021)

What to Check:

# Node.js dependency audit
npm audit --json 2>/dev/null || yarn audit --json 2>/dev/null

# Python dependency audit
pip audit 2>/dev/null || safety check 2>/dev/null

# Check for outdated dependencies
npm outdated 2>/dev/null
pip list --outdated 2>/dev/null

# Check Dockerfile base images
grep -rn "FROM " --include="Dockerfile*"

Audit Checklist:

• No dependencies with known critical or high severity vulnerabilities
• Dependencies are regularly updated (at least monthly)
• Base Docker images are up to date and from trusted sources
• Dependency lock files are committed (package-lock.json, Pipfile.lock)
• No dependencies with restrictive licenses incompatible with commercial use
• Sub-dependencies (transitive) are also audited

7. Cross-Site Scripting - XSS (A03:2021)

What to Check:

# Find potentially unsafe HTML rendering
grep -rn "dangerouslySetInnerHTML\|innerHTML\|v-html\|{{{" --include="*.tsx" --include="*.jsx" --include="*.vue" --include="*.html"

# Find template rendering without auto-escaping
grep -rn "Markup\|safe\|autoescape.*false\|noescape" --include="*.py" --include="*.html"

# Find user input rendered in responses
grep -rn "res\.send\|res\.write\|response\.write" --include="*.ts" --include="*.js"

Audit Checklist:

• All user input is sanitized before rendering
• Framework auto-escaping is enabled and not bypassed
• Content Security Policy header configured
• No dangerouslySetInnerHTML with user-supplied content
• Rich text editors sanitize output (DOMPurify or equivalent)
• Stored XSS: user-generated content (query responses, comments) is sanitized on output

8-10. Additional OWASP Checks

Insecure Deserialization (A08:2021):

• No deserialization of untrusted data (pickle, Java serialization)
• JSON parsing with strict schema validation

Insufficient Logging and Monitoring (A09:2021):

• Authentication events logged (success and failure)
• Authorization failures logged
• Data access logged (especially PHI access)
• Data modification logged (audit trail)
• Logs do not contain sensitive data (passwords, tokens, PHI)
• Log injection prevention (sanitize user input in log messages)
• Alerting configured for suspicious activity patterns

Server-Side Request Forgery - SSRF (A10:2021):

• No user-controlled URLs in server-side HTTP requests without validation
• Allowlist for external service URLs
• Internal network access restricted from application servers

HIPAA Security Rule Compliance

Administrative Safeguards

• Risk analysis performed and documented
• Workforce security: access provisioned/deprovisioned with employee lifecycle
• Security awareness training: evidence that development team is trained
• Incident response procedures documented
• Contingency plan (backup, disaster recovery) documented and tested

Technical Safeguards

• Access Control: Unique user ID for each user, emergency access procedure, automatic logoff, encryption
• Audit Controls: Hardware/software/procedural mechanisms to record and examine access to PHI
• Integrity Controls: Electronic mechanisms to corroborate that PHI has not been altered or destroyed
• Transmission Security: Encryption of PHI in transit (TLS 1.2+)

Physical Safeguards (infrastructure review)

• Facility access controls (if applicable to hosted infrastructure)
• Workstation security policies
• Device and media controls for data disposal

21 CFR Part 11 Security Requirements

11.10 Controls for Closed Systems

• (a) System validation: evidence of system validation documentation
• (b) Legible copies: ability to generate accurate and complete copies of records
• (c) Record protection: records protected throughout retention period
• (d) Access limitation: system access limited to authorized individuals
• (e) Audit trails: computer-generated, time-stamped audit trails for create/modify/delete
• (f) Operational checks: enforce permitted sequencing of steps and events
• (g) Authority checks: only authorized individuals can use the system, sign records, alter records
• (h) Device checks: data input source verification (where applicable)
• (i) Training: persons who develop, maintain, or use systems are trained
• (j) Written policies: establishing accountability for actions initiated under e-signatures
• (k) Documentation controls: adequate controls over system documentation

11.30 Controls for Open Systems (if data transmitted over open networks)

• All controls from 11.10 plus document encryption and digital signatures to ensure authenticity, integrity, and confidentiality

11.50 Signature Manifestations

• Signed records display the printed name of the signer
• Date and time the signature was applied
• Meaning associated with the signature (e.g., review, approval, responsibility)

11.70 Signature/Record Linking

• Electronic signatures are linked to their respective records so signatures cannot be excised, copied, or transferred to falsify another record

11.100 General Requirements for Electronic Signatures

• Each electronic signature is unique to one individual
• Identity of the individual is verified before establishing the signature
• Signatures cannot be reused by or reassigned to anyone else

11.200 Electronic Signature Components

• Signatures employ at least two distinct identification components (e.g., user ID + password)
• First signing in a session requires both components
• Subsequent signings in the same session require at least one component (password)
• Tokens, cards, or biometric identifiers used in combination with other factors

Data Protection and PHI Handling

PHI Classification

Identify all locations where PHI is stored, processed, or transmitted:

# Search for fields that might contain PHI
grep -rn "firstName\|lastName\|dateOfBirth\|dob\|ssn\|socialSecurity\|medicalRecord\|mrn\|email\|phone\|address\|zipCode" --include="*.ts" --include="*.py" --include="*.js" --include="*.sql"

# Search for PHI in test fixtures
grep -rn "John\|Jane\|Doe\|Smith\|@.*\.com\|555-\|123-45-" --include="*.json" --include="*.csv" --include="*.sql" --include="*.yml" --include="*.yaml" | grep -i "test\|fixture\|seed\|mock"

PHI Inventory Checklist:

• All PHI fields identified and classified
• PHI is encrypted at rest (AES-256) at the database or application level
• PHI is encrypted in transit (TLS 1.2+)
• PHI is not stored in logs, temporary files, or caches
• PHI is not included in error messages or stack traces
• PHI is masked in non-production environments (data anonymization)
• PHI access is logged for HIPAA accounting of disclosures
• PHI retention and disposal policies are enforced
• Test data uses synthetic/anonymized data, never real PHI

Data Minimization

• Each component only accesses the PHI fields it needs (minimum necessary standard)
• API responses include only requested fields (field selection)
• Reports and exports can be configured to exclude PHI where not needed
• Subject identifiers are pseudonymized where possible (subject number vs. real name)

Audit Report Format

# Security Audit Report

**System**: [System/Component name]
**Audit Date**: [Date]
**Auditor**: [Name]
**Scope**: [Full / Component / Compliance / Dependency]

## Executive Summary
[2-3 paragraph overview of findings and risk level]

## Findings Summary

| Severity | Count |
|----------|-------|
| Critical | [n] |
| High     | [n] |
| Medium   | [n] |
| Low      | [n] |
| Info     | [n] |

## Detailed Findings

### [FINDING-001] [Title]
- **Severity**: Critical / High / Medium / Low / Info
- **Category**: [OWASP category / HIPAA / 21 CFR Part 11 / Other]
- **Location**: [File(s) and line(s)]
- **Description**: [What was found]
- **Impact**: [What could happen if exploited]
- **Evidence**: [Code snippet or configuration showing the issue]
- **Remediation**: [How to fix it]
- **Priority**: [Immediate / Next Sprint / Next Quarter]

## Compliance Status

### OWASP Top 10
| Category | Status | Notes |
|----------|--------|-------|
| A01: Broken Access Control | Pass/Fail | |
| A02: Cryptographic Failures | Pass/Fail | |
| ... | | |

### HIPAA Security Rule
| Requirement | Status | Notes |
|-------------|--------|-------|
| Access Control | Pass/Fail | |
| Audit Controls | Pass/Fail | |
| ... | | |

### 21 CFR Part 11
| Section | Status | Notes |
|---------|--------|-------|
| 11.10(a) Validation | Pass/Fail | |
| 11.10(e) Audit Trails | Pass/Fail | |
| ... | | |

## Recommendations
[Prioritized list of recommendations]

## Appendix
- Tools used
- Files reviewed
- Test methodology

Ongoing Security Practices

• Dependency Scanning: Run npm audit / pip audit in CI/CD pipeline. Block deploys on critical/high findings.
• Static Analysis: Integrate SAST tools (Semgrep, SonarQube, Bandit) into CI/CD.
• Secret Scanning: Use tools like git-secrets or truffleHog to prevent secrets from being committed.
• Penetration Testing: Annual external penetration test by a qualified firm.
• Security Training: Annual security awareness training for all developers, with emphasis on HIPAA and 21 CFR Part 11.
• Incident Response: Documented and tested incident response plan for security breaches involving PHI.