How seriously is your team actually treating code security in the testing phase, or is it all just shifted to DevSecOps?

[CalderMatt09]

Select Topic Area

Question

Body

The GitHub Advanced Security tooling has gotten genuinely good at catching known vulnerabilities in PRs but it still misses logic level security issues, broken access control, insecure direct object references, the stuff that needs a human thinking adversarially about the feature not just scanning for known CVEs.

QA teams that are doing this well are treating security scenarios like first class test cases, not an afterthought. Auth edge cases, privilege escalation paths, unexpected input handling, these should be in your test suite not just on a penetration tester's checklist once a quarter. Been tracking these separately in Tuskr recently just to get visibility into how much security coverage we actually have vs how much we assume we have. The gap is usually uncomfortable lol.

Curious how other teams are dividing this responsibility. Is security testing part of your QA process or does it live entirely outside it?

[M677871]

Security testing really should be shared, not dumped on one team. QA can cover abuse cases and permission issues, developers should build with security in mind, and AppSec should guide the higher-risk stuff.

Tools help, but they miss plenty. A lot of real problems come from bad assumptions, not missing scanners.

Tracking it separately makes sense to me. If nobody owns it clearly, it usually gets skipped.

[CalderMatt09]

Totally agree on tools. They help, but most issues come from assumptions that never get questioned. Having a separate way to track and review security work makes a big difference, especially when paired with something like Tuskr or Qase help to keep visibility and accountability in place.

Security works best when it’s shared, but still clearly owned. QA catching abuse paths, devs building defensively, and AppSec focusing on real risk areas is a solid balance.

[Aryan-Gore]

Security testing should be part of QA, not separate.

Best approach most teams follow:

QA handles security test cases (auth, edge cases, input validation, access control)
Devs ensure secure coding + reviews
Tools from GitHub Advanced Security catch known issues
Dedicated security/pen-test team handles deep audits occasionally

So it’s shared responsibility, but QA should treat security as first-class test coverage, not an afterthought.

[NipunKachwaha]

Security is no longer just being thrown over the fence to a pen-tester right before launch. QA teams are increasingly taking ownership of role-based access control (RBAC) and predictable adversarial paths.

The Focus: QA treats security requirements as standard acceptance criteria. If an application has different user privileges, QA is writing the automated test cases to ensure those boundaries hold.

In Practice: They aren't just checking if a React frontend successfully hides the "Delete Project" button from a standard user; they are actively testing the API endpoints to ensure the backend actively rejects an unauthorized request (catching those classic IDORs and broken access controls).

[PostoFisso]

From my experience working in Leonardo’s cyber SOC, I’ve noticed something similar but with a slightly different flavor. In a lot of organizations, the deeper security testing — the logic flaws, privilege escalation paths, broken access control — tends to fall on a handful of senior engineers or security‑minded developers. It’s not always a universal, structured QA responsibility. Sometimes it’s just “the older folks.. not juniors.

So I agree with you that treating these scenarios as first‑class test cases is the ideal, but in practice it often ends up concentrated in a small group rather than baked into the whole QA process.

Some teams integrate it well, others leave it to whoever has the most security intuition. It really varies.

And in some cases it’s also just a matter of workload. At places I’ve seen, especially in larger orgs or SOC environment, the volume of security‑related edge cases can be huge..

Smaller companies or teams without dedicated security engineers often outsource parts of it to external firms, or they just drop everything on one senior developer.