P4-8. SSE Traditional Software Engineering – Deep Dive

 

Video Podcast

P4. SSE P2. SSE Traditional Software Engineering – Deep Dive

Executive Briefing

1. Introduction to Secured Software Engineering

Secured Software Engineering (SSE) is a comprehensive and proactive methodology that integrates security measures throughout the entire software development lifecycle (SDLC). Unlike traditional approaches where security is a late-stage concern, SSE embeds security "from initial planning to final release," making it an intrinsic part of the application's fabric. This approach is closely associated with the DevSecOps movement.

The ultimate goal of SSE is to uphold the Confidentiality, Integrity, and Availability (CIA triad) of information, ensuring software is resilient against attacks and vulnerabilities. The motivations for adopting SSE extend beyond technical best practices, addressing crucial business and regulatory imperatives:

• Brand and Reputation Damage: Cyber attacks lead to loss of customer trust.
• Financial Repercussions: Include lawsuits, customer loss, and revenue decline.
• Regulatory Fines: Non-compliance with data protection laws can result in heavy penalties.

By embedding security, organisations can avoid negative outcomes, protect against business disruptions, and maintain a positive public image.

2. The Software Engineering Process

The traditional software engineering process involves a structured set of activities:

1. Requirements Engineering: Gathering, specifying, validating, and verifying stakeholder needs.
2. Software Design & Architecture: Defining architectural styles, module design, and applying design patterns.
3. Software Construction: Programming, code quality practices, and build/integration.
4. Software Testing & Verification: Unit, integration, system, and acceptance testing, often with automation.
5. Software Maintenance & Evolution: Corrective, adaptive, perfective, and preventive maintenance.
6. Configuration & Change Management: Version control, release/deployment management, and change control.
7. Software Engineering Process & Project Management: Applying process models (e.g., Waterfall, Agile), planning, estimation, and risk management.
8. Software Quality Assurance & Metrics Management: QA activities, metrics (defect density, code coverage), and continuous improvement.

3. Evolution from SDLC to SSDLC

The Software Development Life Cycle (SDLC) traditionally encompasses six key phases: Planning and Requirement Analysis, Design, Implementation, Testing, Deployment, and Maintenance. Its purpose is to develop software systematically, allowing for effective progress tracking and quality control.

The Secured Software Development Life Cycle (SSDLC) represents a crucial evolution, embodying a "Shift-Left" philosophy:

• Primary Focus: Traditional SDLC focuses on functional and business requirements; SSDLC unifies functional, business, security, and compliance requirements.
• Timing of Security: Traditional SDLC considers security late-stage; SSDLC integrates security from the very beginning.
• Key Activities: SSDLC adds security risk assessment, threat modelling, compliance analysis, and abuse case definition to traditional activities.
• Participants: SSDLC includes Security Engineers, Legal/Compliance Officers, and Data Protection Officers alongside traditional roles.
• Core Output: Traditional SDLC yields Functional Requirements Documents; SSDLC produces a "Security Requirements Specification (SRS) that integrates security controls, threat models, and risk assessments, defining 'how the system must operate securely'."
• Underlying Philosophy: Traditional SDLC asks "How can we build a system that meets the functional specification?"; SSDLC asks "How can we build a system that is secure by design, and how might an attacker try to break it?".

The principle "A stitch in time saves nine" encapsulates the SSDLC's proactive approach, making early detection and remediation more cost-effective.

4. Integrating Security across SSDLC Phases

The SSDLC integrates security considerations and responsibilities across every phase:

