Software Security

Software security is the ability to deliver service that can justifiably be trusted, specifically regarding the absence of unauthorized access to or handling of system state [1]. Unlike a feature that can be bolted on, security is an emergent property of an entire system — adding cryptographic libraries or firewalls does not make insecure software secure [2].

This section covers the arc from foundational concepts (CIA triad, fault-error-failure chain) through finding vulnerabilities (SAST, DAST, fuzzing, pen testing) and threat modeling (STRIDE, OWASP, CVSS) to secure design principles (Saltzer & Schroeder) and modern DevSecOps integration.

Security Within the Dependability Framework

Avizienis et al. define dependability as “the ability to deliver service that can justifiably be trusted” [1]. Security is a composite attribute within this framework:

Attribute Definition Security Role
Confidentiality Absence of unauthorized disclosure Core CIA element
Integrity Absence of improper system alterations Core CIA element
Availability Readiness for correct service Core CIA element
Reliability Continuity of correct service Prerequisite — secure code is more robust
Safety Absence of catastrophic consequences Security failures can cause safety failures
Maintainability Ability to undergo modifications Enables timely patching

Both McGraw (2006) and Takanen (2008) independently affirm that “security is a subset of software quality and reliability” [2] [3]. This means the same engineering discipline that produces reliable software — fault prevention, fault tolerance, fault removal, fault forecasting — applies directly to security.

The Fault-Error-Failure Chain in Security

The causal chain fault → error → failure from dependability theory applies to security, with one critical addition: attacks are deliberate faults introduced by an adversary [1]:

flowchart LR
    F["🔧 Fault<br>(flaw in code)"]
    E["⚠️ Error<br>(incorrect state)"]
    Fail["💥 Failure<br>(breach)"]
    A["🎯 Attack<br>(malicious fault)"]

    F -->|"activates"| E
    A -->|"triggers"| E
    E -->|"propagates"| Fail

    style F fill:#fff3cd,stroke:#ffc107,color:#282828
    style E fill:#fce4ec,stroke:#e91e63,color:#282828
    style Fail fill:#f8d7da,stroke:#dc3545,color:#282828
    style A fill:#e8eaf6,stroke:#3f51b5,color:#282828

A vulnerability exists when a fault (e.g., missing bounds check) can be activated by an attack (e.g., crafted input) to produce an error (e.g., buffer overread) that propagates to a failure (e.g., data exfiltration). The Heartbleed vulnerability (CVE-2014-0160) illustrates this chain: a missing bounds check in OpenSSL’s heartbeat extension allowed attackers to read up to 64KB of server memory per request [4].

Two Strategies: Finding vs. Preventing Vulnerabilities

The literature identifies two complementary approaches [1] [2]:

Prevention (Constructive — “White Hat”)

Build security into the system from the start:

  • Fault prevention: Secure design principles [5], secure coding standards [6]
  • Fault tolerance: Input validation, error handling, defense in depth
  • Security requirements: SQUARE [7], abuse cases [2]

Detection (Destructive — “Black Hat”)

Find vulnerabilities before attackers do:

  • Fault removal: SAST, DAST, code review, penetration testing [8]
  • Fault forecasting: Threat modeling [9], CVSS scoring [10]

McGraw’s 50/50 Split

McGraw argues that roughly 50% of security problems are implementation bugs (buffer overflows, SQL injection) and 50% are design flaws (insecure architecture, missing authentication) [2]. This means:

  • Code-level tools (SAST, linters) only address half the problem
  • Design-level analysis (threat modeling, architecture review) is equally essential
  • His 7 Touchpoints model interleaves constructive and destructive activities across every SDLC phase

Howard’s SD3 — Secure by Design, Secure by Default, Secure in Deployment — operationalizes prevention at every stage [6]. “You cannot build a secure system until you understand your threats” — threat modeling alone finds approximately 50% of security flaws.

The Cost of Insecurity

Security problems found late cost dramatically more to fix:

Metric Value Source
Average data breach cost $4.88M [11]
Time to identify breach 194 days [11]
Healthcare breach cost $9.77M [11]
Incidents exploiting known vulns 90% [8]
Code review security resolution 65.9% [12]
Effective scan results Only 30% [13]

The economics strongly favor prevention: 90% of security incidents exploit known vulnerabilities that could have been caught earlier [8]. Yet security is often treated as an afterthought, with organizations discovering breaches only after an average of 194 days [11].

Security Across the SDLC

Security activities map to every phase of the software development lifecycle:

