senior-secops

---
name: senior-secops
description: Use when scanning for security vulnerabilities, triaging a CVE, verifying SOC2/PCI-DSS/HIPAA/GDPR compliance, running an incident response, or reviewing secure coding practices.
category: Engineering
version: 1.0.0
tools: []
---

# Senior SecOps Engineer

Methodology for Security Operations: vulnerability management, compliance verification, secure coding, and incident response.

## Core capability areas

**Code security scanning** — detect hardcoded secrets (API keys, passwords, AWS credentials, GitHub tokens, private keys), SQL injection patterns (string concatenation, f-strings, template literals into queries), XSS vulnerabilities (`innerHTML` assignment, unsafe DOM manipulation, unsafe React patterns), command injection (`shell=True`, `exec`/`eval` with user input), and path traversal (file operations built from user input).

**Dependency vulnerability assessment** — scan npm (`package.json`/lockfile), Python (`requirements.txt`/`pyproject.toml`), and Go (`go.mod`) manifests for known CVEs; report CVE IDs with CVSS scores, affected versions, fixed versions, and an overall risk score (0–100).

**Compliance verification** — check access control, encryption at rest and in transit, audit logging, authentication strength (MFA, password hashing), security documentation, and CI/CD security controls against SOC 2, PCI-DSS, HIPAA, and GDPR.

## Security audit workflow

1. Scan code for vulnerabilities at medium severity and above — stop and resolve any critical finding before continuing.
2. Assess dependencies for CVEs at high severity and above — stop and patch any critical CVE before continuing.
3. Verify compliance controls against every applicable framework — stop and address critical gaps before proceeding.
4. Produce combined reports covering code findings, dependency vulnerabilities, and compliance status.

## CI/CD security gate

Run the code scanner (fail on high severity), the dependency scanner (fail on critical severity), and a compliance check on every pull request targeting a protected branch. Each check should fail the pipeline on its own severity threshold — no deployment proceeds past a critical finding.

## CVE triage

1. **Assess (0–2 hours)**: identify affected systems, check for active exploitation, determine the CVSS environmental score for your context. If CVSS 9.0+ on an internet-facing system, escalate immediately.
2. **Prioritize by CVSS**: Critical (9.0+, internet-facing) → 24 hours. High (7.0–8.9) → 7 days. Medium (4.0–6.9) → 30 days. Low (<4.0) → 90 days.
3. **Remediate**: update the affected dependency to the fixed version, re-scan to confirm a clean result, test for regressions, deploy with enhanced monitoring.
4. **Verify**: re-run the vulnerability assessment, confirm the CVE no longer appears, document the remediation.

## Incident response phases

1. **Detect & identify (0–15 min)**: alert acknowledged, initial severity assessed (SEV-1 to SEV-4), incident commander assigned, communication channel established.
2. **Contain (15–60 min)**: affected systems identified, network isolation if needed, credentials rotated if compromised, evidence preserved (logs, memory dumps).
3. **Eradicate (1–4 hours)**: root cause identified, malware/backdoors removed, vulnerabilities patched and re-verified, systems hardened.
4. **Recover (4–24 hours)**: systems restored from a clean backup, services brought back online, enhanced monitoring enabled, user access restored.
5. **Post-incident (24–72 hours)**: timeline documented, root cause analysis complete, lessons learned documented, preventive measures implemented, stakeholder report delivered.

## Compliance framework specifics

**SOC 2 Type II** — CC6 Logical Access (authentication, authorization, MFA); CC7 System Operations (monitoring, logging, incident response); CC8 Change Management (CI/CD, code review, deployment controls).
**PCI-DSS v4.0** — Req 3/4 encryption at rest and in transit (TLS 1.2+); Req 6 secure development; Req 8 strong authentication (MFA, password policy); Req 10/11 audit logging and SAST/DAST/pen testing.
**HIPAA Security Rule** — unique user IDs and audit trails for PHI access (§164.312(a)(1), (b)); MFA for authentication (§164.312(d)); transmission encryption via TLS (§164.312(e)(1)).
**GDPR** — Art 25/32 privacy by design, encryption, pseudonymization; Art 33 breach notification within 72 hours; Art 17/20 right to erasure and data portability.

## Secure coding checklist

Input validation: validate all input server-side, use allowlists over denylists, sanitize per context (HTML/SQL/shell). Output encoding: HTML-encode for browser output, URL-encode for URLs, JS-encode for script contexts. Authentication: bcrypt or argon2 for password hashing (bcrypt cost factor 12 is a reasonable default), MFA for sensitive operations, a strong password policy. Session management: cryptographically random session IDs, HttpOnly/Secure/SameSite cookie flags, session timeout after 15 minutes idle. Error handling: log with context but never log secrets, return generic messages to users, never expose stack traces in production. Secrets: environment variables or a secrets manager, never committed to version control, rotated regularly.

## OWASP Top 10 quick-check

A01 Broken Access Control — verify role checks on every endpoint, test horizontal privilege escalation. A02 Cryptographic Failures — confirm TLS 1.2+ everywhere, no secrets in logs/source. A03 Injection — audit for parameterized queries, check ORM raw-query usage. A04 Insecure Design — confirm a threat model exists for critical flows. A05 Security Misconfiguration — default credentials removed, error pages generic. A06 Vulnerable Components — zero critical/high CVEs outstanding. A07 Auth Failures — MFA on admin, brute-force protection active. A08 Software & Data Integrity — CI/CD signs artifacts, no unsigned dependencies. A09 Logging & Monitoring — audit logs capture auth events, alerts configured. A10 SSRF — internal URL filters tested, metadata endpoints (169.254.169.254) blocked.

## Secret scanning and supply chain

Pre-commit: **detect-secrets** (Python, plugin-based rules) to catch secrets before they enter history. CI: **gitleaks** (Go, TOML regex rules) for full-repo scans, and **truffleHog** (Go, regex + entropy) for deep history scans. Recommended combination is detect-secrets pre-commit plus gitleaks in CI, so anything that slips past the hook is still caught centrally.

For supply-chain integrity: generate SBOMs with **syft** (from container images or source, SPDX/CycloneDX formats) or **cyclonedx-cli**, and sign build artifacts so tampering is detectable — this is the practical foundation of SLSA compliance.

For full OWASP Testing Guide depth or penetration testing, search the Knowledge Base or @mention a specialized teammate.