What Is Software Security? A Practical Guide for Teams That Ship Software

What is software security?

"Software security" is the practice of building software that keeps behaving as intended while someone is actively trying to make it misbehave. The term owes much of its currency to Gary McGraw, whose 2006 book Software Security: Building Security In argued that security has to be designed and engineered into software rather than "bolted on" once the software is finished. Generally, the discipline covers the whole life of a piece of software: the requirements that shape it, the design and code that make it up, the third-party components it depends on, the pipeline that builds it and the process that patches it once it is in the field. That scope is what separates it from network and infrastructure security, which protect the environment the software runs in. Both matter, but a well-configured network does not fix an endpoint that trusts whatever account number the browser sends.

A useful way to hold the distinction is to ask where the defect lives. Infrastructure security asks whether the walls and doors around a system are sound, and it can often be improved without changing a line of application code. Software security asks whether the system itself makes correct decisions about who may do what, with which data, and under which conditions. When those decisions are wrong, perimeter controls will not make them right, because the attacker is using the software exactly as it was built. A good share of the breaches that make the news are, at bottom, failures of that second kind.

It follows that software security is not a product you can buy or a scan you can run. It is a property of the software, produced by the way a team works, and it can only be demonstrated by testing the software and examining the process that made it. A scanner may tell you something useful about the code, and a policy may tell you something useful about intent, but neither one establishes the property on its own. The rest of this guide describes what that property is made of, where it tends to fail, and how organizations measure it.

Software security vs. application security vs. product security

The terms overlap enough that people use them interchangeably, and in casual conversation that rarely causes harm. When you are scoping a program, a hire or an engagement, however, the differences matter, because each term implies a different owner and a different set of deliverables. "Application security", usually shortened to "AppSec", tends to mean testing and hardening specific applications, and in many organizations it sits inside the security team as a service to engineering. "Product security" usually describes an organizational function that owns the security of everything a company ships, including firmware, mobile clients and the public response when a vulnerability is reported. Software security is the broader discipline beneath both: the engineering practices and evidence that make any piece of software trustworthy, whichever team is accountable for it.

The practical point is that a mature software security program usually contains an application security function, and a product security team usually depends on one, but neither is a substitute for the underlying practice. Teams that hire a single AppSec engineer and consider the problem solved often discover that one person reviewing code at the end of the process cannot keep pace with a hundred people writing it. The work has to be spread into the places where software is actually designed and built. The specialists then set the standard, handle the hard cases and check that the standard is being met, which is a very different job from finding every bug personally.

Where software security flaws come from

McGraw drew a distinction that still holds up: "bugs" are implementation mistakes, such as an unchecked buffer or a query assembled from user input, while "flaws" are design mistakes, such as trusting the client to decide which records a user may see. He has long estimated that the two account for roughly equal shares of software security problems. Since his book, two more sources have grown large enough to deserve their own place, namely the components you did not write and the pipeline that turns source code into something customers run. Each of the four fails differently, and each is found by a different kind of work.

1. Design flaws

   A missing authorization model, a trust boundary drawn in the wrong place, a secret shipped inside a mobile app. These are decisions rather than typos, and the code that implements them can be perfectly clean. Automated scanners find very few of them, because the scanner cannot know what the system was supposed to allow. They are found by "threat modeling" and architecture review, ideally before the design is built and while changing it is still cheap.

2. Implementation bugs

   Injection, cross-site scripting, unsafe deserialization and memory corruption live here. Memory safety alone is a large category. In 2019 Microsoft reported that roughly 70 percent of the vulnerabilities it assigned CVEs to each year were memory safety issues. Bugs of this kind respond well to safe-by-default APIs, memory-safe languages, static analysis and review, and catalogs such as the OWASP Top 10 and the CWE Top 25 rank the most common of them. The SQL injection field guide walks one of the oldest of them from the textbook case to the ways parameterization quietly fails.

3. Third-party components

   In most modern applications, the majority of the shipped code was written by someone else and pulled in as a dependency. When Log4Shell was disclosed in December 2021, many organizations spent the first week simply trying to find out where they were running Log4j at all. You inherit the vulnerabilities of every component you ship, and you cannot patch what you cannot inventory, which is why a "software bill of materials", or SBOM, has moved from a nice-to-have to a procurement question.