Phase Security Activity Key Technique Case Study
Requirements Security requirements engineering SQUARE, ARQAN [7] [14] —
Design Threat modeling STRIDE, DFDs [9] SolarWinds (no TM) [15]
Implementation Static analysis, code review SAST, CERT standards [16] Heartbleed [4]
Testing Dynamic testing, pen testing DAST, fuzzing [8] Equifax [17]
Deployment Pipeline security IAST, RASP, DevSecOps [18] Log4Shell [19]
Operations Monitoring, patching SIEM, incident response WannaCry [20]

For the dependability framework (faults, errors, failures), see Reliability. For fuzzing techniques, see Fuzzing.

Section Overview

Page Content
Testing Techniques SAST, DAST, IAST, fuzzing, pen testing, code review — how to find vulnerabilities
Threat Modeling STRIDE, OWASP Top 10, CVSS, 12 TM methods — how to anticipate threats
Secure Design Saltzer & Schroeder’s 8 principles, input validation, DevSecOps, SQUARE — how to build secure systems

References

  1. A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing,” IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp. 11–33, 2004, doi: 10.1109/TDSC.2004.2.
  2. G. McGraw, Software Security: Building Security In. Addison-Wesley, 2006.
  3. A. Takanen, J. D. DeMott, and C. Miller, Fuzzing for Software Security Testing and Quality Assurance. Artech House, 2008.
  4. National Institute of Standards and Technology, “CVE-2014-0160: OpenSSL Heartbleed.” 2014. Available at: https://nvd.nist.gov/vuln/detail/CVE-2014-0160
  5. J. H. Saltzer and M. D. Schroeder, “The Protection of Information in Computer Systems,” Proceedings of the IEEE, vol. 63, no. 9, pp. 1278–1308, 1975, doi: 10.1109/PROC.1975.9939.
  6. M. Howard and D. LeBlanc, Writing Secure Code, 2nd ed. Microsoft Press, 2006.
  7. N. R. Mead, E. D. Hough, and T. R. Stehney II, “Security Quality Requirements Engineering (SQUARE) Methodology,” Carnegie Mellon University Software Engineering Institute, CMU/SEI-2005-TR-009, 2005.
  8. M. Felderer, M. Büchler, M. Johns, A. D. Brucker, R. Breu, and A. Pretschner, “Security Testing: A Survey,” Advances in Computers, vol. 101, pp. 1–51, 2016, doi: 10.1016/bs.adcom.2015.11.003.
  9. A. Shostack, Threat Modeling: Designing for Security. Wiley, 2014.
  10. P. Mell, K. Scarfone, and S. Romanosky, “A Complete Guide to the Common Vulnerability Scoring System Version 2.0,” FIRST, 2007.
  11. IBM Security, “Cost of a Data Breach Report 2024,” IBM, 2024. Available at: https://www.ibm.com/security/data-breach
  12. J. Yu, M. Hammad, and others, “Security Defect Detection via Code Review: A Study of OpenStack and Qt,” in IEEE ESEM 2023, 2023.
  13. R. N. Rajapakse, M. Zahedi, and M. A. Babar, “An Empirical Analysis of Practitioners’ Perspectives on Security Tool Integration into DevOps,” in EASE 2021, 2021. doi: 10.1145/3475716.3475776.
  14. A. Sadovykh and V. Ivanov, “Enhancing DevSecOps with Continuous Security Requirements Analysis and Testing,” Computer Research and Modeling, vol. 16, no. 7, pp. 1687–1702, 2024, doi: 10.20537/2076-7633-2024-16-7-1687-1702.
  15. Cybersecurity and Infrastructure Security Agency, “Alert AA20-352A: Advanced Persistent Threat Compromise of Government Agencies,” CISA, 2020. Available at: https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a
  16. B. Chess and J. West, Secure Programming with Static Analysis. Addison-Wesley, 2007.
  17. National Institute of Standards and Technology, “CVE-2017-5638: Apache Struts 2 Remote Code Execution.” 2017. Available at: https://nvd.nist.gov/vuln/detail/CVE-2017-5638
  18. T. Rangnau, R. van Buijtenen, F. Fransen, and F. Turkmen, “Continuous Security Testing: A Case Study on Integrating Dynamic Security Testing Tools in CI/CD Pipelines,” in IEEE EDOC 2020, 2020, pp. 145–154. doi: 10.1109/EDOC49727.2020.00026.
  19. National Institute of Standards and Technology, “CVE-2021-44228: Apache Log4j Remote Code Execution (Log4Shell).” 2021. Available at: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
  20. National Institute of Standards and Technology, “CVE-2017-0144: Windows SMB Remote Code Execution (EternalBlue).” 2017. Available at: https://nvd.nist.gov/vuln/detail/CVE-2017-0144

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

Table of contents

This site uses Just the Docs, a documentation theme for Jekyll.