The Software Development Lifecycle (SDLC) covers: Planning → Analysis → Design → Implementation → Testing → Maintenance → Retirement. Security must be integrated from the beginning — bolting it on as an afterthought is far more expensive and produces insecure software.
Waterfall vs. Agile
Waterfall — Sequential
Each phase completes entirely before the next begins. All planning → all design → all implementation → all testing → delivery. Timeline: 6 months to 3 years. Problem: if security issues are found at the end, you go back to the beginning. Security must be designed in upfront. Used traditionally by book publishers and enterprises with fixed requirements.
Agile — Iterative
Short sprints (1–4 weeks). Plan → design → build → test → deliver, then repeat with next iteration. Idea-to-product in weeks, not months. Continuous feedback allows security bugs to be fixed before they accumulate. Most modern software (SaaS, startups) is built Agile. Security frameworks must support dynamic development.
Security development frameworks
SDL
Security Development Lifecycle (Microsoft)
Microsoft's framework for integrating security into Agile development. Provides security activities for each sprint/iteration. Trains developers on threat modelling, vulnerability types, and secure code review to build security in, not bolt it on.
OWASP
Open Web Application Security Project
Community-funded open project at owasp.org. Publishes security frameworks, Top 10 vulnerability lists, secure coding guides, and testing checklists. CompTIA pulls many CySA+ questions from OWASP Top 10 lists. Review these before the exam.
Three testing environments
Unknown environment
Also: Blind testing. The analyst receives no privileged information — just the binary or application. Most similar to a real attacker's position. Dynamic testing only. Used for third-party or commercial software assessment.
Known environment
Also: Full disclosure testing. Analyst receives full source code, credentials, and architecture documentation. Most thorough — allows static code review line by line, plus dynamic testing. Used for in-house software security review.
Partially known environment
Between blind and full disclosure. Analyst gets partial information — expected inputs/outputs, a standard user credential, or a description of what the application does. Neither fully blind nor fully disclosed.
Secure coding resources — exam tip: OWASP (owasp.org) and SANS are the two key organisations for secure coding best practices. OWASP publishes Top 10 lists for web, API, mobile, and IoT vulnerabilities. CompTIA frequently sources CySA+ questions from these lists. Review OWASP Top 10 before sitting the exam.
A vulnerability that allows an attacker to run their own code on a target system without the system stopping them. The attacker's code runs in the context of whatever was running the vulnerable application — giving them those permissions.
Remote Code Execution (RCE)
A specific type of ACE where the attacker transmits the malicious code from a remote host over the network (often the internet) and causes it to execute on the target. ACE = local. RCE = over the network. RCE is generally more severe because the attacker doesn't need physical or local access.
Privilege escalation — vertical and horizontal
Vertical escalation
Moving UP the privilege hierarchy — from standard user to admin/root. The classic attack goal. A spear-phishing email triggers code that gives the attacker admin rights on the local system. From here they can install software, create backdoors, and pivot.
Horizontal escalation
Staying at the same privilege level but accessing another user's resources. "I'm a standard user but I run an exploit that lets me act as George's account and access his files." Same tier, different user. Common in multi-tenant environments.
CPU privilege rings — context for rootkits
CPU Privilege Rings — Ring 0 = Highest, Ring 3 = Lowest
Ring 0KernelOS kernel — complete control over memory, hardware, CPU. Most privileged. Kernel mode rootkit here = game over. Full system access.
Ring 1Device DriversHardware abstraction layer. Device drivers operate here. Some rootkits attach to device drivers at this level.
Ring 2Privileged CodeCertain OS services. Less common area for rootkits in modern systems.
Ring 3User ApplicationsNormal applications run here. Lowest privilege. User mode rootkits operate here — have admin rights but use OS features (registry, Task Scheduler) for persistence.
Kernel mode rootkit (Ring 0)
Embeds at Ring 0 — most dangerous. Has complete control over the entire system. Can hide files, processes, and network connections from the OS itself. The OS can't detect it because the rootkit controls the OS. Hardest to detect and remove.
User mode rootkit (Ring 3)
Operates in application/user space. Less powerful but still dangerous. Uses OS persistence mechanisms (registry auto-run, Task Scheduler, startup folders) to survive reboots. Can still hide malware at the user level. Easier to detect than kernel mode.
Rootkit key property: Rootkits modify system files — often at the kernel level — to conceal their presence. This is what makes them especially dangerous: they hide themselves and other malware. Once a rootkit is installed, the attacker can maintain persistent, hidden access — even surviving user logoffs and reboots.
Buffer overflow = responsible for over 85% of data breaches. C and C++ are particularly vulnerable because their strcpy() function does not perform boundary checking. Java, Python, and PHP automatically detect overflow conditions and halt execution — they're safer by default. This is an exam-critical fact: C/C++ = vulnerable to buffer overflow.
Buffer overflow — visual
Buffer Overflow — Adjacent Memory Corruption
NORMAL: 8-digit number fits in Buffer A (8 cells)
Buffer ABuffer B
5
5
5
1
2
3
4
·
A
B
C
D
E
F
G
H
↓ overflow with 10-digit number (410-555-1234)
OVERFLOW: 10 digits overrun Buffer A into Buffer B
4
1
0
5
5
5
1
2
→
SHL
COD
E!
·
·
·
·
·
🟢 Normal data in Buffer A🔵 Original Buffer B data🔴 Overflow data in Buffer A⚠ Shell code injected into Buffer B
Three overflow types
Buffer overflow
Data exceeds the allocated buffer and corrupts adjacent memory. If an attacker controls the overflow content, they can inject executable shell code into adjacent memory. When the program reads Buffer B expecting legitimate data, it executes the attacker's code instead. "Smash the stack" = fill with NOPs (x90) so the return address slides to the shell code.
Heap overflow
Input overwrites memory within the heap — the area used for dynamically sized variables (as opposed to the stack which holds static/local variables). Heap overflows can overwrite program objects and function pointers, leading to arbitrary code execution. Often harder to exploit than stack-based buffer overflows but still extremely dangerous.
Integer overflow
A computed value is too large for its assigned storage space, wrapping around or truncating. Example: a 2-digit field storing 90+17=107 can only hold 10 or 07. In e-commerce: a $107 charge becoming $10 or $07. Can also trigger buffer overflows and data corruption. A precursor attack to more severe exploits.
Overflow mitigations
Language choice
Use modern languages with built-in bounds checking. Java, Python, PHP automatically detect overflow conditions. C and C++ do NOT — strcpy() has no boundary checking. If you must use C/C++, you must manually implement all boundary checks.
Input validation
Validate all inputs before processing. Check length, type, format, and range before writing to a buffer. If the input is a phone number, verify it's numeric and the correct length before accepting it. The single most important secure coding practice.
ASLR
Address Space Layout Randomisation — randomises where components of a running application are placed in memory on each load. Attackers can't hardcode memory addresses in their exploits because the location of the stack, heap, and libraries changes every time. Standard in Windows 7+ and all modern OSes.
Least privilege
Run applications with the minimum permissions needed. If a process runs as a standard user (Ring 3), a buffer overflow exploit can only reach user-space memory. If it runs as kernel/root, the overflow can reach all of memory. Limiting privilege limits the damage radius of any overflow attack.
4
Race Conditions — TOCTOU & Locking Mechanisms
A race condition is a software vulnerability where the outcome depends on the order and timing of events — and those events fail to execute in the intended order. An attacker races the legitimate system to execute their code first. These are extremely difficult to detect because they often leave no log entries.
Race condition
Multiple threads attempting to write a variable at the same memory location simultaneously. An attacker inserts their operation between two legitimate operations. Since it's timing-dependent, it may be intermittent and hard to reproduce — making detection and investigation very difficult.
Dirty Cow (CVE-2016-5195)
Real-world 2016 race condition exploit affecting all Linux kernels (including Android). Exploited the Copy-On-Write (COW) memory management mechanism. Allowed local attacker to turn a read-only file mapping into a writeable one via race condition → privilege escalation. Left no system log entries. Patched but a canonical example of race conditions in the wild.
TOCTOU
Time of Check to Time of Use — a race condition targeting databases and file systems. The gap between when a resource is checked and when it is used. Attacker modifies the resource after the check but before the use. Example: e-commerce cart checked at add-to-cart, paid at checkout hours later — price/stock can change in the gap.
Race condition mitigations
Parallel processing
Reduce sequential dependencies where possible. If operations can run in parallel instead of sequentially, the time window for a race condition attack is eliminated. Minimise the gap between check and use.
Locking mechanisms
Provide exclusive access to a resource during a transaction. In databases: row/table locks prevent another transaction from modifying a record while it's being processed. In e-commerce: a five-minute checkout lock on an item reserves it exclusively. In SharePoint: "check out" a file to get exclusive write access — others can only read until you check in.
5
Improper Error Handling — Information Leakage
An error handler is code that anticipates and deals with exceptions — preventing the application from failing in a way that allows attacker code execution or information disclosure. Poor error handling is a major source of information leakage.
What improper handling enables
If a division-by-zero goes unhandled, the program may dump memory to the screen — exposing sensitive data. SQL errors may print the full query, file paths, and stack traces — giving attackers database schema information. Any unhandled exception is an attacker opportunity.
Custom error messages
Never let default error messages reach end users. Custom handlers should display a friendly user-facing message and log the technical details separately. "An error occurred — please try again" vs. "SQL Error: SELECT * FROM users WHERE id='1' failed — table users at /var/db/main.db".
Login error example
"Error: incorrect password" tells an attacker the username was correct. Now they only need to brute-force the password. Use "Error: incorrect username or password" instead — no confirmation of which field failed. Never confirm which component of a credential is wrong.
Any code used outside the main development process: code reuse (copy-pasted from Stack Overflow), third-party libraries (DLLs, shared objects), or software development kits (SDKs). If the borrowed code has vulnerabilities, you inherit them. If you're using an old version that has since been patched, you're running with known, public vulnerabilities.
Insufficient logging and monitoring
Any program that doesn't record enough detail for an analyst to investigate an incident. If attackers can act inside your application and leave no trace, you can't detect, contain, or recover effectively. Every security-relevant event should be logged with enough context to answer who/what/when/where/how.
Weak or default configurations
Applications shipping with admin/admin or root/root credentials that are never changed. Programs defaulting to run as root or local admin when they don't need to. File and directory permissions set to world-writable by default. Mitigation: use scripted installations and baseline configuration templates to enforce secure defaults immediately at install time.
7
Platform Best Practices — Client/Server, Web, Mobile & Embedded
Client/Server
Three attack surfaces: client (workstation must be patched and scanned), network (encrypted transport), server (hardened, patched, validated). A completely secure application running on a malware-infected client is insecure. All three must be secured. Server-side must use input validation for all data from clients.
Web applications
Generic web browser as client — no install. Multi-tier: front-end logic + back-end database. Modern apps may use microservices or serverless designs. OWASP Top 10 is the primary reference for web application vulnerabilities. Input validation is critical — prevents SQL injection, XSS, buffer overflows. Validate ALL data coming from clients.
Mobile applications
Deployed on smartphones/tablets. More susceptible to insecure authentication, authorisation, and confidentiality controls. Vulnerable to open WiFi attacks — even a secure mobile app can be compromised if data goes over an unencrypted public WiFi network. Always use TLS for mobile data in transit.
Embedded applications
Dedicated hardware platforms (smart TVs, ICS, SCADA, medical devices). Traditionally not security-focused during development. Old technologies, rarely updated. OWASP has an embedded systems security guide. If responsible for embedded development, treat security as a first-class requirement from day one.
Firmware
Embedded code at first startup (BIOS/UEFI). Controls hardware and bootstraps the OS. If attackers compromise firmware, they have complete hardware-level control — below the OS, invisible to antivirus. Must use trusted firmware (UEFI Secure Boot/Measured Boot — see Ch.28).
System-on-a-Chip (SoC)
CPU+memory+GPU+networking+storage all on one chip. Used in mobile devices. Manufacturers use IP blocks (pre-built logic gate configurations) for individual functions — often supplied by third parties. IP block code reuse introduces unknown third-party vulnerabilities. Supply chain trust is critical for SoC.
Input validation = most frequently correct answer for software vulnerabilities. When you see a question about preventing SQL injection, XML injection, buffer overflows, or any attack that involves accepting data from a client/user and processing it server-side — input validation is the answer. It covers the widest range of application vulnerabilities. On the exam, when you see input validation as an option, it's correct about 75% of the time.
8
Metasploit Framework — Structure & Key Concepts
Metasploit is a multi-purpose penetration testing framework pre-installed on Kali and Parrot Linux. Launch with msfconsole. It organises its modules as: type / platform / service / module_name. Example: exploit/windows/smb/ms17_010_psexec = exploit targeting Windows over SMB using EternalBlue.
Exploits (~2,200)
Code that delivers a payload against a specific vulnerability on a specific target OS/service. Select with use exploit/...
Auxiliaries (~1,100)
Scanners, sniffers, fuzzers, spoofers — non-exploit tools. Can replace Nmap for port scanning.
Post (~400)
Post-exploitation tasks — maintain persistence, cover tracks, collect data, pivot after compromising a host.
Payloads (~600)
What executes after the exploit lands — bind shell, reverse shell, Meterpreter. Set with set payload ...
Encoders (45)
Encode payloads to bypass IDS/IPS, firewalls, and AV. Ensure payload arrives intact and undetected.
NOPs (10)
No-operation padding — keep payload sizes consistent. Also used in NOP sled (smash-the-stack) techniques.
Evasions (9)
Specific techniques to bypass defensive systems. Complements encoder functionality for advanced evasion.
Basic workflow
1. Scan
Discover the target. Use Nmap (nmap -sV <target_ip>) to identify open ports and running services. Find vulnerable software versions to match against Metasploit modules.
2. Select exploit
Search and load the exploit.search <keyword> to find matching modules. use exploit/<path> or use the module number to load it.
3. Configure
Set options.options shows required fields. set RHOST <target_ip> to set the remote target. set RPORT <port> if not default.
4. Set payload
Choose what happens after exploit.show payloads lists compatible payloads. set payload <path> to load. RHOST/RPORT (target) and LHOST/LPORT (listener) must be set.
5. Run
Execute the attack. Type run to launch. If successful, a session opens. Use session commands. Background with Ctrl+Z. sessions -l lists active sessions. sessions <n> to re-enter.
Exam
Quick Reference Cheat Sheet
SDLC & testing
Waterfall = sequential, all phases complete before next, 6mo–3yr cycles. Agile = iterative sprints (1–4 weeks), rapid feedback. Security frameworks: SDL (Microsoft, Agile-integrated) and OWASP (community, owasp.org, Top 10 lists). Testing: Unknown = blind (no info). Known = full disclosure (source code + creds). Partially known = some info. CompTIA pulls from OWASP Top 10 — review before exam.
Execution & escalation
ACE = Arbitrary Code Execution (attacker runs code locally). RCE = Remote Code Execution (over network). Vertical privilege escalation = user → admin/root. Horizontal = user → different user at same level. Rootkits: Kernel mode (Ring 0, most dangerous, hides from OS) vs. User mode (Ring 3, uses registry/Task Scheduler for persistence). Ring 0 = kernel, Ring 3 = applications.
Overflow attacks
Buffer overflow: data exceeds buffer, corrupts adjacent memory (85%+ of breaches). C/C++ = vulnerable (no bounds checking). Java/Python/PHP = safe (built-in detection). Heap overflow: overwrites dynamically-sized variables in heap. Integer overflow: result too large for storage, can chain to buffer overflow. Mitigations: ASLR (randomise memory layout), input validation, least privilege, modern languages.
Race conditions
Timing-dependent vulnerability — attacker races legitimate operation. TOCTOU = Time of Check to Time of Use (the gap between validation and use). Dirty Cow (2016) = Linux race condition, local privilege escalation via Copy-On-Write, left no log entries. Mitigations: parallel processing (remove sequencing), locking mechanisms (exclusive access during transactions), re-check at time of use for critical resources.
Error handling & design vulns
Improper error handling: default errors leak SQL queries, file paths, stack traces. Custom error messages prevent info leakage. Never confirm which login field is wrong ("incorrect password" = username confirmed). Insecure components: code reuse, 3rd-party libs, old SDKs inherit vulnerabilities. Insufficient logging: can't investigate if you don't log. Default configs: change all default credentials immediately on install.
Platform best practices
Client/server: 3 attack surfaces (client + network + server — all must be secured). Web: multi-tier, OWASP Top 10, microservices/serverless. Mobile: open WiFi risk, use TLS always, insecure auth common. Embedded: not security-focused, rarely updated — isolate/segment. Firmware: bootstrap target, controls hardware, UEFI Secure Boot. SoC: IP block code reuse = inherited third-party vulnerabilities. Input validation = answer for ~75% of software vuln questions.
Metasploit framework
Launch: msfconsole. Components: Exploits (attack code), Auxiliaries (scanners/sniffers), Post (post-exploitation), Payloads (what runs after exploit), Encoders (bypass detection), NOPs (padding), Evasions (bypass defences). Workflow: Nmap scan → use exploit/... → set RHOST → set payload → run → session opens. EternalBlue: exploit/windows/smb/ms17_010_psexec = CVE-2017-0144 (WannaCry). Metasploitable 2 = intentionally vulnerable practice VM.