Episode 56 · Module 11 · Monitoring & Incident Response

Security Testing in Your Development Process

19 May 2026 · 8:50 · Security for Legal SaaS

8:50 8:50

If your security testing happens once a year in a penetration test, you're finding bugs 364 days too late. Every vulnerability that exists in production between pen tests is a vulnerability an attacker can exploit. The modern approach — and the only one that scales — is continuous security testing embedded in your development process, from the moment code is written to the moment it runs in production.

Today’s Lesson

Security for Legal SaaS — Episode 56: Security Testing in Your Development Process

Finding Bugs 364 Days Before the Pen Test

OWASP's guidance on integrating security into the SDLC (Software Development Lifecycle) is unambiguous: security testing must happen at every phase — requirements, design, implementation, verification, and deployment — not as a gate at the end.¹ The shift-left movement (moving security activities earlier in the development process) has been the dominant trend in application security since 2020, and for good reason: fixing a vulnerability in development costs a fraction of fixing it after deployment.²

For legal SaaS teams — where a vulnerability might expose attorney-client privileged communications or allow manipulation of case records — the cost of a late-discovered bug extends beyond engineering time into professional liability, regulatory penalties, and client trust.

The Security Testing Pyramid

Borrow from the testing pyramid concept: lots of automated checks at the base, fewer manual reviews in the middle, rare comprehensive assessments at the top.

         /\
        /  \        Annual penetration tests
       /    \       (1-2 per year)
      /------\
     /        \     Manual code reviews for
    /          \    security-critical changes
   /------------\
  /              \  Automated testing in CI/CD:
 /                \ SAST, DAST, SCA, secrets scanning
/------------------\

Layer	Frequency	Scope	Finds
SAST in CI	Every pull request	Source code patterns	SQL injection, XSS, insecure crypto, hardcoded secrets
SCA in CI	Every pull request	Third-party dependencies	Known CVEs in libraries you use
Secrets scanning	Every commit (pre-commit hook)	Repository content	API keys, passwords, tokens accidentally committed
DAST in staging	Every deployment to staging	Running application	Authentication flaws, injection in HTTP responses, header misconfigurations
Manual code review	Security-critical changes	Authentication, authorisation, encryption code	Logic flaws, business logic bypasses
Penetration test	1-2 times per year	Full application + infrastructure	Complex attack chains, multi-step exploits

Shift Left: SAST in the IDE

SAST (Static Application Security Testing) analyses source code without executing it, looking for patterns that indicate vulnerabilities. Modern SAST tools integrate directly into developers' editors, flagging issues as code is written — before it even reaches a pull request.³