• Requirements Phase:
• Purpose: Understand user needs and define system expectations, including security.
• Security Influence: Product Owners ensure security requirements align with business, CISOs define risk appetite, Business Analysts translate security needs, and Risk Officers ensure regulatory coverage (e.g., GDPR, PCI-DSS).
• Security Decisions: Risk acceptance criteria, security budget allocation.
• Design Phase:
• Purpose: Define system architecture, modules, and data flow with security in mind.
• Security Influence: Security Architects design controls and select encryption standards, Solutions Engineers implement security patterns, Data Architects implement data protection, and UX Leads prevent security-usability conflicts.
• Security Decisions: Cryptographic standards, authentication frameworks.
• Implementation Phase:
• Purpose: Translate secure design into working code.
• Security Influence: Development Teams implement secure coding practices (e.g., OWASP Top 10), DevOps Engineers enforce security gates in pipelines, and Security Champions resolve findings and train developers.
• Security Decisions: Vulnerability remediation timelines, tool configurations.
• Testing Phase:
• Purpose: Verify software works as intended, meets requirements, and is bug-free, including security.
• Security Influence: Penetration Testers exploit vulnerabilities, QA Leads integrate security tests, Project Managers track remediation, and Auditors verify compliance.
• Security Decisions: Release approval, vulnerability risk acceptance.
• Deployment Phase:
• Purpose: Release secure software for real-world use.
• Security Influence: Operations Managers enforce hardening standards, IAM Specialists implement least privilege, Network Engineers configure security, and Release Managers enforce change control.
• Security Decisions: Deployment approvals, emergency rollback triggers.
• Maintenance Phase:
• Purpose: Update, fix, and optimize software post-release based on feedback and performance, including security incidents.
• Security Influence: SOC Analysts monitor and respond to threats, Support Leads manage security requests, Compliance Managers conduct audits, and Executive Sponsors approve major security investments.
• Security Decisions: Patch prioritization, incident response actions.

5. DevSecOps: The Evolution of DevOps

DevOps aimed to break down silos between Development and Operations, accelerating the software delivery lifecycle through collaboration, communication, and CI/CD. However, security was often a late-stage "gatekeeper" process, becoming a bottleneck to agility.

DevSecOps is the evolution that "bakes security into every phase of the secured software development lifecycle (SSDLC)." It shifts security from a late-stage gatekeeper to a shared responsibility.

Key features of DevSecOps:

• Focus: Expands DevOps' speed and quality to include security.
• Security Integration: Embedded throughout SSDLC, not just post-development
• Team Composition: Adds Security specialists to Dev + Ops.
• Testing: Includes security testing (SAST, DAST, IAST) alongside functional and performance.
• Tools: Integrates security scanners and compliance tools with CI/CD and version control.

Core principles of DevSecOps include: Shift-Left Security, Automation, Collaboration, Continuous Monitoring, and Compliance as Code.

6. Continuous Integration, Continuous Delivery, and Continuous Security (CI/CD/CS)

The technical engine of DevSecOps is the integrated CI/CD/CS pipeline:

• Continuous Integration (CI): Automates integrating code changes into a shared repository. Each commit triggers automated builds and tests.
• Process: Code Commit -> Automated Build -> Automated Testing (Unit, Integration) -> Feedback Loop.
• Goals: Catch bugs early, ensure codebase stability, reduce integration conflicts.
• Continuous Delivery/Deployment (CD): Automates deployment of validated code to production.
• Process: Artifact Repository -> Environment Deployment (Staging, Production) -> Automated Tests (E2E, Performance) -> Rollback Mechanism.
• Goals: Deliver features faster, minimise deployment risk, ensure zero-downtime releases.
• Continuous Security (CS): Integrates security checks throughout the CI/CD pipeline, embodying "shift left" security.
• Techniques: * Static Application Security Testing (SAST): Scans source code for vulnerabilities (e.g., SQLi) during the development phase. Tools: SonarQube, Checkmarx. * Dynamic Application Security Testing (DAST): Tests running applications for runtime threats during testing/QA phase. Tools: OWASP ZAP, Burp Suite. * Dependency Scanning (Software Composition Analysis - SCA): Checks third-party libraries for known vulnerabilities. Tools: Snyk, Dependency-Track. * Secrets Detection: Prevents accidental exposure of credentials. * Compliance Checks: Enforces policy standards (e.g., GDPR, HIPAA). * Infrastructure as Code (IaC) Scan: Analyzes infrastructure code for misconfigurations before deployment. Tools: Checkov, Terrascan. * Interactive Application Security Testing (IAST): Combines SAST and DAST by running inside the application server to identify issues during operation and evaluate code.
• Goals: Identify security flaws before deployment, maintain compliance, reduce remediation costs.

In the CI-CD-CS pipeline:

• CI Phase: Code commit, build, automated unit/integration tests.
• CS Phase: SAST, Dependency Scan, Secrets Detection. Pipeline halts if security checks fail.
• CD Phase: Secure artifact storage, staging deployment (with DAST scans), and feedback loop for alerts and metrics.

7. Key Practices, Tools, and Technologies

A variety of tools and practices underpin Secured Software Engineering:

