Security testing in the software life cycle

Most organizations now build or customize software, whether that means a public website, an internal workflow tool or the scripts that configure cloud infrastructure. Every one of those artefacts can contain security defects, and defects found late cost far more to fix than defects found early. Security testing in the software life cycle is the set of assessment activities that find those defects while code is being designed, written, built and deployed. Sub-domain 6.2 of the outline lists code review and testing, misuse case testing, test coverage analysis and interface testing among the activities a security professional must be able to plan and evaluate.

This lesson takes the manager's view. It explains what each kind of security testing does, where it fits in the pipeline, what its results mean and how to judge whether a development team's testing gives adequate assurance. For the engineering detail of testing in general, see CMPUT-301 Software Engineering; for the mechanisms behind common software flaws and their fixes, see CMPUT-331 Computer Security.

Why test early

The cost of fixing a defect rises as it moves through the life cycle. A design flaw found in a threat modelling session costs a conversation; the same flaw found in production may require an emergency patch, customer notification and a redesign. Estimates of the multiplier vary widely and many published figures are poorly sourced, but the direction is not in dispute. The practice of moving testing earlier is often called shifting left. It does not remove the need for testing in production; it adds checks at each stage so that fewer defects survive to the end.

Code review

Code review is the examination of source code by someone other than its author. In a security context, reviewers look for flaws such as missing input validation, unsafe handling of queries, weak use of cryptography, hard-coded secrets, missing authorization checks and poor error handling. Formal inspections, such as the Fagan inspection method, follow defined roles and stages and are used for high-assurance software. Most teams use lighter peer review in which every change is approved by another developer before it is merged, with security-focused review for sensitive components.

For managers, the questions are about coverage and competence. Are all changes reviewed, including urgent fixes? Are reviewers trained to recognize security issues? Do sensitive components, such as authentication and payment handling, get a review by someone with security expertise? Is there a checklist so that reviews are consistent? The evidence is the review record in the source control platform, linked to the change.

The example below shows the kind of change a reviewer should insist on. The first function builds a database query by joining strings, so user input becomes part of the query text. The second passes the input as a parameter, so the database treats it strictly as data. The point for a manager is not the syntax but the review rule: queries must be parameterized, and a reviewer who sees string-built queries should reject the change.

import sqlite3
db = sqlite3.connect(':memory:')
db.execute('CREATE TABLE customers (id INTEGER, name TEXT, region TEXT)')
db.executemany('INSERT INTO customers VALUES (?, ?, ?)',
               [(1, 'Aster Ltd', 'west'), (2, 'Birch Co', 'east'), (3, 'Cedar Inc', 'west')])

# Rejected in review: query text built by joining strings with user input
def find_by_region_unsafe(region):
    return 'SELECT name FROM customers WHERE region = \'' + region + '\''

# Approved: the input is passed as a parameter, never as query text
def find_by_region(region):
    return db.execute('SELECT name FROM customers WHERE region = ?', (region,)).fetchall()

print('Unsafe version builds this query text:')
print('  ', find_by_region_unsafe('west'))
print('Safe version returns:', find_by_region('west'))
# Unexpected input is simply treated as a value that matches nothing
print('Safe version with odd input:', find_by_region("west' OR '1'='1"))

Unsafe version builds this query text:
   SELECT name FROM customers WHERE region = 'west'
Safe version returns: [('Aster Ltd',), ('Cedar Inc',)]
Safe version with odd input: []

Automated security testing tools

Automated tools scale testing beyond what people can review. Each type sees the application from a different angle, and a mature program combines them.

Fuzz testing deserves a separate mention. Fuzzing supplies large volumes of unexpected, malformed or random input to a program to find crashes, hangs and unhandled errors, which often indicate robustness or security defects. Mutation fuzzers alter valid samples; generation fuzzers build inputs from a model of the expected format. Coverage-guided fuzzers measure which code each input reaches and favour inputs that explore new paths. For a manager, fuzzing is evidence of robustness for components that parse untrusted data, such as file uploads and network protocols, and it is increasingly built into continuous integration.

Software bills of materials and the supply chain

