Q24 of 24 · Security

How do you define a security testing strategy that integrates QA with the dedicated security team?

SecurityLeadsecuritystrategyleadershipgovernancepenetration-testingthreat-modellinglead

Short answer

Short answer: Define clear lanes: QA owns preventive security testing (OWASP Top 10 coverage, SAST/SCA in CI, functional security tests per feature). The security team owns threat modelling, penetration testing, and incident response. Create a shared defect classification for consistent severity and SLA. QA engineers attend threat modelling sessions to translate findings into test cases.

Detail

The failure mode in most organisations is one of two extremes: QA does no security testing at all ("that's the security team's job") or QA tries to do penetration testing without the skills for it. The right model has clear lanes with explicit integration points.

QA owns:

  • Security test cases derived from each feature's threat model (written by the security team, translated into test steps by QA)
  • SAST and SCA tooling in the CI pipeline — configuration, threshold decisions, and triage of findings
  • Functional negative security tests: OWASP Top 10 test cases, cookie flag checks, header checks, input validation, access control checks
  • Regression tests for every security defect found in penetration tests or production incidents

Security team owns:

  • Threat modelling for new features and architecture changes
  • Annual or pre-release penetration testing (external or internal red team)
  • Vulnerability management programme (SLAs for CVE remediation)
  • Incident response, forensics, and post-incident analysis

Integration points:

  • Threat model → test cases: QA engineers attend or review threat modelling output for every significant feature. Each threat in the model generates at least one security test case.
  • Pen test → regression suite: after each pen test, the findings are triaged with QA. The QA team writes regression tests for each confirmed finding so it doesn't recur.
  • Shared severity taxonomy: use a single severity scale (aligned to CVSS or a company standard) so a "High" severity finding from a pen test maps to the same SLA as a "High" from QA's test suite.

What QA is not responsible for: QA cannot be the last line of defence for security. The strategy document should explicitly state that QA testing supplements, not replaces, secure development practices (code review, SAST, threat modelling) and the security team's specialist testing.

// WHAT INTERVIEWERS LOOK FOR

Clear lane separation with specific activities per team. Names the integration points (threat model → test cases, pen test → regression). Explicitly states QA's scope limitations — not the last line of defence.