Most teams run one kind of security testing and believe they are covered. A scanner runs somewhere in the build, it goes green, and nobody asks what it was looking for.
Security testing is not one activity. It is six, and each one sees a different class of problem. A code scanner will find a hard-coded password and will never notice that your checkout lets a customer change the price. A dependency scanner will flag a vulnerable library and cannot tell you whether you call the vulnerable part. A penetration test finds the thing nobody thought to look for, once a year, and then the code changes.
This page is about what each type of security testing actually catches, where it belongs in the software development lifecycle, and what none of them catch. The last part is the one most guides leave out, and it is the part that decides whether your testing is honest.
You will not find a breach-cost figure here, or the claim that fixing a bug in production costs a hundred times more than fixing it in design.
Both are repeated on nearly every page about this subject and sourced on almost none of them, and the case for security testing does not need them.
We set this up for startups, SMBs and enterprise clients as part of our QA and software testing services, so the order of work here is the order we use when our own team owns the outcome. If you want the wider case for testing before the security-specific part, our note on software quality assurance covers it.
What security testing in the SDLC actually means
Functional testing checks that the right thing happens. Security testing checks that the wrong thing cannot be made to happen.
That is the whole distinction, and it explains why a fully tested application can still be wide open: your test suite proves that a valid order goes through. Security testing asks what happens when somebody sends an order that was never meant to be possible: a negative quantity, another customer's identifier, a file where a number should be.
Security testing in the SDLC means doing that at every stage rather than once at the end: in design, by asking what could go wrong; in development, by reading the code for known-dangerous patterns; in build, by checking what your dependencies bring with them; in testing, by attacking a running version; and before release, by having a person try to break it.
Each of those catches something the others cannot. That is why the list is six items long rather than one.
Why the importance of security testing is not really about breaches
Every article on this subject opens with a breach figure. That framing is doing nobody any favours, because it makes security sound like a risk-management topic rather than an engineering one.
Three reasons hold up better, and none needs a statistic.
A security bug is an ordinary bug found late, and it sits in the code like any other defect. The difference is that a functional bug is reported by a user who wants it fixed, and a security bug is found by somebody who does not tell you. Security testing shortens the gap between writing the mistake and knowing about it, which is the same reason you run any other test.
Remediation competes with work you have already promised. A vulnerability found the week before a release does not arrive with extra engineers attached. It arrives during a sprint that was already full, and something planned gets dropped. Finding the same problem in a pull request costs an hour and no negotiation.
Buyers now ask. Enterprise procurement, regulated industries and security questionnaires all ask what you test and how often. Answering we scan dependencies on every build and pen-test before each major release is a sentence that closes deals. We take security seriously is not.
What security testing does not make you
It does not make an application secure, safe or immune to attack. No activity on this page does that, and any page claiming otherwise is selling something.
What it does is narrower and worth having. It reduces the number of ways in, and it finds the well-known mistakes before somebody else does. It shortens the time between a mistake being written and being noticed. And it produces evidence that a process exists, which is what an auditor or a customer's security team is actually asking to see.
Types of security testing, and what each one catches
Six types. For each one: what it does, what it finds, what it cannot see, and when it runs. The last two columns are the ones that decide whether your programme has a hole in it.
Static application security testing (SAST)
SAST reads your source code without running it, looking for patterns that are known to be dangerous.
What it catches: string concatenation into a database query, a password written into a config file, weak or obsolete cryptography, unvalidated input reaching something that executes it, and user data written into a page without escaping.
What it cannot see: anything that depends on how the application is deployed or configured, whether the risky code path is reachable in practice, or whether your access rules are the right rules. It reads text, and it has no idea what your business considers allowed.
The honest problem with it: SAST produces false positives, sometimes a lot of them. That is a consequence of reading code without running it, not a flaw in any particular tool. It means the output is a queue of things to look at rather than a list of things to fix, and a team that treats every finding as a defect will abandon the tool within a quarter.
When it runs: on every commit, and in the developer's editor if the tool supports it. Speed matters more than depth here, because a check that adds ten minutes to a build gets switched off.
Dynamic application security testing (DAST)
DAST attacks a running version of the application from the outside, the way an attacker would, and it has no access to your code.
What it catches: injection that actually works rather than injection that merely looks possible, endpoints you forgot were exposed, missing or misconfigured security headers, weak session handling, and error pages that reveal more than they should.
What it cannot see: where in the code the problem is, anything behind a login it has not been given credentials for, which is most of the interesting surface unless you configure it properly, and anything in a code path it never reached.
Why it is worth the trouble: everything DAST reports is real. It did the thing, and the application allowed it. That makes triage far cheaper than SAST triage, and it makes DAST findings much easier to get prioritised.
When it runs: nightly, against a deployed build in a non-production environment. It is slower than a unit test suite, and it can leave test data behind, so it does not belong in the path of somebody waiting to merge.
Security testing across the SDLC phases
Same six activities, arranged by when they happen. For each phase: what to do, what it produces, and who owns it. The ownership line matters more than it looks, because an activity with no owner does not happen twice.
Requirements and design: threat modelling and security requirements
The cheapest moment in the whole lifecycle, and the only one where a vulnerability can be designed out rather than found.
What to do: take the design of whatever you are about to build and walk through it with three questions. Where does data arrive from outside our control? Who is allowed to do each thing, and where is that checked? What happens if that check fails or is skipped?
Alongside it, write the security requirements as requirements. Only the account owner and an administrator may view these records is testable. The system shall be secure is not, and it is the line that appears in most specifications.
What it produces: a short list of what could go wrong, kept with the design. That list becomes the test cases later, which is why an hour here saves a week in the testing phase.
Who owns it: whoever owns the design. Not a security team — they may facilitate, but the people building it have to be in the room or the output is a document nobody reads.
Development: SAST, secrets scanning and secure code review
The phase with the tightest feedback loop, which is the whole argument for shifting security work earlier.
What to do: run SAST on every commit, keep it fast, and fail the build only on new high-severity findings rather than on the accumulated backlog. Run a secrets scanner in the same stage. Add one security question to the pull request template so review is a habit rather than an event.
On secrets specifically: scan the commit, not just the current files. A credential removed in a later commit is still in the history, and history is what gets cloned. Anything the scanner finds should be treated as compromised and rotated, not just deleted.
What it produces: findings a developer can act on while the code is still in their head. A finding that arrives three weeks later costs several times more to fix, not because the fix is harder but because the context is gone.
Who owns it: the development team, with the build enforcing it. Security testing that depends on somebody remembering to run it is a practice with an expiry date.
Testing: DAST, SCA and security regression tests
The phase where security testing looks most like ordinary testing, and where it should.
What to do: run DAST against a deployed build, with credentials so it can reach the parts that matter, run SCA on the build output, and write a regression test for every vulnerability you fix.
What security testing does not cover
Run everything on this page, on the schedule above, with a named owner for each queue, and there are still classes of problem that nothing here will find. Knowing which ones is the difference between a programme and a false sense of security.
Business-logic flaws: the request is valid, the user is authenticated, every field passes validation. And the sequence lets somebody apply a discount twice, or skip the payment step, or cancel an order after it shipped and get a refund. No scanner reports these, because nothing is technically wrong. Only a person who understands what the feature is for can see them, which is why penetration testing and exploratory testing exist.
Access control that is wrong by design: tools check that your authorisation code runs. They cannot check that the rule it enforces is the rule you meant. If the specification says support staff can view any customer record and that was a mistake, every test passes and the problem is in the requirement.
Anything involving people: a convincing email, a phone call to a helpdesk, a credential shared in a chat message because somebody was in a hurry. Testing software does not touch this, and it is a common route in; training and process cover it, not scanners.
Insider misuse: someone with legitimate access doing something they should not, which by definition looks like normal use. Logging, monitoring and separation of duties cover it; testing does not.
Third-party services you do not control: your payment provider, your analytics vendor, your authentication service. You can test your integration, but you cannot test their code, and their incident becomes your incident. Contracts, questionnaires and attestations are the tools here.
Anything after release, in production: testing tells you what was possible when you tested, and monitoring tells you what is being attempted now. They are different jobs and neither substitutes for the other.
Stating this is not an argument against security testing. It is an argument for knowing the shape of what you have covered, so that the uncovered part gets a plan rather than a hope. A team that can name these six is in a far better position than a team with a green dashboard and no idea what it is not looking at.
Security testing best practices that survive a release schedule
Six practices. Each one has survived contact with a team that had a deadline, which is the only test that matters for a practice.
Fail the build on new findings, not on the backlog. Point a scanner at an existing codebase and it returns hundreds of findings on day one. Failing the build on all of them means nobody can ship, so the gate gets disabled within a week. Set the line at new high-severity findings introduced by this change, and give the backlog its own schedule.
Triage by exploitability, not by severity alone. A critical-rated vulnerability in a library you never call matters less than a medium-rated one on your login page. Severity ratings describe the vulnerability in general; only you know what your application actually does with it. Teams that sort strictly by severity spend their first month on findings that cannot be reached.
Write a regression test for every vulnerability you fix. Send the attack that worked, assert that it now fails. This is the cheapest practice on the list and the one that stops the same problem returning in a refactor two years later.
Keep dependencies current on a rhythm. Small, regular updates are boring and fast. A library four major versions behind cannot be patched in an afternoon when a critical vulnerability lands, and that afternoon always arrives at the worst moment. Monthly is enough for most teams.
Give the findings queue a named owner. Not a team, a person. Their job is not to fix everything; it is to decide what happens to each finding — fix now, fix later, accept with a reason written down, or false positive. A queue with no owner grows until people stop opening it, and an unread queue is worse than no queue because it looks like coverage.
Re-test after remediation. Closing a finding because a developer says it is fixed is a record-keeping exercise. Run the check again. This is also what an auditor asks for, and it is the difference between a process and a spreadsheet.
None of these is expensive. What they need is the same discipline any test suite needs, which is why they belong in the software testing plan rather than in a separate security document nobody opens.
Where to start when you have no security testing at all
If the honest answer to what security testing do you run is none, this section is the whole page for you. The instinct is to build a programme. Do not. Do three things.
The first quarter for a small team
One: turn on dependency scanning. It takes an afternoon, it needs no expertise to read, and most of the known vulnerabilities in your application are already in code you did not write. This gives the largest reduction in known risk per hour spent, by a wide margin.
Two: scan for secrets, including your history. Run a secrets scanner across the repository and its commit history. If it finds a live credential, rotate it — deleting the line does not help, because the history is what gets cloned. Then put the check in the pipeline so the next one gets caught at the commit.
Three: spend two hours threat modelling your most sensitive flow. Whichever one handles money, personal data or administrative access. Three questions: where does data come in from outside, who is allowed to do what and where is that checked, and what happens if the check is skipped. Write down what could go wrong.
That is the quarter. Not a scanner in every stage, not a policy document, not a tool evaluation. Three moves, each of which removes a real class of risk, and each of which a small team can actually sustain.
Add SAST next quarter, when there is somebody to look at what it says. Add DAST after that. Book a penetration test once the obvious things are gone, because paying a specialist to find your out-of-date dependencies is an expensive way to learn something a free tool would have told you.
What changes at enterprise scale
At enterprise scale the problem is rarely coverage. Most large organisations already own several scanners. The problems are triage, ownership and consistency.
Triage: thousands of findings across dozens of applications, and no agreed way to decide what matters. Without a shared rule, each team invents one, and the findings that get fixed are the ones on whichever team is most conscientious rather than the ones that matter most.
Ownership: the tool belongs to the security team, the code belongs to the product teams, and the findings belong to nobody. This is the single most common reason a well-funded programme produces no improvement.
Consistency: four teams, four toolchains, four definitions of a high-severity finding, and no way to answer how exposed are we across the estate.
So the enterprise work is standardising the rule, assigning the queue, and making the results visible in one place — not buying a seventh scanner.
Four ways security testing in the SDLC goes wrong
Each with the symptom you would notice before anybody names the cause.
The ignored findings queue. Scanners run, findings accumulate, nobody triages. The symptom is a dashboard with a four-digit number on it that has not moved in six months. Everyone has stopped looking, and the tooling now provides documentation of what you failed to fix rather than protection. The fix is not a better scanner. It is one named person and a rule about what counts as urgent.
Scanning without fixing. A close relative, and worse, because it looks like activity. Reports are produced, circulated and filed. Nothing changes in the code. The symptom is a security review meeting where the same three items appear every month. If a finding cannot be fixed, the honest outcome is a written acceptance with a reason and a date to revisit, not a permanent place on a list.
The annual penetration test as the whole programme. A test is booked, the report arrives, the urgent items are fixed, and nothing else happens for eleven months. The symptom is that the report finds the same class of problem every year. A point-in-time test cannot cover code that changes weekly. It is the last layer, not the only one.
Security testing owned by nobody. The tools belong to the security team, the code belongs to the product teams, and the findings belong to whoever feels guiltiest. The symptom is a finding that has been reassigned four times in the ticket system. This is the root cause behind most of the other three, and it is the cheapest to fix and the least often fixed, because it needs a decision rather than a purchase. Where the gap is capacity rather than intent, QA and automation testing staff augmentation is a more honest answer than another tool.
All four are ownership failures rather than technical ones. The scanners mostly work. What fails is the arrangement around them, and that arrangement costs nothing to set up at the start and a great deal to retrofit.
Build security testing into your SDLC with 4Labs Technologies
Most teams do not need to be told that security testing matters. They need somebody to work out which two things to do first, wire them in so they run without anybody remembering, and set up the triage so the findings get fixed rather than counted.
That is the work we do. We look at the application and the release process, recommend what to run and in what order, put the scans in the pipeline, and set up the queue with a rule for what counts as urgent and a person who owns it.
Work with our QA and software testing team
An engagement starts with what is there. What gets scanned today, what comes out of it, where those findings go, how current the dependencies are, and what a release actually passes through before it ships.
Often the first recommendation costs nothing: triage what the tools you already own have already found. A queue nobody has read usually contains two or three things worth doing this week, and finding them is cheaper than buying anything.
What comes back is a short ordered list of what to run, wired into the pipeline, with the triage rule written down and the queue assigned.
What you bring: access to the repository and the pipeline, and one person who can say which data in the application would genuinely hurt to lose. That answer decides the order of everything else.
What we leave behind: scans that run on their own, a queue somebody owns, regression tests for what was fixed, and no dependency on us to keep it going.
Our QA and software testing services cover this alongside the rest of the testing work, because security testing that lives apart from the test suite is the kind that stops running.
Tell us what you scan today and what happens to the findings. Let's Connect.
Frequently asked questions about security testing in the SDLC
What is security testing in the SDLC?
It is checking, at every stage of development, that software cannot be made to do something it was not meant to do. Functional testing proves the right thing happens; security testing proves the wrong thing cannot be forced. It covers six activities: threat modelling, static analysis, dependency scanning, dynamic testing, vulnerability scanning and penetration testing.
Why is security testing important in software development?
Because a security bug is an ordinary bug found late, and the person who finds it may not tell you. Testing shortens the gap between writing the mistake and knowing about it, keeps remediation out of the week before a release, and produces the evidence that enterprise and regulated buyers now ask for before they sign.
What are the types of security testing?
Static application security testing (SAST) reads the code. Dynamic application security testing (DAST) attacks the running application. Software composition analysis (SCA) checks your dependencies. Vulnerability scanning checks the infrastructure and configuration. Secure code review and threat modelling are the human activities. Penetration testing is a person trying to break it.
What is the difference between SAST and DAST?
SAST reads source code without running it, so it sees everything including problems that are not reachable in practice. DAST attacks the running application from outside, so it sees only what is reachable, but everything it reports is real. SAST tells you where the problem is in the code; DAST tells you that it works. Use both, and add SCA before either.
When should security testing start in the SDLC?
At design, before code exists. Threat modelling costs an hour or two, needs no tools, and is the only activity that can remove a class of vulnerability rather than find instances of it. After that, security testing runs continuously: on every commit, every build, nightly, and before each major release.
What is shift left security?
Moving security work earlier in the lifecycle, so problems are found while the code is still being written rather than in a pre-release scan. In practice it means threat modelling at design, static and secrets scanning on every commit, and dependency checks on every build. It does not mean removing the later checks.
Does automated security testing replace penetration testing?
No. Automation covers known patterns at speed and repeats reliably. A penetration tester finds the chained weaknesses and business-logic flaws that no scanner can express, because those break intent rather than rules. Automation should remove the obvious findings so the tester spends their time on what only a person can do.
