Why do so many security breaches happen through software that was supposedly 'working fine'? The answer is that security was bolted on at the end, not baked in from the start. For the SSCP exam, you must understand how to integrate security activities into every phase of building software, so that vulnerabilities are caught before they ever reach a live system.
Jump to a section
A simple way to picture Secure Software Development and Lifecycle
Have you ever watched a friend try to renovate a house without any plans? They start by knocking down a wall, then realise it was load-bearing, so the roof starts to sag. They patch it with a wooden beam, but now the wiring is in the way, so they just tape some extra cable to the outside of the wall. Then they paint over everything to hide the mess. The house looks okay from a distance, but six months later, the roof leaks, the lights flicker, and the floorboards are rotting.
Now imagine a professional renovation. Before a single hammer is swung, the builder draws detailed architectural plans, gets permits, and checks for gas pipes and wiring. During construction, every new wall is inspected before it is closed up. After the house is finished, the builder hands you a full set of as-built drawings and a maintenance guide. The upfront planning and constant double-checking cost more time and money at the start, but the house lasts decades without disaster.
Secure software development works exactly the same way. The 'house' is your application, the 'walls' are features, and the 'hidden gas pipes' are security vulnerabilities. If you skip the planning and security checks, you get software that 'works' today but collapses under a hacker's weight tomorrow. The entire concept of a secure software development lifecycle is about applying that professional renovation mindset to code.
The phrase 'Secure Software Development and Lifecycle' might sound intimidating, but it is just a fancy way of saying: 'Build software with security in mind from the very first idea, through coding and testing, all the way to when the software is retired.' In IT, we call this the Secure Software Development Lifecycle (SSDLC). It is a framework that adds security practices to the traditional steps of building software.
To understand why this matters, you first need to know what happens when security is an afterthought. In the old days, and still in many rushed projects, developers would write all the code, test it for basic functionality (like 'does the login button work?'), and then toss the software to a security team a week before launch. The security team would find dozens of problems, but fixing them would delay the launch. So management often decided to launch anyway and 'fix it later'. That later never came, and hackers would eventually find those holes.
The SSDLC fixes this by inserting security checks at every stage. Let us walk through the typical phases of the SSDLC, which maps to the traditional 'Software Development Lifecycle' (SDLC).
Phase 1: Requirements In this first phase, you decide what the software should do. In a secure lifecycle, you also decide what it must NOT do. For example, if you are building a banking app, a requirement might be 'users can transfer money'. The secure requirement would be 'users can only transfer money to accounts they own, and all transfers over £100 must require a second approval.' You also perform a 'security risk assessment' here, which means listing possible bad things that could happen (like someone stealing a password) and planning how to stop them.
Phase 2: Design This is where you draw the blueprints. Architects create diagrams showing how different parts of the software talk to each other. A security-focused design will include things like 'encryption in transit' – meaning data is scrambled when it travels between the app and the server – and 'least privilege' – meaning each part of the software only has access to the bare minimum data it needs to do its job. They will also create a 'threat model', which is a structured way of thinking like a hacker to spot flaws in the design on paper.
Phase 3: Implementation (Coding) Now the developers actually write the code. Security at this stage means following 'secure coding practices'. For example, never trusting user input. If a user types their name into a field, you must check it is actually a name and not a piece of malicious code designed to break your database. This checking is called 'input validation'. Developers also use 'static application security testing' (SAST) tools, which act like a spell-checker for security flaws in the code as they type.
Phase 4: Testing After the code is written, testers try to break it. In the security version, this includes 'dynamic application security testing' (DAST), where automated tools try to hack the running software. It also includes 'penetration testing', where human experts manually try to find vulnerabilities. All bugs – including security bugs – are logged and assigned a severity. Critical bugs must be fixed before the software is released.
Phase 5: Deployment This is the 'go live' stage. Even here, security matters. You need to configure the server securely, ensure default passwords are changed, and set up logging to record who accesses the system. Secure deployment often uses a 'change management' process, meaning every change to the live system must be approved and documented.
Phase 6: Maintenance and Disposal Software is never truly finished. You must monitor it for new vulnerabilities, apply security patches, and eventually, when the software is replaced, securely wipe all data. Simply deleting files is not enough – you need to 'sanitise' the storage.
The whole point of the SSDLC is to catch defects early. It is well-known in IT that fixing a bug during the requirements phase costs pennies, but fixing the same bug after the software is live can cost thousands and damage your company's reputation. The SSCP exam expects you to know these phases and which security activity happens in each phase.
Define Security Requirements
This step happens at the very start, alongside defining what the software should do. You list all security needs, such as 'passwords must be hashed' and 'user data must be encrypted when stored'. This ensures security is not an afterthought.
Perform Threat Modelling
During the design phase, you use a structured approach (like STRIDE or PASTA) to think like an attacker and identify potential weaknesses in the architecture. For example, you might identify that an attacker could intercept data between the user's phone and the server, leading to a requirement for encryption in transit.
Conduct Code Reviews and Static Analysis
While developers write code, they must review each other's work for security flaws. Automated SAST tools scan the code for common vulnerabilities like SQL injection and buffer overflows. This catches problems early, when they are cheap to fix.
Run Dynamic and Penetration Testing
Before the software is released, testers run DAST tools that attack the live application, and human penetration testers try to break in using the same methods real attackers use. This step validates that all earlier security controls are working as intended.
Apply Secure Configuration and Change Management
When deploying the software, you must harden the server by disabling unnecessary services, changing default passwords, and enabling logging. All changes to the live environment must go through a formal change management process to prevent unauthorised modifications that could introduce vulnerabilities.
Monitor, Patch, and Dispose Securely
Post-deployment, you continuously monitor for new vulnerabilities and apply patches. When the software is eventually retired, you must securely wipe all data from storage devices to prevent data leaks. This final step is part of the maintenance and disposal phase of the SSDLC.
Imagine you work as a junior security analyst at a mid-sized e-commerce company called 'ShopLocal'. The company wants to launch a new mobile app for ordering groceries. In a non-secure world, the developers would start coding immediately. But your manager insists on following the SSDLC. Here is what actually happens step by step.
Step 1: The kick-off meeting The project manager, two developers, a database administrator, and you (the security person) sit down. You ask: 'What data will the app collect?' The answer: customer names, addresses, credit card numbers, and order history. You immediately identify a security requirement: credit card numbers must never be stored in plain text. They must be encrypted (scrambled) both when stored and when sent over the internet. This requirement is written into the project document.
Step 2: Design review A week later, the lead developer shows a diagram of the app's architecture. It shows a user's phone talking to a web server, which talks to a database. Your job is to spot risks. You notice that the diagram shows the database directly accessible from the internet. That is a huge red flag. You mark it as a 'high-severity finding' and recommend a firewall between the web server and the database. The team updates the design.
Step 3: Coding with guardrails The developers start coding. You set up a SAST tool that automatically scans every piece of code before it is merged into the main project. One day, the tool flags a piece of code where the developer built an SQL query by directly combining text from a user's search box. That is a classic 'SQL injection' vulnerability. You explain to the developer how to use 'parameterised queries' instead, which treats user input as data, not as executable code. The developer fixes it in ten minutes, instead of finding it during a hack after launch.
Step 4: The security test drive Before the app is released, you run a DAST tool that simulates hundreds of hacking attempts. It finds that the 'forgot password' feature allows unlimited guesses. An attacker could try every possible reset code. You add a 'rate limit' – the system only allows three attempts per minute. You also schedule a penetration test with an external expert. The expert finds one medium-risk issue: the app sends a session token (a temporary digital ID) in the URL instead of in a secure header. The developers fix that before launch.
Step 5: Going live with paranoia On launch day, you ensure that the server has no default passwords. You configure logging to record every login attempt and every payment transaction. You set up an alert so that if someone tries to log in from a different country five minutes after a login from the UK, an email is sent to the security team.
Step 6: Ongoing maintenance After launch, you subscribe to a vulnerability feed. Three months later, a critical flaw is discovered in the 'Encryption library' the app uses. You identify which systems are affected, test a patch in a safe environment, and deploy it to production within 48 hours. The app never gets compromised.
In this real-world scenario, you did not just 'add security at the end'. You were involved from the first meeting to the final patch. That is the SSDLC in action.
The SSCP exam loves to test your understanding of when specific security activities happen in the SDLC. You will get scenario questions that describe a phase (e.g., 'a developer is writing code') and ask which security activity should occur. The key is to memorise which activities map to which phase.
Phase-specific activities the exam tests: - Requirements phase: Risk assessment, security requirements definition, privacy impact assessment. - Design phase: Threat modelling, architecture review, security design principles (like defence in depth, least privilege). - Implementation phase: Static code analysis (SAST), secure code reviews, input validation, use of approved libraries. - Testing phase: Dynamic analysis (DAST), penetration testing, fuzz testing (feeding random data to find crashes), vulnerability scanning. - Deployment phase: Secure configuration management, hardening (disabling unnecessary services), change management. - Maintenance phase: Patch management, vulnerability monitoring, secure disposal of data.
Common traps in the exam: - They will present a scenario where a developer finds a bug during coding and ask what should be done. The trap answer is 'fix it now and skip the testing phase'. The correct answer is 'log it in the defect tracker and fix it in the next cycle following the change management process'. - They will ask about 'code review' and try to confuse you with 'peer review' as a non-security activity. The exam considers both peer code review (looking for logic errors) and security code review (looking for vulnerabilities) as valid, but the question will specify 'security code review'. - They will list a mix of activities and ask which belong to the testing phase. Watch out for 'static analysis' being listed in the testing phase – it belongs in implementation. 'Static' means looking at the code without running it, which happens during coding.
Concepts they love to test: - The difference between SAST (white-box testing, done during coding) and DAST (black-box testing, done on a running application). - The 'shift left' concept – the idea of moving security earlier in the lifecycle to save cost and time. - The principle of 'least privilege' – every user and every piece of code should have only the permissions necessary to do its job. - The concept of 'defence in depth' – using multiple layers of security (e.g., firewall, encryption, strong passwords) so that if one layer fails, others still protect the system. - The requirement for 'separation of duties' – the person who writes the code should not be the only person who approves it for release.
Exam question pattern: You are likely to see a question like: 'A security analyst is reviewing the architecture of a new application. Which phase of the SDLC is this activity most associated with?' The answer is the Design phase. Another pattern: 'Which tool would a developer use to identify vulnerabilities in source code before compilation?' The answer is SAST. If the question says 'running application', the answer is DAST.
The wrong answer choices often include unrelated activities like 'vulnerability scanning of the network' (which is an operations task) or 'user acceptance testing' (which is a business function, not security).
The Secure Software Development Lifecycle (SSDLC) integrates security activities into every phase of building software, from requirements to disposal.
Fixing a security vulnerability during the design phase costs a fraction of what it costs to fix the same vulnerability in production.
Static Application Security Testing (SAST) analyses source code for vulnerabilities without running the program, and is performed during the implementation phase.
Dynamic Application Security Testing (DAST) analyses a running application for vulnerabilities and is performed during the testing phase.
The principle of least privilege means every user and every component of a system should have only the permissions necessary to perform its function.
Threat modelling is a structured activity performed during the design phase that identifies potential security threats and defects before any code is written.
Change management ensures that every modification to a production system is documented, approved, and tested before it is applied.
Input validation is a secure coding practice that prevents attackers from injecting malicious code by rejecting any data that does not match expected patterns.
These come up on the exam all the time. Here's how to tell them apart.
SAST (Static Application Security Testing)
Performed on source code without running the program.
Used during the implementation (coding) phase.
Catches vulnerabilities like SQL injection in the code logic.
DAST (Dynamic Application Security Testing)
Performed on a running application from the outside.
Used during the testing phase after the app is built.
Catches vulnerabilities like misconfigured servers that only appear at runtime.
Requirements Phase
Focuses on what the software must do and what it must NOT do from a security standpoint.
Output is a list of security requirements (e.g., encrypt all credit card numbers).
Activity: security risk assessment and privacy impact assessment.
Design Phase
Focuses on how the software will be structured to meet those requirements.
Output is a blueprint of the system architecture and data flow.
Activity: threat modelling to find design-level flaws.
White-Box Testing
Tester has full knowledge of the internal code and architecture.
Example: SAST and manual code reviews.
Can find hidden logic errors and backdoors.
Black-Box Testing
Tester has no knowledge of the internal code.
Example: DAST and penetration testing from an outsider's perspective.
Simulates a real attacker who does not have access to source code.
Least Privilege
A principle that grants only the minimum permissions needed.
Focuses on limiting damage if an account is compromised.
Implemented through user roles and access control lists.
Defence in Depth
A strategy that uses multiple overlapping security controls.
Focuses on ensuring that no single point of failure can break security.
Implemented through layers like firewalls, encryption, and antivirus.
Change Management
Process for controlling all modifications to a system (features, config, fixes).
Includes approval, documentation, and rollback planning.
Applies to every change, not just security updates.
Patch Management
Process for applying security updates (patches) to software.
Focuses on fixing known vulnerabilities in a timely manner.
A subset of change management, specifically for security fixes.
Mistake
Security is only the responsibility of the security team, not the developers.
Correct
In a secure lifecycle, every person involved in building the software – including developers, testers, and project managers – shares responsibility for security. The security team guides and audits, but the developer must write secure code.
Beginners often think security is a separate 'gate' at the end, because that is how it works in many non-IT industries (e.g., a security guard checks bags at the door). But software security must be part of the building process itself.
Mistake
A penetration test at the end of the project is enough to make the software secure.
Correct
Penetration testing is important, but it only finds a snapshot of vulnerabilities at one point in time. Many flaws, especially design flaws, are nearly impossible to fix after the software is built. Security must be integrated from the start.
This misconception persists because penetration testing is visible and dramatic ('hackers trying to break in'). It feels like a concrete safety check. The invisible work of secure design and code review seems less exciting, so beginners undervalue it.
Mistake
If the software passes all functionality tests, it is probably secure.
Correct
Functionality tests check if the software does what it is supposed to do. Security tests check if the software does what it is NOT supposed to do (e.g., let an attacker access another user's data). A program can work perfectly and still be deeply insecure.
Non-IT people are used to testing things by trying their normal use – a car starts, a toaster toasts. They do not naturally think about someone maliciously trying to misuse the product. This is a blind spot that the SSCP exam explicitly tests.
Mistake
Fixing a security bug after the software is live is just as easy as fixing it during development.
Correct
Fixing a security bug in production is significantly more expensive and time-consuming. It requires emergency change requests, regression testing, downtime, and often patching on hundreds of servers. The cost can be 30 to 100 times higher than fixing it during design.
People who have never managed software releases do not understand the complexity of a live production environment. They think all code changes are equally simple. The exam uses this concept to justify why 'shift left' (early security) is a best practice.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
SDLC is the general process of building software (plan, design, code, test, deploy, maintain). SSDLC is exactly the same process but with security activities added to each phase, such as threat modelling in design and security testing in the testing phase.
Shift left means moving security activities earlier in the software development lifecycle. Instead of waiting until the testing phase to look for vulnerabilities, you start finding and fixing them during the design and coding phases. This reduces cost and risk.
No, the SSCP does not expect you to be a programmer. You need to understand the security activities in each phase of the lifecycle and the concepts like SAST, DAST, threat modelling, and least privilege. You will not be asked to write or fix actual code.
A penetration test is a manual or automated attempt to hack your own software to find vulnerabilities. It is not enough because it only looks at the final product; it cannot find flaws in the design or logic that were built in from the start. You need security activities in all phases, not just a final test.
Defence in depth means using multiple layers of security controls so that if one layer fails, another layer still protects the system. For example, a firewall at the network, encryption on the data, and strong passwords on user accounts create three separate barriers for an attacker.
Input validation is the practice of checking that any data a user provides to a program (like text in a search box) matches what is expected. It is important because attackers can send malicious data (e.g., SQL commands) to trick the program into doing something harmful, like leaking the entire database.
You've finished Secure Software Development and Lifecycle. Continue through the SSCP study guide to build a complete picture of the exam.
Done with this chapter?