Security Testing: Red, Blue, and Purple Teams, Scanning, SAST, and DAST

Security controls are only assumptions until they are tested. An organization can deploy firewalls, write policies, train staff, and patch systems, yet still not know whether an actual attacker would get in, whether the security team would notice, or whether the new web application leaks data. Security testing replaces those assumptions with evidence by deliberately probing defenses under controlled, authorized conditions.

The word authorized matters. Every form of testing described in this lesson is performed with explicit permission from the organization, under agreed rules that define what may be tested, when, and how far the testers may go. The same actions performed without authorization are simply attacks. Legitimate testers operate under written agreements, often called rules of engagement, and stop at the boundaries those agreements set. On the exam, ethical testing is always authorized, scoped, and documented.

Testing serves several purposes at once. It finds vulnerabilities while they can still be fixed quietly, before an adversary finds them first. It measures whether detection and response actually work: it is one thing to own monitoring tools and another to notice a simulated intruder moving through the network. It validates that people follow procedures under pressure. And it satisfies external obligations, since many regulations and customer contracts require regular security testing. The CC exam expects you to know the main categories of testing, what each one examines, and, above all, how to tell the commonly confused ones apart. The rest of this lesson works through those categories one by one.

Readiness testing borrows its team names from military exercises. The red team plays the adversary: it simulates real attackers, using their tools and techniques to attempt to breach the organization, with authorization but usually without warning the defenders. The blue team is the defense: the people who monitor systems, detect intrusions, and respond to contain them, whether the intruder is a real attacker or the red team. A red team exercise therefore tests both sides at once: can the attackers get in, and do the defenders notice?

The purple team is the one candidates most often get wrong. It is not a third, separate group of specialists; it is red and blue working together, sharing information openly instead of competing. In a purple team exercise, the red side demonstrates an attack technique and the blue side immediately checks whether its tools detected it, tuning defenses on the spot. The purpose is mutual improvement through collaboration and feedback, not a contest with a winner.

Remember it as a color mix: red plus blue makes purple, offense plus defense working jointly. If an exam scenario describes attackers and defenders sharing findings during the exercise to improve detection, the answer is purple team.

Vulnerability scanning is the automated examination of systems, networks, or applications to discover known weaknesses. A scanner probes its targets and compares what it finds against a regularly updated database of published vulnerabilities and insecure settings: missing patches, outdated software versions, open ports running vulnerable services, default credentials, and weak configurations. The output is a report listing each finding, typically with a severity rating so remediation can be prioritized.

Three characteristics define scanning, and each one shows up in exam questions. First, it is automated: software does the work, so scans are inexpensive to run and can cover an entire network. Second, it is broad but shallow: the scanner checks every reachable system against thousands of known issues, but it only identifies likely weaknesses. It does not break in. Third, it is recurring: because new vulnerabilities are published constantly and environments change, organizations scan on a regular schedule, often monthly or more frequently, and after significant changes.

Scanning has honest limitations. It can produce false positives, reporting a weakness that is not actually exploitable in context, which is one reason findings are validated before major remediation effort is spent. It can also miss issues that require human creativity to find, such as flaws in business logic or weaknesses that only emerge when several minor issues are chained together. Scanning tells you what is probably wrong; it does not prove what an attacker could actually accomplish. That proof is the job of penetration testing, and the difference between the two is one of the most reliably tested distinctions on the CC exam, covered next.

A penetration test is an authorized, largely manual exercise in which skilled testers attempt to actually exploit vulnerabilities to demonstrate what a real attacker could achieve. Where a scanner reports that a server is missing a patch, a penetration tester uses that missing patch to gain access, then explores what the access allows: reading sensitive data, moving to other systems, escalating privileges. The result is not a list of possible weaknesses but a demonstration of proven impact.

The two are complementary, not competing. Scanning provides continuous, wide coverage that catches routine issues cheaply; penetration testing provides occasional, deep validation of what those issues mean in combination. Mature programs do both. A penetration test also commonly begins with scanning as its reconnaissance step, then goes further where the scanner stops.

For the exam, the discriminating verb is exploit. If the scenario describes an automated tool producing a report of known weaknesses, it is a vulnerability scan. If it describes authorized testers attempting to break in and demonstrate impact, it is a penetration test. An answer choice that says a vulnerability scan exploits weaknesses, or that a penetration test is fully automated, is describing the wrong activity.

Applications get their own testing methods, and the exam expects you to know two of them by their initials. Static application security testing (SAST) analyzes an application's source code without running it. A SAST tool reads the code the way a meticulous reviewer would, tracing how data flows through the program and flagging dangerous patterns: unvalidated input reaching a database query, hardcoded credentials, unsafe functions. Because it needs only the code, SAST can run early in development, even before the application is complete, and it points to the exact file and line where a flaw lives.

