Security Testing Fundamentals for Developers
- Contributor
- Mar 25
- 5 min read
Security testing has a reputation as something the security team does to you after you've shipped. In healthy teams, developers do most of the security testing themselves, with security teams catching what slips through. Done right, this catches issues weeks earlier and at much lower cost.
This guide is the fundamentals every developer should know.
The Layers
Security testing has roughly four layers:
Static analysis (SAST) — scanning source code for known vulnerability patterns
Dynamic analysis (DAST) — testing the running application from the outside
Dependency scanning — checking third-party libraries for known vulnerabilities
Penetration testing — humans actively trying to exploit the system
Each catches different things. A mature program uses all four.
SAST: Static Analysis
Tools scan your source code for patterns associated with vulnerabilities:
SQL injection (unsafe string concatenation)
XSS (unescaped user input in HTML)
Hard-coded secrets
Insecure crypto usage
Path traversal
Insecure deserialization
Common SAST tools: Semgrep, SonarQube, Snyk Code, GitHub Advanced Security.
Strengths:
Fast — runs in CI on every commit
Cheap — open-source options exist
Catches whole classes of issues
Weaknesses:
High false positive rate (especially generic rules)
Misses runtime-dependent issues
Can be silenced or ignored if not enforced
Practical approach: run SAST in CI with curated rules (tune out the noise), block PRs on high-confidence findings, log lower-confidence ones for review.
DAST: Dynamic Analysis
Tools test the running application from the outside, sending malicious-looking inputs to see what the application does.
Common DAST tools: OWASP ZAP, Burp Suite, Nuclei.
Strengths:
Catches runtime issues SAST misses
Tests the application as deployed
Finds configuration mistakes
Weaknesses:
Slower than SAST
May miss issues that require authentication
Can disrupt running systems if not careful
Practical approach: run DAST against staging environments, not production. Schedule weekly or pre-release. Don't run from CI on every commit.
Dependency Scanning
Most modern applications include hundreds of third-party libraries. Many have known vulnerabilities (CVEs).
Tools: Dependabot, Snyk, Renovate.
These tools:
List all dependencies
Check against vulnerability databases
Flag known issues
Often produce automatic update PRs
Strengths:
Catches a major source of real-world breach
Automated; minimal effort per check
Drives steady upgrade cadence
Weaknesses:
False positives common (vulnerability in code path you don't use)
Triage required — not every CVE is actionable
Updates can break things
Practical approach: enable dependency scanning, triage findings weekly, update aggressively on critical CVEs, batch routine updates.
Penetration Testing
Humans actively trying to break in. Sometimes internal red team, sometimes external firm.
Strengths:
Finds chains of issues automated tools miss
Tests business-logic vulnerabilities
Produces actionable reports with remediation guidance
Weaknesses:
Expensive
Time-boxed; can't run continuously
Quality varies dramatically by tester
Practical approach: annual pentest at minimum; before major releases; after significant architecture changes. Vendor quality matters more than vendor brand.
What Developers Should Watch For
The OWASP Top 10 is a regularly-updated list of common web vulnerabilities. Worth knowing:
Broken access control — users accessing data or functions they shouldn't
Cryptographic failures — weak crypto, exposed sensitive data
Injection — SQL, command, LDAP injection
Insecure design — fundamental design flaws
Security misconfiguration — default credentials, exposed config
Vulnerable components — outdated libraries
Authentication failures — weak auth, session issues
Data integrity failures — unsigned updates, compromised pipelines
Logging failures — insufficient or excessive logging
Server-side request forgery (SSRF)
For each, learn the pattern and the mitigation. Most are simple to avoid once you've seen them.
Building Security Into Tests
Beyond dedicated security tools, security-relevant tests in your normal suite:
Authentication tests (signed-out users can't access protected resources)
Authorization tests (users can't access other users' data)
Input validation tests (malicious-looking inputs are rejected)
Rate limiting tests (abuse patterns are slowed or blocked)
CSRF tests (cross-origin requests handled correctly)
These aren't separate from your regular tests. They're part of behavior verification. Treat security as a behavior, not a separate concern.
Threat Modeling
Before testing security, understand what you're defending against.
A lightweight threat model asks:
What are we protecting? (data, services, money, reputation)
Who might attack us? (random scanners, motivated attackers, insiders)
What could they do? (steal data, deny service, escalate privilege)
What's the impact?
This shapes your testing priorities. A simple internal tool needs different testing than a payment processor.
The Shift-Left Approach
"Shift left" means catching security issues earlier in the development cycle, where they're cheaper to fix.
Concrete shift-left practices:
Secrets scanning in pre-commit hooks
SAST in PR checks
Dependency scanning continuous
Security review for sensitive design changes
Developer training on common patterns
The alternative — security finding issues at the end — costs much more to address and produces friction between teams.
Common Mistakes
Checkbox security. Running tools and ignoring results. Worse than not running them.
Tool overload. Five SAST tools producing thousands of findings. Triage costs more than insight.
Security-only-at-pen-test-time. Spending nothing during development, then surprised by the pentest results.
Security as gate, not partner. Security team enters at the end with veto. Friction guaranteed.
Ignoring DAST. Running only SAST. Misses runtime issues.
A Working Setup for a Small Team
If you have nothing today:
Enable Dependabot or equivalent dependency scanning
Add a SAST tool (Semgrep or similar) to CI with curated rules
Run secrets scanning as a pre-commit hook
Set up basic DAST (OWASP ZAP) against staging weekly
Schedule an annual pentest
Total setup time: a few days. Ongoing cost: low. Coverage: enough to catch most common issues.
Reading Results
Security tools produce findings. Each finding needs triage:
True positive, exploitable: fix
True positive, not exploitable in your context: document why; consider preventive fix anyway
False positive: tune the rule
Ambiguous: investigate
Track triage decisions. Without tracking, the same false positive gets re-triaged forever.
Integration With Development
Security testing works best when it's integrated, not bolted on:
Findings appear in normal review tools (PR comments)
Severity levels respect normal priority systems
Security regressions are tracked like other regressions
Security learnings feed back into engineering practices
The team's culture should treat security findings the same as functional bugs: serious, prioritized, fixable.
Key Takeaway
Security testing has four layers: SAST (code analysis), DAST (running application), dependency scanning (third-party libraries), and penetration testing (human-driven). Each catches different things. Developers should run SAST in CI, scan dependencies continuously, and write security-relevant tests as part of normal coverage. Threat modeling guides priorities. Shift-left practices catch issues weeks before they'd otherwise surface. The mature program isn't running all the tools; it's integrating findings into normal development flow.
Related reading
Keep learning. This article is part of the Software Testing Foundations path in the ShiftQuality Learning Center. Learn to design tests that catch real bugs.
