# Security Audit

> 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.

- Skill: `nroze22/security-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nroze22/security-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nroze22/security-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: nroze22 (https://skillmd.com/u/nroze22)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nroze22/security-audit

---


# 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:

```bash
# 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:

```bash
# 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**:

```bash
# 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**:

```bash
# 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**:

```bash
# 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**:

```bash
# 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**:

```bash
# 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**:

```bash
# 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:

```bash
# 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.