Dynamic application security testing (DAST) tests the application while it is running. A DAST tool interacts with the live application from the outside as an attacker would, sending unexpected and malicious inputs and observing how the application responds. It needs no access to the source code, which also means it sees the application as deployed, catching problems that only appear at runtime, such as misconfigured servers or flaws in how components interact.

A simple analogy locks in the difference: SAST is proofreading the recipe, DAST is tasting the cooked dish. The exam trigger words are equally direct: without running it or examining the code means static analysis; against the running application means dynamic analysis. The two are complementary, because each finds problems the other cannot see.

The cheapest vulnerability to fix is the one that never gets built. Threat modeling is the systematic identification of potential threats to a system during its design, before code is written or infrastructure is deployed. Designers examine the planned system piece by piece and ask, in a structured way: what could go wrong here, who might attack this, and what would they try to do? Each identified threat then gets a planned defense, designed in from the start rather than patched on after an incident.

What makes threat modeling a discipline rather than a brainstorm is the structure. Frameworks give designers a checklist of threat categories to apply to every component so nothing is overlooked. The framework the CC exam expects you to recognize is STRIDE, whose letters name six threat categories: Spoofing (pretending to be another user or system), Tampering (improperly modifying data), Repudiation (denying having performed an action), Information disclosure (exposing data to those who should not see it), Denial of service (making the system unavailable), and Elevation of privilege (gaining rights one should not have). You need recognition depth only: know that STRIDE is a threat modeling framework and what its categories are, not how to run a full modeling workshop.

Position threat modeling correctly against the other methods in this lesson. Scanning, SAST, DAST, and penetration testing all examine something that already exists: code, a running application, a deployed network. Threat modeling is the only method here that works on a design. If an exam scenario describes a team identifying threats to a system that is still being planned, the answer is threat modeling, not any form of scanning or testing.

Not every attack travels over a network. Physical penetration testing assesses an organization's physical and human defenses by having authorized testers attempt to gain access the way a real intruder would: through doors, desks, and people. Technology controls mean little if a stranger can walk into the server room, and firewalls do not stop an employee from holding a door open for someone carrying coffee and a convincing smile.

The exam names three techniques. Phishing uses deceptive messages, typically email, to trick staff into revealing credentials or clicking malicious links; in a test, the phishing is simulated and measures how many employees take the bait and, just as importantly, how many report it. Tailgating (closely related to piggybacking) is following an authorized person through a secured door without presenting credentials, exploiting politeness: people naturally hold doors. Impersonation is pretending to be someone with a legitimate reason to be present or to ask, such as a delivery driver, an IT technician, a new employee, or an executive on the phone demanding urgent help.

A typical engagement combines them. Consider this scenario: a tester emails a simulated phishing message to 200 staff and harvests 30 credential entries. The next morning, wearing a courier uniform and carrying boxes, the tester tailgates through the staff entrance behind an employee who holds the door, then tells the receptionist he is the new printer technician and is directed, unescorted, to the equipment room, where he plugs a small device into the network. Every step tested a human or physical control: security awareness, badge discipline, visitor verification, and escort procedures. The findings feed directly into awareness training and physical policy fixes. As with all testing, authorization is what separates this exercise from a crime: physical testers carry written permission and stop at the boundaries the engagement defines.

This sub-domain is tested almost entirely through distinctions, so finish by decoding scenarios the way the exam frames them. Each method has a signature the question will include.

For the teams: attackers simulating an adversary is red; defenders monitoring and responding is blue; the two collaborating and sharing feedback to improve detection is purple. The purple trap is answer choices describing it as a separate elite team or a neutral referee; it is a cooperative exercise between red and blue. For application analysis: examining source code without executing it is SAST; testing the running application from the outside is DAST. For discovery versus proof: an automated tool listing known weaknesses is a vulnerability scan; authorized humans exploiting weaknesses to demonstrate impact is a penetration test. Identifying threats in a system still on the drawing board, perhaps using STRIDE, is threat modeling. Testers using phishing, tailgating, or impersonation to defeat human and physical controls are performing physical penetration testing.

Two final cautions. First, do not invent hybrids: there is no such thing as a scan that exploits, or a SAST tool that tests running behavior; if an answer choice blends the definitions, it is a distractor. Second, remember what all these methods share: they are authorized, scoped, and conducted to improve the organization's security, with findings reported and fixed. A scenario where the same techniques are used without permission is describing an attack, not a test. Hold the signature phrases, and the questions in this area become matching exercises: simulates attackers, detects and responds, collaborate to improve, source code without running, running application, identifies known weaknesses, exploits weaknesses, threats during design, follows an employee through the door.