•  Secure Coding & Design:
• Threat Modelling: Identifying risks during design using tools like OWASP Threat Dragon, Microsoft Threat Modelling Tool.
• OWASP Application Security Verification Standard (ASVS): Provides a basis for testing web application technical security controls and guidance for secure development.
• Secure Templates: Enforce secure coding standards via IDE plugins (SonarLint, Snyk IDE).
• Automated Security Testing (Detailed):
• SAST: SonarQube, Checkmarx (White-box, early SDLC, finds logic flaws, hardcoded secrets, injection risks).
• SCA: Snyk, Dependency-Track (Build/CI phase, identifies known CVEs in dependencies, license risks).
• DAST: OWASP ZAP, Burp Suite (Black-box, late SDLC, tests running apps for runtime vulnerabilities, config errors, authentication flaws).
• IaC Security: Checkov, Terrascan (CI/CD phase, scans infrastructure code for misconfigurations, overprivileged IAM roles, exposed storage).
• IAST: Addresses flaws in SAST/DAST by combining approaches (dynamic, inside app server, evaluates code).
• Runtime Protection:
• RASP (Runtime Application Self-Protection): Integrates with applications to analyze traffic and user behaviour at runtime to prevent attacks. Tools: Contrast Security, Imperva RASP.
• WAF (Web Application Firewall): Protects web applications from common attacks.
• Container Security: Scanning Docker/Kubernetes for misconfigurations.
• Continuous Compliance:
• Open Policy Agent (OPA): An open-source, general-purpose policy engine that unifies policy enforcement across the stack using "Policy-as-Code" (Rego language). It enables decentralised enforcement and dynamic context evaluation for infrastructure, APIs, CI/CD, and data systems. Tools: Gatekeeper (Kubernetes admission controller), Conftest (test IaC), Styra DAS.
• Threat Monitoring & Response:
• Security Information and Event Management (SIEM): Aggregates, analyzes, and manages security data from various sources for real-time monitoring, threat detection, incident response, and compliance reporting. Tools: Splunk, ELK Stack.

8. Maturity Model and KPIs

The adoption of DevSecOps and SSE can be viewed through a Maturity Model, progressing from Ad-hoc (Level-1) to Defined, Integrated, Automated, and finally Optimised (Level-6).

Key Performance Indicators (KPIs) and metrics are essential for measuring the success and impact of DevSecOps:

• DORA Metrics (DevOps Research and Assessment):
• Deployment Frequency: How often an organisation successfully releases to production (Faster Time-to-Market).
• Lead Time for Changes: Time from commit to production (Increased Efficiency, quicker response to feedback).
• Mean Time to Restore (MTTR): Time to restore service after an incident (Improved Reliability, minimises revenue loss).
• Change Failure Rate: Percentage of deployments causing service degradation (Higher Quality, reduces rework costs).
• Security-Specific KPIs:
• Mean Time to Detect (MTTD): Average time to discover a vulnerability (Reduced Risk Window).
• Vulnerability Remediation Rate: Speed at which identified vulnerabilities are fixed (Proactive Risk Management).
• Security Burndown: Time-series chart tracking open, unresolved security issues (Visible Progress in reducing security debt).
• Proactive Compliance Percentage: Percentage of security controls met automatically by the pipeline.
• Cost per Defect / Rework: Cost of fixing bugs, significantly reduced by "shifting left" (Lower Development Costs).
•     Customer Satisfaction (CSAT): (Enhanced Brand Loyalty, higher trust).

9. Fostering a DevSecOps Culture

Cultural transformation is paramount for successful DevSecOps adoption:

• Leadership's Role: Executives must champion the vision, provide resources, and communicate that "security is a non-negotiable component of product quality, not an impediment to speed."
• Education and Enablement: Continuous learning through secure coding training, easy access to security expertise, and immersive experiences (e.g., "capture-the-flag" competitions)
• Collaboration and Transparent Communication: Breaking down silos through cross-functional teams, shared communication channels, and blameless post-mortems to understand root causes.
• Building Empowerment and Trust: Creating an environment of psychological safety where engineers can experiment and innovate without fear of punishment. Security leadership should focus on "guardrails, not gates"—guiding developers towards secure outcomes rather than blocking them. 

Comprehensive Study Guide

Quiz

Answer the following questions in 2-3 sentences each.

