What is threat modeling?

Threat modeling is a structured analysis, done during design, of what an attacker might target and how. Teams diagram the system, enumerate threats (often with a checklist like STRIDE), and decide on mitigations before code is written, so security is built into the architecture.

Why isn't running a security scanner enough?

Automated scanners catch many known patterns but miss design flaws, business-logic errors, and novel issues, and they produce false positives. Effective programs combine automated analysis with threat modeling, manual review, and testing across the whole lifecycle.

Secure Software Development

Secure software development integrates security into every phase of building software — from threat modeling and secure design through coding standards, testing, and review — so that vulnerabilities are prevented rather than patched after release.

Nájsť tému v PaperMindČoskoroFind papers & topics

Tools & resources

Stiahnuť snímky

Learn & explore

VideoČoskoro

Definition

Secure software development is the discipline of incorporating security activities and controls throughout the software development lifecycle in order to reduce the number and severity of vulnerabilities in delivered software.

Scope

This topic covers the practices and processes that produce secure software: threat modeling, secure design principles, secure coding standards, static and dynamic analysis, fuzzing, security testing, code review, and the secure development lifecycle and DevSecOps. It addresses supply-chain and dependency security. It excludes the offensive study of exploitation and the post-release analysis of malware, which are treated in sibling topics.

Core questions

How is security designed into software from the start rather than added afterward?
What is threat modeling and how does it guide secure design?
How do static analysis, dynamic analysis, and fuzzing find vulnerabilities before release?
How are secure development activities embedded into modern CI/CD pipelines (DevSecOps)?
How are risks from third-party dependencies and the software supply chain managed?

Key concepts

threat modeling
secure design principles
secure coding standards
static application security testing (SAST)
dynamic analysis (DAST)
fuzzing
code review
secure development lifecycle
supply-chain security

Key theories

Security development lifecycle: A structured process integrates security gates into each development phase — requirements, design (threat modeling), implementation (secure coding, analysis), verification (testing, fuzzing), and release — measurably reducing shipped vulnerabilities.
Shift-left and automated assurance: Finding and fixing defects early ('shifting left') is far cheaper than after deployment; automated static/dynamic analysis and fuzzing embedded in continuous integration provide scalable, repeatable assurance.

Mechanisms

Secure development begins with threat modeling (e.g., STRIDE) to identify what could go wrong, informing a design that applies least privilege and defense in depth. During implementation, secure coding standards and static analysis flag risky patterns, while dynamic analysis and fuzzing exercise the running program with malformed inputs to surface crashes and memory errors. Code review and security testing precede release, and in DevSecOps these checks run automatically in the build pipeline, with dependency scanning and signed builds protecting the supply chain.

Clinical relevance

Secure development determines the baseline security of nearly all software people use. Microsoft's adoption of the SDL after 2002 markedly reduced vulnerabilities in its products, continuous fuzzing (Google's OSS-Fuzz) finds thousands of bugs in widely used open-source code, and supply-chain practices became urgent after attacks like SolarWinds and Log4Shell. These practices shape regulatory expectations and procurement requirements.

Evidence & guidelines

Frameworks include the Microsoft SDL, OWASP SAMM and ASVS, BSIMM (a measurement of real programs), and NIST's Secure Software Development Framework (SSDF, SP 800-218). U.S. executive guidance now requires SSDF attestation for government software suppliers, and SBOM (software bill of materials) standards support supply-chain transparency.

History

Secure development grew from the recognition in the late 1990s and early 2000s that patching shipped software did not scale. Microsoft's 2002 Trustworthy Computing initiative produced the Security Development Lifecycle, and McGraw's 'Software Security' (2006) codified 'building security in'. The 2010s integrated these practices into agile and DevOps workflows (DevSecOps) and, after major supply-chain incidents, extended them to dependencies and build integrity.

Key figures

Gary McGraw
Michael Howard
Steve Lipner
Ross Anderson

Seminal works

howard2006
mcgraw2006
anderson2020

Frequently asked questions

What is threat modeling?: Threat modeling is a structured analysis, done during design, of what an attacker might target and how. Teams diagram the system, enumerate threats (often with a checklist like STRIDE), and decide on mitigations before code is written, so security is built into the architecture.
Why isn't running a security scanner enough?: Automated scanners catch many known patterns but miss design flaws, business-logic errors, and novel issues, and they produce false positives. Effective programs combine automated analysis with threat modeling, manual review, and testing across the whole lifecycle.