4. The build and release pipeline

   In the SolarWinds compromise disclosed in 2020, attackers altered the build process so that malicious code shipped inside legitimately signed updates. In 2024 a backdoor was found in the xz compression library, planted by a contributor who had spent roughly two years earning maintainer trust. Neither case involved an honest coding mistake, and in both the malicious logic was hidden from ordinary source review, in the build system in one case and in test files and a release-only build script in the other. Both were attacks on the path between the source code and the customer, and they are defended by protecting build systems, signing artifacts and recording provenance, which is largely security engineering work.

The pattern worth noticing is that most security tooling concentrates on the second category, because implementation bugs are the easiest to detect automatically. A program built only around scanners will therefore look busy while leaving design flaws, dependency exposure and pipeline integrity largely unexamined. In practice, a team can have a clean scan report and still ship an application in which any logged-in user can read any other user's data. Balanced coverage across all four sources is one of the clearest differences between a mature program and a tooling budget.

Software security across the development lifecycle

The phrase "shift left" is often read as a single instruction to run security tools earlier in the pipeline. The more useful reading is that each phase of development has a security question only that phase can answer cheaply, and a program should ask each question at the point where it belongs. The frequently quoted claim that a defect costs one hundred times more to fix in production than in design is difficult to trace to a primary study, and it should not carry the argument. The stronger reason is simpler: a design flaw found in review changes a document, while the same flaw found in production changes a data model, a migration, several services and a customer notification. In practice, the activities usually line up as follows.

• Requirements. Security and privacy requirements are written down alongside functional ones, including who may access which data and what must be logged, so they can be tested later rather than assumed.
• Design. Threat modeling identifies trust boundaries, sensitive data flows and abuse cases while the architecture can still change. This is where most design flaws are caught or missed.
• Implementation. Secure coding standards, safe libraries, peer review with security in scope, and static application security testing, or SAST, tuned so that its findings are trusted rather than ignored.
• Dependencies. Software composition analysis, or SCA, an SBOM for each release, and a policy for how quickly known vulnerabilities in components must be addressed.
• Build and release. Hardened CI/CD, protected secrets, signed artifacts and build provenance, for which the OpenSSF's SLSA framework, short for Supply-chain Levels for Software Artifacts, provides a graded target.
• Verification. Dynamic application security testing, or DAST, fuzzing, penetration testing and targeted manual review, scaled to the risk of the change rather than applied uniformly.
• Response. A published way to report vulnerabilities, a process to triage and fix them, and a feedback loop so the root cause of each finding improves the earlier phases.

None of these activities is exotic, and most teams already perform some of them informally. The difference between informal and managed is whether the activity happens consistently, whether someone owns it, and whether it leaves a record. A threat model held only in one architect's head protects the system for as long as that architect is in the room.

Software security frameworks and standards

Several established frameworks describe what a software security program should contain, and most organizations benefit from picking one as a yardstick rather than inventing their own. The NIST Secure Software Development Framework, published as SP 800-218, final at version 1.1 since February 2022 with a draft version 1.2 released for comment in December 2025, organizes its practices into four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. It is deliberately outcome-oriented, stating what should be achieved without dictating tools or methods, and it has become the reference point for software sold to the US federal government. Because it is concise and widely recognized, it is often the easiest framework to explain to customers.

OWASP SAMM, the Software Assurance Maturity Model, is the most practical choice for measuring your own program. Version 2 organizes fifteen security practices under five business functions: governance, design, implementation, verification and operations. It scores each practice across three maturity levels. It is free, prescriptive and designed for self-assessment, so it produces a roadmap as well as a score. BSIMM, the Building Security In Maturity Model, takes the opposite approach. First published in 2009, it is descriptive rather than prescriptive, cataloging the activities that participating firms actually perform, which makes it useful for benchmarking against peers but less direct as a plan.

A framework tells you what good looks like. It cannot tell you whether you are doing it.

