SAST, DAST, Penetration Testing & Security in the SDLC
You're familiar with testing code to make sure it does what it's supposed to do — passing the right inputs and checking for the right outputs. That's functional testing. Security testing is fundamentally different.
Functional testing asks: "Does the system do what it should?"
Security testing asks: "Can the system be made to do what it shouldn't?"
A functional test checks that a login form accepts the correct username and password. A security test checks whether you can log in without a correct password — using SQL injection, a bypassed session check, or a stolen cookie. Normal users don't try to break systems. Attackers do. Security testing requires thinking like an attacker.
' OR '1'='1 as a usernameSecurity testing requires dedicated methods. The NESA syllabus requires you to know three: SAST, DAST, and penetration testing.
Static Application Security Testing (SAST) analyses source code, bytecode, or binaries for security vulnerabilities without executing the program. The application is examined while it is "at rest" — think of it as a security-focused code review performed by an automated tool.
Static = the program is not running. The analysis is done on the code itself.
SAST tools scan the code looking for known dangerous patterns, misconfigurations, and vulnerability signatures:
eval(), innerHTML, functions known to be unsafeimport hashlib
# SAST FLAG: hardcoded secret
API_KEY = "sk-abc123def456"
def get_user(username):
# SAST FLAG: SQL injection risk — user input concatenated into query
query = "SELECT * FROM users WHERE username = '" + username + "'"
return db.execute(query)
def hash_password(password):
# SAST FLAG: MD5 is cryptographically broken, use bcrypt or Argon2
return hashlib.md5(password.encode()).hexdigest()| Tool | Language Support | Common Use |
|---|---|---|
| SonarQube | 25+ languages | Enterprise CI/CD pipelines |
| Bandit | Python | Lightweight local scanning |
| ESLint (security plugins) | JavaScript | IDE integration, pre-commit checks |
| Semgrep | Multi-language | Custom rule-based scanning |
| GitHub Advanced Security | Multi-language | Integrated into GitHub repos |
Dynamic Application Security Testing (DAST) tests a running application by sending it inputs and analysing the responses, without access to the source code. The application is tested from the outside, as an attacker would approach it.
Dynamic = the program is running. The analysis is done against the live system.
DAST is sometimes called black-box testing because the tester has no visibility into the internal code — only the external behaviour matters.
A DAST tool acts as an automated attacker. It systematically:
Content-Security-Policy, X-Frame-Options, etc.| Tool | Type | Common Use |
|---|---|---|
| OWASP ZAP | Free, open source | Automated scanning and manual testing proxy |
| Burp Suite | Free/paid | Professional web application testing |
| Nikto | Free, open source | Web server misconfiguration scanning |
| Acunetix / Invicti | Commercial | Enterprise automated scanning |
| SAST | DAST | |
|---|---|---|
| What it analyses | Source code, without running | Running application, from outside |
| When it runs | During development, on commit | After deployment, against a test instance |
| Source code required? | Yes | No |
| Running app required? | No | Yes |
| Finds | Code-level flaws, hardcoded secrets, dangerous patterns | Runtime vulnerabilities, config issues, behavioural flaws |
| False positives | Higher | Lower |
| HSC keyword | "White-box" (has access to code) | "Black-box" (no access to code) |
Best practice: Use both. SAST catches issues early in development; DAST validates the deployed system. Together they provide coverage that neither achieves alone.
Penetration testing (or "pen testing") is an authorised, simulated cyberattack on a system, conducted by security professionals to evaluate how well the system can withstand real attack techniques. Unlike automated tools, penetration testing involves human expertise, creativity, and judgement.
The key word is authorised. Without explicit written permission from the system owner, a penetration test is a crime. The same techniques used in pen testing are used by malicious attackers — the only difference is the authorisation.
Gather information about the target: domain names, IP ranges, technologies used, employee names, email patterns. Entirely passive — no direct interaction with the target system.
Actively probe the target to map open ports, running services, software versions, and potential entry points. Tools: Nmap (port scanning), Nessus (vulnerability scanning).
Attempt to exploit discovered vulnerabilities to gain unauthorised access. Documents exactly what an attacker could achieve and how. Tools: Metasploit, Burp Suite, manual techniques.
Deliver a detailed report of all findings: what was found, how it was exploited, what data or access was obtained, and remediation recommendations ranked by severity.
These terms describe how much information the tester has about the system being tested. They apply to penetration testing specifically, but also to testing in general.
| Type | Tester Knows | Simulates | Advantage |
|---|---|---|---|
| Black box | Only what is publicly visible (URL, company name). No source code, no credentials. | An external attacker with no insider knowledge | Most realistic simulation of an outside attacker |
| White box | Full access to source code, architecture diagrams, credentials, documentation | An insider threat, or thorough audit with full access | Most thorough; can find deeply buried vulnerabilities |
| Grey box | Partial information — e.g., user-level credentials but no source code | An authenticated user attempting to escalate privileges | Balanced; more efficient than black box, more realistic than white box |
The Open Web Application Security Project (OWASP) publishes the Top 10 — a regularly updated list of the most critical security risks to web applications, based on real-world data from security experts globally. It serves as a standard checklist for penetration testers and a guide for developers.
The most recent OWASP Top 10 includes:
You've now studied items 2, 3, 6, and 7 in detail. Penetration testers use this list as a systematic framework to ensure comprehensive coverage.
Penetration testing without authorisation is a criminal offence under the Cybercrime Act 2001 (Cth) in Australia. All penetration testing must be preceded by a signed scope agreement (sometimes called a "rules of engagement" document) that specifies exactly what systems may be tested, what techniques are permitted, and the timeframe of testing.
A penetration tester who goes beyond the agreed scope — even with good intentions — may face legal consequences.
Security testing is not a single step at the end of development. The NESA syllabus connects security to the SDLC — security activities belong at every phase.
| SDLC Phase | Security Activity |
|---|---|
| Requirements | Define security requirements; identify assets and threats; perform threat modelling |
| Design | Review architecture for security weaknesses; apply Privacy by Design principles; plan authentication and authorisation model |
| Development | Developers follow secure coding practices; SAST tools run on every commit to catch issues immediately |
| Testing | DAST runs against the deployed test environment; security-focused functional testing of auth, access control, and input handling |
| Deployment | Server hardening; security configuration review; penetration testing of the production-ready system |
| Maintenance | Ongoing dependency auditing; monitoring and logging; periodic re-testing as the system evolves |
"Shift left" means moving security activities earlier in the development lifecycle — towards the left of a timeline that runs from design to deployment.
The principle is economic: the earlier a vulnerability is found, the cheaper it is to fix. A vulnerability caught by a SAST tool during development costs a developer an hour to fix. The same vulnerability found after deployment by a penetration tester might require architectural changes, a redeployment, and a public disclosure process.
DevSecOps: A culture and set of practices where security is integrated into every stage of DevOps — not added at the end. Security is "everyone's responsibility," not the security team's problem to solve after the code is written.
SAST analyses source code without executing the program. It can run during development, before the application is built, catching issues at their source. An advantage is early detection — running on every commit means vulnerabilities are found at the cheapest point to fix. SAST can find hardcoded secrets embedded in source files, which DAST cannot detect because secrets in source code may not be visible in the application's runtime responses.
DAST tests a running application by sending malicious inputs and analysing responses, without access to source code. An advantage is that it finds runtime vulnerabilities that only appear when the application is actually operating, including server misconfiguration and behavioural flaws that SAST cannot detect from code alone.
Black box testing is performed with no knowledge of the internal system — the tester only knows what is publicly visible, such as the application's URL. White box testing is performed with full access to source code, architecture documentation, and credentials.
Black box testing better simulates an external attacker because it replicates the attacker's perspective: no insider knowledge, only what can be discovered from outside the system. This makes the findings directly relevant to real-world threats from unknown attackers, though it may miss vulnerabilities that only become apparent when the code is examined directly.
"Shift left" refers to integrating security testing earlier in the software development lifecycle — moving security activities toward the beginning of the development timeline rather than treating them as a final-stage concern.
It is more cost-effective because vulnerabilities become progressively more expensive to fix as development progresses. A vulnerability discovered by a developer's SAST tool during coding requires a small code change. The same vulnerability discovered after deployment by a penetration tester may require architectural redesign, redeployment, user notification, and potential regulatory reporting — a significantly greater cost in time, money, and reputation.
Write HSC-style answers (3–5 sentences each) for the following questions. These are the type of questions that appear in the actual HSC exam.
Q1: Think about which testing method can run without a deployed application, and which requires one. Where do they fit in the SDLC?
Q2: The Cybercrime Act 2001 (Cth) is the relevant Australian legislation. The key issue is that attack techniques are identical whether authorised or not.
Q3: Imagine fixing a bug the day you wrote it vs. fixing it six months after the application has launched and is being used by customers.
Look up one real-world security breach from the last five years. Write a short paragraph (4–6 sentences) identifying:
Come prepared to discuss it at the start of next lesson.