Security Engineer (AppSec)
Own application security across an AI-enabled healthcare marketplace. You'll design privacy-by-design controls, build a secure SDLC, threat-model new features (including AI features), and partner with product teams to ship fast and safely.
On This Page
Role Overview
AppSec ownership
Define and drive the application security program for patient, provider, and internal apps/APIs; build pragmatic, developer-friendly controls.
Threat modeling
Structured models for new features (incl. AI/RAG/search, payments, messaging), covering authn/z, data flows, third parties, and abuse cases.
Privacy by design
Enforce data minimization, purpose limitation, strong encryption, least privilege, and clear PHI boundary (no PHI to non-compliant endpoints).
Developer enablement
Templates, secure defaults, linters, and quick paths to fix. Opinionated guidance beats policy-only approaches.
| Area | Summary |
|---|---|
| AppSec ownership | Define and drive the application security program for patient, provider, and internal apps/APIs; build pragmatic, developer-friendly controls. |
| Threat modeling | Structured models for new features (incl. AI/RAG/search, payments, messaging), covering authn/z, data flows, third parties, and abuse cases. |
| Privacy by design | Enforce data minimization, purpose limitation, strong encryption, least privilege, and clear PHI boundary (no PHI to non-compliant endpoints). |
| Developer enablement | Templates, secure defaults, linters, and quick paths to fix. Opinionated guidance beats policy-only approaches. |
Core Security Domains
Authentication & Authorization
Focus: Modern auth (OIDC/OAuth2), session mgmt, step-up auth for sensitive actions.
Examples: Rotate secrets, short tokens, hardened cookies, RBAC/ABAC, JTI revocation.
Input/Output Handling
Focus: Injection prevention, SSRF/XSS/XXE defenses, content sanitization.
Examples: Centralized encoders, CSP, template auto-escape, signed URLs.
Data Protection
Focus: Encrypt at rest & transit, KMS/HSM, key rotation, field-level encryption for sensitive PII/PHI.
Examples: TLS 1.2+, KMS CMKs, envelope encryption, tokenization/pseudonymization.
Secrets & CI/CD
Focus: Secret scanning, sealed secrets, workload identity, build integrity.
Examples: SBOM, provenance attestations, SLSA concepts, branch protections.
Third Parties & SaaS
Focus: Vendor risk, DPA/BAA checks, least data sharing, key escrow.
Examples: Scopes per integration, signed webhooks, egress allow-lists.
Abuse & Fraud
Focus: Rate limits, anomaly detection, anti-automation, account take-over defenses.
Examples: Device signals, captcha alternatives, velocity and behavior models.
| Domain | Focus | Examples |
|---|---|---|
| Authentication & Authorization | Modern auth (OIDC/OAuth2), session mgmt, step-up auth for sensitive actions. | Rotate secrets, short tokens, hardened cookies, RBAC/ABAC, JTI revocation. |
| Input/Output Handling | Injection prevention, SSRF/XSS/XXE defenses, content sanitization. | Centralized encoders, CSP, template auto-escape, signed URLs. |
| Data Protection | Encrypt at rest & transit, KMS/HSM, key rotation, field-level encryption for sensitive PII/PHI. | TLS 1.2+, KMS CMKs, envelope encryption, tokenization/pseudonymization. |
| Secrets & CI/CD | Secret scanning, sealed secrets, workload identity, build integrity. | SBOM, provenance attestations, SLSA concepts, branch protections. |
| Third Parties & SaaS | Vendor risk, DPA/BAA checks, least data sharing, key escrow. | Scopes per integration, signed webhooks, egress allow-lists. |
| Abuse & Fraud | Rate limits, anomaly detection, anti-automation, account take-over defenses. | Device signals, captcha alternatives, velocity and behavior models. |
AI Security & Guardrails
Secure AI by default
Our AI features must be safe, privacy-preserving, and resilient to prompt-level and supply-chain attacks. Simpler non-AI solutions are preferred where they outperform or reduce risk.
- Threat-model AI surfaces: prompt injection, data exfiltration, jailbreaks, model/embedding poisoning, supply chain of providers and datasets.
- Guardrails: retrieval over generation for sensitive flows, allow-lists, output filters, role-separated contexts, and human-in-the-loop for risky actions.
- Data boundary: no PHI or consumer health data to non-approved LLM endpoints; use vetted providers/regions and signed BAAs where required.
- Evaluation: offline eval sets, red-teaming, and regression gates before rollout; monitor drift, latency, and cost.
- Observability: structured logs with redaction, privacy-preserving telemetry, and differential alerting for anomalies.
Compliance note
HIPAA boundary, state consumer health privacy (e.g., WA "My Health My Data"), CPRA/CPPA and GDPR principles apply to model inputs/outputs and storage.
Secure SDLC & Toolchain
Design
Security activities: Threat models, data-flow diagrams, privacy impact checks, crypto decisions.
Tooling: Architectural RFCs, STRIDE, data catalogs, key mgmt runbooks.
Build
Security activities: Secure frameworks, dependency hygiene, secrets mgmt, parameterized queries.
Tooling: SBOM, Dependabot/Renovate, KMS, IAM roles, secret scanners.
Test
Security activities: SAST/DAST/IAST, unit/contract tests incl. security assertions, fuzzing.
Tooling: Static analyzers, container scanners, ZAP/Burp, fuzzers.
Release
Security activities: Signed builds, policy gates, change approvals, staged rollouts.
Tooling: CI attestations, OPA/Conftest, deploy diff checks.
Operate
Security activities: Runtime protections, WAF, IDS/IPS, secrets rotation, backup/restore tests.
Tooling: WAF/CDN, CSP, SIEM, EDR, KMS rotation jobs, chaos drills.
| Stage | Security activities | Tooling (illustrative) |
|---|---|---|
| Design | Threat models, data-flow diagrams, privacy impact checks, crypto decisions. | Architectural RFCs, STRIDE, data catalogs, key mgmt runbooks. |
| Build | Secure frameworks, dependency hygiene, secrets mgmt, parameterized queries. | SBOM, Dependabot/Renovate, KMS, IAM roles, secret scanners. |
| Test | SAST/DAST/IAST, unit/contract tests incl. security assertions, fuzzing. | Static analyzers, container scanners, ZAP/Burp, fuzzers. |
| Release | Signed builds, policy gates, change approvals, staged rollouts. | CI attestations, OPA/Conftest, deploy diff checks. |
| Operate | Runtime protections, WAF, IDS/IPS, secrets rotation, backup/restore tests. | WAF/CDN, CSP, SIEM, EDR, KMS rotation jobs, chaos drills. |
Incident Readiness & Detection
Readiness
- Runbooks for P0/P1, on-call rotations, and comms templates (legal & comms reviewed).
- Table-top exercises incl. AI data exfil drills and third-party compromise scenarios.
- Backups, restore validation, and breach notification decision trees.
Detection
- Structured logs, anomaly detection, and privacy-preserving telemetry.
- Alerting on auth anomalies, permission escalations, and egress deviations.
- Playbooks for credential stuffing and ATO mitigation.
Success Metrics
Mean time to remediate (MTTR)
Definition: Avg. time to fix high/critical vulns from discovery to prod.
Guardrails: Prioritize exploitable issues; avoid "dashboard chasing."
Defect escape rate
Definition: % security issues found post-release vs. pre-release.
Guardrails: No slowdown on critical product delivery.
Secrets exposure
Definition: Count and dwell time of secrets in code/logs.
Guardrails: Time-bound rotation SLAs; verify revocation.
AI guardrail efficacy
Definition: Red-team pass rate, prompt-injection block rate, eval regressions.
Guardrails: No PHI egress; latency/cost within SLOs.
| Metric | Definition | Guardrails |
|---|---|---|
| Mean time to remediate (MTTR) | Avg. time to fix high/critical vulns from discovery to prod. | Prioritize exploitable issues; avoid "dashboard chasing." |
| Defect escape rate | % security issues found post-release vs. pre-release. | No slowdown on critical product delivery. |
| Secrets exposure | Count and dwell time of secrets in code/logs. | Time-bound rotation SLAs; verify revocation. |
| AI guardrail efficacy | Red-team pass rate, prompt-injection block rate, eval regressions. | No PHI egress; latency/cost within SLOs. |
Requirements
Must-have
- • 4+ years in AppSec or security engineering with shipped impact at product velocity.
- • Hands-on with threat modeling, code review, and SAST/DAST/container scanning.
- • Cloud security (IAM least privilege, KMS, network egress controls, secrets).
- • Pragmatic risk judgment; excellent written communication with engineers & product.
- • US work authorization; ability to participate in on-call rotation.
Nice-to-have
- • Experience securing AI/RAG systems, model evals, and guardrails.
- • Healthcare context (HIPAA boundary awareness) or SOC 2 / ISO 27001 exposure.
- • Abuse/fraud prevention, WAF/CDN tuning, or secure payments experience.
- • Certs (e.g., OSCP, GWAPT, CSSLP) welcome but not required.
| Must-have | Nice-to-have |
|---|---|
|
|
Hiring Process
1) Apply
2–5 business daysResume/CV + short note on an AppSec win and an AI security/guardrail choice you made.
2) Screen
~1 week30 min on AppSec judgment, trade-offs, and collaboration style.
3) Deep dive
~1 weekThreat-model exercise (includes an AI feature); code review or design critique.
4) Practical
3–7 daysTime-boxed hands-on (or prior work walkthrough) covering SDLC/tooling and guardrails.
5) Panel
~1 weekCross-functional interviews with Product/Eng/Legal; privacy & safety scenarios.
6) Offer
48–72 hoursComp band, benefits, start date. Background check post-offer where lawful.
| Step | What to expect | Typical time |
|---|---|---|
| 1) Apply | Resume/CV + short note on an AppSec win and an AI security/guardrail choice you made. | 2–5 business days |
| 2) Screen | 30 min on AppSec judgment, trade-offs, and collaboration style. | ~1 week |
| 3) Deep dive | Threat-model exercise (includes an AI feature); code review or design critique. | ~1 week |
| 4) Practical | Time-boxed hands-on (or prior work walkthrough) covering SDLC/tooling and guardrails. | 3–7 days |
| 5) Panel | Cross-functional interviews with Product/Eng/Legal; privacy & safety scenarios. | ~1 week |
| 6) Offer | Comp band, benefits, start date. Background check post-offer where lawful. | 48–72 hours |
Accommodation requests: email care@clinicbooking.com with subject "Interview Accommodation".
Apply
Email your application with your resume/CV and 1–2 concrete examples (before/after) of issues you prevented or remediated. If available, include a sanitized threat model or security RFC.
Apply NowNotices
- Equal Opportunity: We welcome applicants of all backgrounds and do not discriminate on any protected basis.
- Right to work & export: US work authorization required; export-control compliance may apply to some roles/tools.
- Privacy: Your data is handled per our Applicant/Candidate Privacy Notice and Records Retention Summary.
Owner/Operator: Spyface Tech Company, LLC (d/b/a "ClinicBooking"). Address: 30 N Gould St Ste N, Sheridan, WY 82801, USA · Contact: hello@spyface.com (corporate), care@clinicbooking.com (talent).