1. What is the primary goal of Secured Software Engineering and how does it differ from traditional software development approaches regarding security?
2. Explain the concept of "Shift-Left Security" within the context of DevSecOps.
3. What are the three fundamental pillars of information security (the CIA triad), and why are they crucial in secured software engineering?
4. Describe the role of Configuration & Change Management in the traditional Software Engineering Process.
5. How does the Secured Software Development Life Cycle (SSDLC) differ from the traditional Software Development Life Cycle (SDLC) in its primary focus and timing of security integration?
6. Explain the key distinction between Continuous Integration (CI) and Continuous Deployment/Delivery (CD) within a pipeline.
7. What is the main purpose of Static Application Security Testing (SAST) and at which stage of the SDLC is it typically performed?
8. Briefly explain the function of Runtime Application Self-Protection (RASP) and how it differs from SAST, DAST, and IAST.
9. What is Open Policy Agent (OPA) and how does it contribute to continuous compliance in a DevSecOps pipeline?
10. Name two DORA metrics and explain how they measure the performance of software delivery teams.

--------------------------------------------------------------------------------

Answer Key

1. The primary goal of Secured Software Engineering is to create software with an intrinsic focus on protecting sensitive data and preventing security breaches. It differs from traditional approaches by integrating security measures proactively from the earliest stages of development, rather than treating security as a reactive, post-deployment concern.
2. "Shift-Left Security" refers to the practice of introducing security checks and considerations at the earliest possible stages of the software development lifecycle. This approach aims to identify and remediate vulnerabilities when they are less costly and time-consuming to fix, moving away from late-stage security testing.
3. The three fundamental pillars of information security are Confidentiality, Integrity, and Availability (the CIA triad). They are crucial because they ensure that sensitive data remains private, is accurate and trustworthy, and is accessible to authorised users when needed, forming the core objectives of secure software.
4. Configuration & Change Management involves tracking code changes using version control systems like Git, managing builds, releases, and roll-outs, and establishing change control boards. Its purpose is to govern and approve modifications to baselines, ensuring controlled and traceable evolution of the software.
5. The SSDLC defines functional, business, security, and compliance requirements as a unified set, whereas the traditional SDLC primarily focuses on functional and business requirements. Security is integrated from the very beginning of the project lifecycle in SSDLC, unlike the traditional SDLC where it is often a late-stage activity.
6. Continuous Integration (CI) automates the process of merging code changes from multiple developers into a shared repository, triggering automated builds and tests to detect integration errors early. Continuous Deployment/Delivery (CD) then automates the release of validated code to production environments, ensuring that every change passing CI is automatically released to users.
7. The main purpose of Static Application Security Testing (SAST) is to scan source code or binaries for vulnerabilities without executing the code. It is typically performed early in the SDLC, during the development phase, acting as "white-box" testing to provide feedback on possible flaws.
8. RASP (Runtime Application Self-Protection) tools integrate directly with applications and analyse traffic and user behaviour at runtime to prevent attacks. Unlike SAST (static), DAST (dynamic), and IAST (interactive, in-app testing), RASP is primarily focused on real-time protection and prevention in production environments after the product release.
9. Open Policy Agent (OPA) is an open-source, general-purpose policy engine that unifies policy enforcement across various parts of the technology stack, using a declarative language called Rego. It contributes to continuous compliance by allowing organisations to codify compliance rules and automate audits, ensuring consistent, context-aware security and compliance policies.
10. Two DORA metrics are Deployment Frequency and Lead Time for Changes. Deployment Frequency measures how often an organisation successfully releases to production, indicating the speed of delivery. Lead Time for Changes measures the amount of time it takes for a code commit to get into production, reflecting the efficiency of the development and delivery pipeline.

--------------------------------------------------------------------------------

Essay Format Questions

1. Discuss the evolution from traditional Software Development Life Cycle (SDLC) to Secured Software Development Life Cycle (SSDLC) and subsequently to DevSecOps. Highlight the key drivers for these transitions and the fundamental changes in approach at each stage.
2. Analyse the motivations, both technical and non-technical, for adopting Secured Software Engineering. Explain how embedding security into the development lifecycle from the outset addresses these motivations and contributes to business value.
3. Compare and contrast the different types of automated security testing tools (SAST, SCA, DAST, IAST, IaC Security, RASP). For each, describe its primary purpose, where it fits within the DevSecOps pipeline, and its strengths and limitations.
4. Elaborate on the cultural shifts necessary to successfully implement DevSecOps within an organisation. Discuss the roles of leadership, continuous education, collaboration, and trust in fostering a security-conscious and agile development environment.
5. Explain how the integration of Continuous Integration (CI), Continuous Deployment/Delivery (CD), and Continuous Security (CS) creates a robust pipeline for secure software delivery. Provide examples of activities and tools from each phase that contribute to overall security and efficiency.