Tools like Semgrep (open-source, rule-based pattern matching), CodeQL (GitHub's code analysis engine, which we mentioned in Episode 8), and SonarQube scan for:

SQL injection patterns — string concatenation in database queries instead of parameterised queries
XSS vulnerabilities — unescaped output in templates, use of `dangerouslySetInnerHTML` (as covered in Episode 9)
Insecure cryptographic operations — weak algorithms, hardcoded keys, missing TLS verification
Taint tracking — following untrusted input from an API endpoint through to a sensitive operation like a database query or file write

For legal SaaS: Configure SAST rules specifically for your risk profile. Add custom rules for: access control checks on every endpoint that serves client data (IDOR prevention — Episode 6), tenant isolation in multi-tenant queries (row-level security — Episode 8), and audit logging on every data access operation.

DAST in Staging

DAST (Dynamic Application Security Testing) tests your running application from the outside — like an automated attacker. It sends crafted requests to your application and analyses the responses for vulnerabilities that only manifest at runtime.⁴

Where SAST finds "this code builds a SQL query unsafely," DAST finds "this endpoint actually returns data it shouldn't when I manipulate the request." DAST catches:

Authentication bypasses visible only when testing the full request/response cycle
Security header misconfigurations — missing HSTS (as covered in Episode 12), CSP, X-Frame-Options
Server information leakage — error messages exposing stack traces, database versions, internal paths
CORS misconfigurations that allow cross-origin data theft (as covered in Episode 12)

Run DAST against your staging environment (a copy of your application that mirrors production but uses test data) on every deployment. Tools like OWASP ZAP (open-source), Burp Suite (commercial), and SecureLayer7 provide DAST capabilities ranging from free to enterprise-grade.⁵

Why Both SAST and DAST?

They find different things. SAST examines your code and finds potential vulnerabilities. DAST examines your running application and finds actual exploitable issues. Some vulnerabilities (business logic flaws, complex authentication bypasses) are invisible to SAST. Some (dead code paths, internal utility functions) are invisible to DAST. Using both provides complementary coverage.⁶

Dependency Scanning: Your Supply Chain Check

Every third-party library in your application is code you didn't write, didn't review, and might contain known vulnerabilities. SCA (Software Composition Analysis) tools continuously scan your dependencies against vulnerability databases.

As we discussed in Episode 51, AI-generated code exacerbates this risk by suggesting vulnerable package versions. Automated dependency scanning catches these before deployment:

`npm audit` / `pip audit` — built-in vulnerability scanning for Node.js and Python
Snyk — commercial SCA with automated pull requests for vulnerable dependencies
Dependabot (GitHub) / Renovate — automated dependency update PRs
OWASP Dependency-Check — open-source SCA tool maintaining the National Vulnerability Database (NVD) feed⁷

Configure your CI pipeline to fail the build when a dependency has a known critical or high-severity CVE (Common Vulnerabilities and Exposures — the standardised identifier for publicly known security vulnerabilities, as covered in Episode 8). A red build for a vulnerable dependency forces the issue to be addressed before deployment.

Penetration Testing: The Expert Assessment

Automated tools have blind spots. Penetration testing — where skilled security professionals manually attempt to exploit your application — finds vulnerabilities that automated tools miss: business logic flaws, complex multi-step attack chains, social engineering vulnerabilities, and novel attack patterns.

Scoping a Pen Test for Legal SaaS

Define the scope before engagement:

In Scope	Typically Out of Scope
Application authentication and authorisation	Third-party IdP infrastructure (Okta, Azure AD)
API endpoints and data access controls	Client-owned networks
Tenant isolation (can Firm A access Firm B's data?)	Physical security
File upload and document processing	Social engineering of end users
Session management and token handling	Denial of service attacks against production
Infrastructure (cloud configuration, network)	Testing outside agreed hours

Frequency

For most legal SaaS platforms: annually at minimum, plus after any major architectural change (new authentication system, new data storage layer, new API surface). If you handle highly sensitive data (active litigation strategy, government legal work), semi-annual pen tests are appropriate.

What to Do with the Findings

A penetration test report is not a trophy — it's a to-do list. Prioritise findings by severity and exploitability. Critical and high findings should be remediated before the next deployment. Medium findings within 30 days. Track every finding to resolution. Re-test to verify fixes.

Bug Bounty Programmes

Bug bounties — public or private programmes where external security researchers are rewarded for finding and reporting vulnerabilities — extend your testing surface beyond your team and your pen tester.

When to start: Not on day one. Start a bug bounty after you have: (1) automated security testing in CI, (2) at least one pen test completed, and (3) a process for triaging and fixing reported issues. A bug bounty before these basics are in place generates a flood of reports you can't handle.

Platform options: HackerOne and Bugcrowd provide managed platforms with triage support, legal safe harbour for researchers, and structured reward tiers.

Legal SaaS consideration: Your bounty scope must explicitly exclude access to real client data. Use a dedicated testing environment with synthetic data. Make this clear in the programme policy.

Automated Security Regression Tests

The most frustrating vulnerability is one you already fixed that comes back. Regression testing — automated tests that verify previously fixed vulnerabilities remain fixed — prevents this.

For every security bug found (whether by SAST, DAST, pen test, or bug bounty):

Write an automated test that reproduces the vulnerability
Verify the test fails before the fix and passes after
Add the test to your CI suite permanently
The test runs on every pull request, forever

Over time, this builds a growing library of security-specific regression tests — a permanent immune system for your application.

Example for legal SaaS: A pen test discovers that /api/cases/:id/documents doesn't verify the requesting user belongs to the case's firm (an IDOR vulnerability). You fix it by adding a tenant check. The regression test: authenticate as User A from Firm A, request a document belonging to Firm B's case, assert 403 Forbidden. This test runs on every PR. If anyone refactors the access control code and accidentally removes the tenant check, the test catches it.

The Security Testing Minimum

Control	When	What It Catches
Pre-commit secret scanning	Every commit	Accidental credential exposure
SAST in CI	Every pull request	Code-level vulnerabilities
SCA / dependency scanning in CI	Every pull request	Known vulnerabilities in libraries
DAST in staging	Every deployment	Runtime vulnerabilities and misconfigurations
Manual review of security-critical code	As needed	Logic flaws, business rule bypasses
Annual penetration test	Yearly + major changes	Complex, multi-step vulnerabilities
Security regression tests	Every pull request	Previously fixed bugs don't return

Security testing is not a phase. It's a layer that runs continuously, at every stage of development, catching different classes of vulnerabilities at the earliest possible moment. The pen test finds what the automation missed. The automation prevents the pen test from finding the same things twice.

Next episode: access reviews and least privilege audits — how to ensure that the contractor who left six months ago doesn't still have an active API key.

Sources & references

OWASP, OWASP in SDLC — Integration Standards.
Cymulate, Shift Left Security for DevOps & AppSec Teams.
TechSpective, Is SAST Still Relevant in 2026? Rethinking Static Code Analysis.
Checkmarx, What Is Dynamic Application Security Testing (DAST)? 2026 Guide.
SecureLayer7, Top DAST Tools in 2026: Features, Pros & Cons.
Deepstrike, SAST vs DAST vs IAST vs RASP Explained (2025).
OWASP, Dependency-Check: Software Composition Analysis.
OX Security, SAST and DAST Tools: Still Essential Security Testing Tools in 2025.
Cybersecurity Dive, The Future of DAST in an AI-First World.
Netalith, Automated DevSecOps Testing Workflows: Integrating Security into CI/CD Pipelines.
Deepstrike, Software Testing & Security Testing 2025.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 56 — security testing in your development process. Alice, we've been through monitoring, incident response, disaster recovery. Now we're closing the loop — how do you find the vulnerabilities before the attackers do?

Alice: And the key word is "before." If your security testing happens once a year in a penetration test, you're finding bugs three hundred and sixty-four days too late. Every vulnerability that exists in production between pen tests is one an attacker can exploit. The modern approach is continuous security testing — embedded in your development process, running on every code change, catching different types of issues at different stages.

Dan: Mm. So walk me through the layers. Where does it start?

Alice: Start at the very bottom: pre-commit secret scanning. Before code even reaches your version control system, a hook — an automated script that runs before the commit is saved — scans for accidental secrets. API keys, database passwords, tokens. We covered this back in Episode 52 with the day-zero checklist. This is your first line of defence against the most common mistake developers make.

Dan: Right. And then what runs in the CI pipeline?

Alice: Two things run on every pull request. First: SAST — Static Application Security Testing. These are tools that examine your source code without running it, looking for patterns that indicate vulnerabilities. SQL injection patterns — where someone builds a database query by concatenating strings instead of using parameterised queries. XSS patterns — where user input gets rendered without escaping. Insecure cryptographic operations. Tools like Semgrep and CodeQL can catch these as the developer writes the code — some even run in the editor, flagging issues in real time.

Dan: Mm-hmm. And the second thing?

Alice: Dependency scanning — also called Software Composition Analysis or SCA. Every third-party library in your application is code you didn't write and might contain known vulnerabilities. SCA tools check your dependency list against vulnerability databases. npm audit, pip audit, Snyk, Dependabot — they all do versions of this. Configure your pipeline to fail the build when a dependency has a known critical or high-severity vulnerability. A red build forces the team to address it before deployment.

Dan: Yeah. We talked about hallucinated packages in Episode 51. This catches those too?

Alice: It catches known-vulnerable real packages. For hallucinated packages — the slopsquatting risk — you need the private registry approach we discussed. But SCA catches the other half of the AI code risk: when the AI suggests a real package at a vulnerable version. Combined with a locked dependency file, you get comprehensive supply chain protection.

Dan: Mm. So SAST looks at code, SCA looks at dependencies. What about the running application?

Alice: That's DAST — Dynamic Application Security Testing. DAST tests your running application from the outside, like an automated attacker. It sends crafted requests and analyses the responses. Where SAST finds "this code builds a SQL query unsafely," DAST finds "this endpoint actually returns data it shouldn't when I manipulate the request." It catches authentication bypasses, security header misconfigurations, information leakage in error messages, CORS issues — things that only manifest when the full application is running.

Dan: And you run that against staging, not production?

Alice: Against staging — a copy of your application that mirrors production but uses test data. Run it on every deployment to staging. OWASP ZAP is a solid open-source option. Burp Suite is the commercial standard. The key is that SAST and DAST find different things. Some vulnerabilities are invisible in the code but obvious in the running application. Some are obvious in the code but can't be triggered in a running test. Using both gives you complementary coverage.

Dan: Right. Now, all of that is automated. Where does manual testing come in?

Alice: <sigh> Manual testing — penetration testing — is where you find the things automation can't. Business logic flaws. Complex multi-step attack chains. The scenario where an attacker creates two accounts, uses one to invite the other to a case, then exploits a permission gap that only exists during the invitation flow. No automated scanner is going to find that. A skilled pen tester will.

Dan: Hmm. How often should a legal SaaS platform do pen tests?

Alice: Annually at minimum. Plus after any major architectural change — a new authentication system, a new data storage layer, a new API surface. For platforms handling highly sensitive data like active litigation strategy, semi-annual. And scope it carefully. For legal SaaS, the critical targets are: tenant isolation — can Firm A's users access Firm B's data? Authentication and session management. API access controls. File upload and document processing. These are where the highest-impact vulnerabilities live.

Dan: Mm. And what do you do with the findings?

Alice: A pen test report is a to-do list, not a trophy. Prioritise by severity and exploitability. Critical and high findings get fixed before the next deployment. Medium within thirty days. Track every finding to resolution, and re-test to verify the fixes work. And here's the crucial step most teams skip: for every vulnerability found, write an automated regression test. A test that reproduces the vulnerability, fails before the fix, passes after, and runs on every pull request forever.

Dan: Yeah. So the bug can never come back.

Alice: Exactly. Over time, you build a growing library of security-specific regression tests. Think of it as your application's immune system. Every infection it survives makes it stronger. The pen tester finds an IDOR vulnerability — someone can access another firm's case documents by changing the ID in the URL. You fix it. You write a test: authenticate as User A from Firm A, request a document belonging to Firm B, assert 403 Forbidden. That test runs on every pull request. If anyone refactors the access control code and accidentally removes the tenant check, the test catches it immediately.

Dan: Mm-hmm. What about bug bounties? When does a legal SaaS team start one of those?

Alice: Not on day one. Start a bug bounty after you have automated testing in CI, at least one pen test completed, and a process for triaging and fixing reports. A bug bounty before those basics just generates a flood of reports you can't handle. When you're ready, platforms like HackerOne and Bugcrowd provide managed programmes with triage support and legal safe harbour for researchers. For legal SaaS, the bounty scope must explicitly exclude access to real client data. Use a dedicated testing environment with synthetic data.

Dan: Right. So to sum up the layers: pre-commit secret scanning on every commit. SAST and dependency scanning on every pull request. DAST on every deployment to staging. Manual code review for security-critical changes. Pen tests annually. And regression tests that grow with every bug found.

Alice: That's the security testing pyramid. Lots of cheap, fast, automated checks at the base. Fewer, deeper manual reviews in the middle. Rare, comprehensive expert assessments at the top. The automated layer prevents the pen test from finding the same things twice. The pen test finds what automation can't see. And regression tests ensure that nothing ever comes back. It's not a phase of development. It's a layer that runs continuously.

Dan: Next episode — access reviews and least privilege audits. That contractor who left six months ago? Their API key is probably still active.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.