QA should test the security behavior a story promises: who can do what, what happens with bad input, and whether old vulnerabilities stay fixed. That is ordinary test design applied to access rules and misuse. It does not require pen testing skills, and it catches problems automation alone misses.
What the framework asks of testing
NIST's Secure Software Development Framework treats testing of running code as a decision to make and document. Practice PW.8.1 asks organizations to decide whether executable code testing should be done and which types to use. PW.8.2 asks them to scope the tests, design them, run them, and record and triage every finding in the team's workflow or issue tracker.
Its examples are useful to a QA team: functional testing of security features, dynamic vulnerability testing as part of the test suite, tests for previously reported vulnerabilities so they do not come back, and fuzz testing for input handling.
The five test areas
| Area | Example test |
|---|---|
| Authorization | A user calls an endpoint for another user's record and gets a denial |
| Authentication | A reset link works once, and an expired session is refused |
| Input handling | Oversized, empty, malformed and unexpected types are rejected cleanly |
| Error behavior | Errors do not reveal stack traces, paths or internal names |
| Regression | Every past security bug has a test that fails if it returns |
Authorization first
Most serious web flaws are access mistakes. For each role, list what it should and should not do, then test the "should not" half. Use two test accounts and try each one's actions against the other's data.
Regression tests for old bugs
When a security bug is fixed, the fix is not done until a test proves it. That test stays in the suite. SSDF example PW.8.2 names this directly. Over time the suite becomes a record of lessons learned.
How to add it without slowing release
- Take the security acceptance criteria from each story and turn them into test cases.
- Add a short "misuse" section to the test plan template, with one or two abuse cases per feature.
- Run an automated dynamic scan against a test environment on a schedule, and triage results with the team.
- Record each finding as a ticket, with severity and the test that found it.
- Review the findings in the retrospective and add regression tests for any real issue.
Limits of what QA should do
- QA should not run attacks against production.
- QA should not test systems outside the project's scope without approval.
- QA findings need a clear owner, so they are fixed, not just logged.
A scanner does not replace this work. Automated tools find known classes of flaw but cannot know your business rules, such as "only the account owner may export this report". Testers who know the product catch those gaps.
Working with developers
Agree on a severity scale that testers and developers share, and on what blocks a release. A finding that has no agreed severity gets argued over at the worst time. Pair a tester with a developer for the first sprint of misuse testing, and both sides learn quickly.
Safeguard can run dependency scanning, SAST and web application scans, so findings land in one place for triage alongside test results. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a running-app scan reports a finding, and compare it to what a tester with product knowledge would also check by hand.
Quick check
Does QA need security training to start?
Basic training helps, but the first step is applying normal test design to access rules and bad input. Start with authorization tests using two accounts.
What is a security regression test?
A test that fails if a previously fixed vulnerability returns. Each fixed security bug should add one to the suite.
Sources
Last reviewed: 19 October 2026.
