I've had this idea floating around in my head for a while, and never had the time to really test it out. Maybe someone else will?

For some time now, the security world has operated with the idea that security testing is a largely separate domain. We create security-specific checklists, execute separate security-specific testing tools, and often build out an entire separate security testing lifecycle.

Traditional thinking separates security testing from normal functional testing. Developers write tests to check whether a function executes correctly or an API returns the right data or whether a UI behaves as intended. Then security testing largely happens later in the development lifecycle, probing for vulnerabilities as a separate exercise.

But security bugs are just another category of bug. They’re often not special; they’re just triggered by adversarial inputs rather than normal usage. So why not address them using the same testing frameworks?

Security is not a bolt-on feature. It should be a property of how your system behaves under stress, manipulation, and misuse. If that’s true, then perhaps security testing should not be a standalone phase or separate consideration. What if a baseline of security testing could be woven into the same unit, integration, and end-to-end tests that developers already use to ensure quality?

Prioritize using your existing unit, integration, and end-to-end testing frameworks to cover security cases!

Imagine your normal test suite, but with security-specific scenarios woven throughout:

• Parameter tampering in your input validation tests
• Authentication bypasses in your session handling tests
• Insecure direct object reference checks in your access control tests
• Race conditions in your concurrency tests
• Privilege escalation attempts in role / permission handling
• Cross-site scripting tests for any rendered output
• Injection attacks (SQL, command, LDAP) to verify backend resilience
• Denial of service tests for overload scenarios
• Replay attacks against sensitive APIs
• Information leakage checks in error handling and logs

Security engineers should work alongside product engineers to identify and expand these scenarios. Instead of duplicating work in separate security test frameworks, we should extend existing tests to cover security edge cases.

There are some obvious potential benefits:

• Avoid redundancy. Why build a separate security testing suite when you can extend what’s already there? There's probably already been significant investment in existing test frameworks.
• Better coverage. Developers already know their systems’ weird edge cases. Adding security scenarios to those edge cases ensures broader coverage.
• Faster feedback. No more waiting for a security penetration test cycle. Security issues surface as part of normal development, and can be fixed before they make it into production.
• Improved collaboration. Security engineers and product engineers become partners, not independent operators. Knowledge gets shared and pooled, with potentially better outcomes alround.

Testing this approach out probably takes partnership.

What if the most efficient way to get real security testing coverage isn’t to build a separate security testing pipeline? What if it is better to partner closely with product engineers and extend the tests they’re already running?

Trying this out could be as simple as:

1. Have security engineers and product engineers pair together to review existing unit, integration, and end-to-end testing frameworks and test cases.
2. With your threat model in mind, they should identify opportunities to add new test cases that exercise security controls or test for security related concerns.
3. Use the same tools — your unit testing framework, your CI/CD pipelines — to run these extended tests.

We generally agree that security shouldn’t only be a completely separate phase — that it should be an integrated dimension of your broader quality efforts ("shift left", etc). This probably isn't an either-or but a both-and thing. Investing in adding security-specific coverage to existing testing frameworks seems like it could be a smart thing to do?