--------------------------------------------------------------------------------

Glossary of Key Terms

• Secured Software Engineering (SSE): A comprehensive methodology that integrates security measures from the earliest stages of the software development process, focusing on protecting sensitive data and preventing breaches
• Confidentiality, Integrity, and Availability (CIA Triad): The three fundamental pillars of information security. Confidentiality ensures data privacy, Integrity ensures data accuracy and trustworthiness, and Availability ensures data access for authorised users.
• Software Development Life Cycle (SDLC): A structured process for developing software, typically encompassing phases such as planning, design, implementation, testing, deployment, and maintenance.
• Secured Software Development Life Cycle (SSDLC): An extension of SDLC that embeds security activities and considerations into every phase of the software development process, making security a primary concern from the outset.
• DevOps: A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the systems development life cycle and provide continuous delivery with high software quality. It emphasises collaboration, communication, and automation.
• DevSecOps: An evolution of DevOps that integrates security practices and considerations into every phase of the development and operations lifecycle. It aims to make security a shared responsibility across all teams.
• Continuous Integration (CI): An automated process where code changes from multiple developers are frequently merged into a central repository, followed by automated builds and tests to detect integration errors early.
• Continuous Delivery (CD): An extension of CI that automates the deployment of validated code to staging or production environments, ensuring that software can be released rapidly and reliably.
• Continuous Deployment (CD): A further extension of Continuous Delivery, where every change that passes all automated tests is automatically released to production, without manual intervention.
• Continuous Security (CS): The practice of integrating automated security checks and processes throughout the CI/CD pipeline ("shift left"), aiming to identify and remediate vulnerabilities as early as possible.
• Shift-Left Security: A paradigm in software development where security activities and testing are moved to the earliest possible stages of the development lifecycle to identify and fix vulnerabilities proactively.
• Static Application Security Testing (SAST): A "white-box" testing method that analyses source code or binaries for vulnerabilities without executing the application. It is typically performed during the development phase.
• Dynamic Application Security Testing (DAST): A "black-box" testing method that analyses a running application to identify vulnerabilities by simulating attacks. It is performed during the testing or QA phase.
• Interactive Application Security Testing (IAST): A testing method that combines elements of SAST and DAST, running from inside the application server to analyse code and identify issues during operation.
• Software Composition Analysis (SCA): An automated process that identifies and manages open-source software components within a codebase, checking for known vulnerabilities (CVEs) and license compliance issues.
• Infrastructure as Code (IaC) Scan: A security testing practice that analyses infrastructure code (e.g., Terraform, CloudFormation) to identify misconfigurations, vulnerabilities, and compliance issues before deployment.
• Runtime Application Self-Protection (RASP): Security technology that integrates with applications and actively monitors their behaviour at runtime to detect and prevent attacks in real-time.
• Web Application Firewall (WAF): A security solution that filters and monitors HTTP traffic between a web application and the Internet, protecting against common web exploits like XSS and SQL injection.
• Security Information and Event Management (SIEM): Software solutions that collect, aggregate, analyse, and manage security data (logs, events) from various sources to detect threats and facilitate incident response.
• Open Policy Agent (OPA): An open-source, general-purpose policy engine that allows organisations to define and enforce policies as code (using Rego language) across various components of their cloud-native stack.
• OWASP (Open Worldwide Application Security Project): A non-profit organisation focused on improving software security. It provides resources like the OWASP Top 10 (common web application security risks) and ASVS (Application Security Verification Standard).
• DORA Metrics: A set of four key metrics (Deployment Frequency, Lead Time for Changes, Mean Time to Restore, Change Failure Rate) developed by the DevOps Research and Assessment team to measure the performance and efficiency of software delivery teams.
• Threat Modelling: A structured process used to identify, categorise, and mitigate potential threats and vulnerabilities in a system or application during the design phase.
• Mean Time to Detect (MTTD): The average time it takes to discover a security vulnerability or incident in the system.
• Vulnerability Remediation Rate: The speed or efficiency at which identified security vulnerabilities are fixed or resolved.

Powerpoint Slides

Detailed Mindmap of the topics 

#	Part	Topic
1	Mindmap	Detailed Topics of Mindmap