Beyond those three, ISO/IEC 27034 provides an international standard for application security, IEC 62443-4-1 defines secure development lifecycle requirements for industrial automation products, and CISA's Secure by Design principles, first published with international partners in 2023, push vendors to take ownership of customer security outcomes rather than leaving hardening to the customer. AI systems introduce their own layer, which the article on AI security standards covers separately. The frameworks overlap heavily, and a team that meets SSDF well will already satisfy much of SAMM and the secure development section of most customer questionnaires. The choice matters less than the commitment to measure against one of them honestly and repeatedly.

Why customers and regulators now ask

For most of its history, software security was an internal quality concern, and buyers had little way to ask about it beyond a generic questionnaire. That changed in the early 2020s. In the United States, Executive Order 14028, issued in May 2021 after the SolarWinds compromise, led NIST to publish the SSDF as SP 800-218 and led the Office of Management and Budget to require that software producers selling to federal agencies attest to following it. CISA published the common attestation form in March 2024, but in January 2026 the Office of Management and Budget rescinded that mandate, so each agency now decides whether to collect an attestation or an SBOM based on its own assessment of risk. The mechanism has changed more than once, but the direction has been consistent: buyers want the producer, not the customer, to stand behind the security of the software.

In Europe the shift carries legal force. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force in December 2024 and covers most hardware and software products with digital elements placed on the EU market, although software delivered purely as a hosted service is largely outside its scope. Its obligation to report actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, and the main requirements for secure design, vulnerability handling and conformity assessment apply from 11 December 2027. Enterprise buyers have followed the same path in their procurement, so a mid-sized software company can now expect questions about its SBOM, its vulnerability disclosure policy and its secure development process from customers who asked none of them five years ago.

How to tell whether a program is working

The most common measurement mistake is to count activity instead of outcomes. The number of scans run, trainings completed or findings closed says something about effort, but it says very little about whether the software is becoming harder to attack. Outcome measures are less comfortable and far more useful. Time to remediate by severity shows whether findings are actually being fixed or merely accepted. The share of serious findings that trace back to design rather than code shows whether threat modeling is doing its job. The count of "escapes", vulnerabilities found in production that an earlier control should have caught, shows which controls are weaker than they appear on paper.

Coverage matters as much as depth. A program might produce excellent threat models for the flagship product while forty internal services have never had one, and a single average will hide that completely. Generally, the questions worth tracking are simple ones: what fraction of services have a current threat model, what fraction of releases carry an SBOM, how old are the dependencies in the oldest service, and how many critical findings are older than the policy allows. None of them requires a new tool, although each one requires someone to own the answer.

Evidence is the other half of measurement. If a practice leaves no record, then from the perspective of a customer, an auditor or a regulator, it did not happen. Mature programs produce evidence as a side effect of doing the work, in the form of pipeline logs, signed build attestations, review records and tracked exceptions, rather than assembling it by hand the week before an audit. Going forward, the organizations that find these conversations easy will be the ones whose evidence already exists when the question arrives.

Where to start

For a team without a formal program, the sequence that works most often is to know what you have, measure it against a yardstick, and fix the gaps in order of leverage. Start with an inventory of the applications, services and components you ship, because every later step assumes you can say what is in scope. Then assess the program honestly against one framework, SSDF if you sell to the US public sector or expect to, and SAMM if you want the most direct route to a scored roadmap. The assessment will usually surface two or three gaps that dominate the rest, often threat modeling, dependency management or the absence of usable evidence, and those deserve attention before anything else.

After the first round of fixes, validate them. A control that has been implemented but never tested is an assumption, and assumptions tend to fail at inconvenient moments, frequently in the middle of a customer's security review. Repeating the assessment on a regular cadence turns a one-time project into a program, and the trend line between assessments becomes the most persuasive evidence you can offer a buyer. It shows not only where the program stands, but that it is improving.

Software security is ultimately less about any single tool or framework than about whether a team can explain, with evidence, why its software deserves to be trusted. The organizations that do it well tend to treat security as an engineering property to be designed, built and verified like performance or reliability, rather than a review that happens to the software after it is finished. That shift in posture is harder than buying a scanner, but it is also the only version of the work that keeps paying off as the software grows.

Assessing a program against SSDF or SAMM and assembling the evidence buyers ask for is the substance of a software security assurance engagement, and the evidence readiness assessment is the structured version of that first measurement. Testing whether the software itself holds up is application and AI security work.