Modern applications are assembled more than written: open-source and commercial components often make up most of the code. A software bill of materials (SBOM) is a formal, machine-readable inventory of the components in a piece of software, their versions and their relationships. Common formats are SPDX (an ISO standard, ISO/IEC 5962:2021) and CycloneDX (standardized by Ecma International as ECMA-424 in 2024). An SBOM lets an organization answer quickly whether it uses a component when a new vulnerability is announced, and lets customers evaluate what they are buying.

In Canada, the Canadian Centre for Cyber Security has published guidance on software supply chain security and joint guidance with allied agencies on SBOMs and secure-by-design principles. Federal departments reference these in procurement, and the Critical Cyber Systems Protection Act, enacted through Bill C-8 in June 2026, is expected to require designated operators in federally regulated sectors to manage third-party and supply chain risks as regulations are made (check current status). Private organizations increasingly ask vendors for SBOMs and secure development attestations in contracts.

# A tiny SBOM extract checked against an advisory list (illustrative data)
sbom = [
    {'name': 'log-utils', 'version': '2.14.0', 'terms': 'Apache-2.0'},
    {'name': 'json-fast', 'version': '1.9.3', 'terms': 'MIT'},
    {'name': 'imgparse', 'version': '0.8.1', 'terms': 'BSD-3-Clause'},
    {'name': 'netclient', 'version': '5.2.0', 'terms': 'GPL-3.0'},
]
advisories = {('log-utils', '2.14.0'): 'critical', ('imgparse', '0.8.1'): 'high'}
approved_terms = {'Apache-2.0', 'MIT', 'BSD-3-Clause'}
for c in sbom:
    issues = []
    sev = advisories.get((c['name'], c['version']))
    if sev:
        issues.append(f'known vulnerability ({sev})')
    if c['terms'] not in approved_terms:
        issues.append(f"terms {c['terms']} need legal review")
    status = '; '.join(issues) if issues else 'ok'
    print(f"{c['name']:10s} {c['version']:7s} {status}")

log-utils  2.14.0  known vulnerability (critical)
json-fast  1.9.3   ok
imgparse   0.8.1   known vulnerability (high)
netclient  5.2.0   terms GPL-3.0 need legal review

The same inventory supports two kinds of decisions. Security decides how quickly vulnerable components must be upgraded, using the prioritization approach from lesson 4. Legal and procurement decide whether licence obligations, such as copyleft terms, fit how the software will be distributed. A component with an unknown licence or no maintainer is also a risk in its own right.

Misuse cases, interface testing and coverage

Functional tests check that software does what it should. Misuse case testing checks that it does not do what it should not. A misuse case describes how a feature could be abused, from the point of view of someone with harmful intent, and leads to a test of the control that should stop it: a user trying to view another customer's invoice by changing an identifier, a buyer submitting a negative quantity, a form submitted thousands of times a minute. Misuse cases come from threat modelling and from past incidents, and they are written alongside ordinary use cases so that requirements include the controls.

Interface testing examines the points where components meet: application programming interfaces, user interfaces, network interfaces and physical interfaces. Security defects cluster at interfaces because each side may assume the other validates input or checks authorization. API testing confirms authentication, authorization on every endpoint, input validation, rate limiting and error handling. Test coverage analysis measures how much of the code or requirements the tests exercise; for security, coverage of authorization checks and input handling matters more than a single overall percentage.

Release gates and assurance evidence

A release gate is a checkpoint in the pipeline where results must meet criteria before software moves on: no unresolved critical findings from static analysis, no components with critical known vulnerabilities, all misuse case tests passing, and secrets scanning clean. Gates should be automatic where possible, with a documented exception process for cases where the business accepts a risk temporarily. Exceptions need an owner, a reason, compensating controls and an expiry date.

Assurance evidence for software includes the pipeline configuration showing which tests run, the results for each release, the exceptions granted, code review records and the SBOM. Auditors and customers ask for this evidence, and frameworks such as NIST SP 800-218, OWASP SAMM (Software Assurance Maturity Model) and BSIMM (Building Security In Maturity Model) help organizations measure and improve their secure development practices.