Share it, with clear roles. Developers write and maintain the regression test that ships with each fix. QA owns the overall suite, its coverage and its health. Security owns the list of abuse cases and reviews gaps. One named person should be accountable for the suite as a whole.
Why a single owner fails
If only QA owns it, tests drift away from the code and fixes ship without them. If only developers own it, nobody looks at coverage across features, and tests rot as people move teams. If only security owns it, the suite becomes a list of requests nobody builds.
A split works when each group owns the thing it is best placed to keep right.
A practical split
| Task | Primary owner | Others |
|---|---|---|
| Write the regression test with each fix | Developer who fixes it | QA reviews |
| Keep a list of abuse cases | Security | QA and product contribute |
| Decide which cases get automated | QA | Security advises |
| Keep tests fast, stable and in CI | QA | Developers fix flaky ones in their area |
| Track coverage against abuse cases | QA | Security reviews gaps |
| Triage failing security tests | Developer on call | QA helps reproduce |
| Retire tests for removed features | QA | Product confirms |
Rules that keep it working
- A security fix pull request is not complete without its regression test. Make this a review checklist item.
- Tests live in the same repository as the code they protect, so they change together.
- Each test names the ticket or abuse case it covers, so purpose is never a mystery.
- A failing security test blocks the merge. If a team wants to bypass that, it needs a recorded exception with an owner and an expiry.
- Flaky security tests are fixed or removed within an agreed time, because retries can hide real bugs.
What the accountable person does
One person, often a QA lead, does these things on a schedule:
- Reviews the table of abuse cases against the tests, looking for gaps.
- Looks at the slowest and flakiest tests.
- Checks that known failures marked as expected are still tracked and not forgotten.
- Reports a short summary each release: new tests added, gaps open, tests retired.
They do not write every test. They keep the system honest.
Small teams
With five engineers and no dedicated QA, the roles still exist. The developer who fixes writes the test, a second engineer reviews it, and one person is named as the keeper of the abuse case list. It can be a ten minute monthly review.
Metrics worth watching
Keep it simple. The count of abuse cases with no test. The age of expected failures. The number of security bugs that came back after being fixed. If the last number is above zero, look at why a regression test did not catch it.
Handoffs to avoid
Do not let a test sit in a QA only repository that developers never run. Do not let security hand a spreadsheet of findings to QA with no context. Do not let ownership live in one person's head, since people leave.
Write the split down in the team handbook, one page, and review it when the team changes.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a gate sits in the pull request, which is where the rule that a fix needs its test is enforced.
Safeguard offers policies and gates that can enforce rules like this in the pull request. The free scan is a quick way to see dependency findings first.
Quick check
Can security own the whole suite?
It rarely works. Security should own the abuse case list, while developers and QA own the tests that prove them.
Who fixes a flaky security test?
The team that owns the code under test, with QA helping to find the cause.
Last reviewed: 19 October 2026.
