Why Testers Should Think Like Ethical Hackers: Lessons From WannaCry

Last updated: October 2026

Quick answer

Ransomware outbreaks such as WannaCry in 2017 showed that many breaches exploit known, preventable weaknesses: unpatched systems, weak access controls and insecure defaults. Testers are well placed to catch these early if they think like an attacker. Adding security checks to everyday testing, such as abusing inputs, testing authorization, verifying patches and dependencies and scanning in the CI/CD pipeline, makes security part of quality rather than an afterthought.

What WannaCry taught software teams

WannaCry spread in May 2017 through a Windows vulnerability for which a patch had been released weeks earlier. It encrypted data on hundreds of thousands of computers across the world and disrupted hospitals, manufacturers and public services. The lesson for software teams was not about one vulnerability: it was that known, fixable problems stay open when nobody checks for them.

Five reasons testers should think like ethical hackers

1. Testers already break things on purpose

Exploratory testers ask “what if?” all day. Extending that to “what if a malicious user tried this?” uncovers injection, privilege escalation and data exposure issues that functional tests miss.

2. Security bugs are cheapest to fix early

A missing authorization check found during a sprint takes minutes to fix. The same bug found after a breach costs incident response, customer trust and possibly regulatory penalties.

3. Most attacks target known weaknesses

Outdated dependencies, misconfigurations, default credentials and missing patches are common entry points. Checking for them can be routine and largely automated.

4. APIs and integrations widen the attack surface

Modern applications expose many APIs to browsers, mobile apps and partners. Testing their authentication, authorization and input handling is essential. See the OWASP API Security Top 10.

5. Security is part of the user experience

Users judge an application by whether their data is safe. Testers represent the user, and that includes protecting them.

Security checks testers can add today

• Input abuse: try script tags, SQL fragments, very long strings and unexpected types in every field and API parameter.
• Authorization: can user A see or change user B’s data by changing an ID in the URL or request?
• Authentication and sessions: lockout after failed logins, password reset flows, session timeouts and logout that actually ends the session.
• Sensitive data: no secrets or personal data in URLs, logs, error messages or client-side code.
• Dependencies and patches: run dependency and container scans in the pipeline and check that environments are patched.
• Security headers and HTTPS on every page.

Building security into your pipeline

Combine automated scans (static analysis, dependency checks and dynamic scans) in CI/CD with tester-led security checks on risky features, and regular penetration tests by specialists for high-risk systems. See shifting API security left.

How CloudQA can help

CloudQA automates the functional side of this work: regression tests for login, password reset, role-based access and session flows can run on every release and across environments, with API steps to check that protected endpoints reject unauthorized requests. Every run executes the same predefined steps, so security-relevant regressions are caught consistently. See CloudQA regression testing.