Skip to content

Software Quality

Security

Does it hold up against someone trying to break it?

Resistance to misuse: protecting data and behavior against an adversary. A distinct discipline with its own literature (OWASP), toolchains (SAST / DAST / SCA), and tracking infrastructure (CVE, GHSA, NVD). Safety is a different concern: a product not harming people, property, or the environment. Here it folds into Functionality and Reliability rather than forming a dimension of its own; the methods are in verifying safety-critical systems.

The most cost-effective security work is removing whole classes of vulnerability rather than detecting cases one at a time: memory-safe languages eliminate buffer overflows, parameterized queries eliminate SQL injection, framework-level escaping eliminates most XSS.

What goes wrong

  • Injection. SQL, OS command, LDAP, XPath, template. User input ends up where it shouldn't be parsed.
  • Authentication and session bugs. Predictable tokens, replay, weak credential storage, missing rate limits.
  • Authorization bugs. A user accessing data that belongs to another tenant. Often invisible to the type system; visible to fuzzers and pentesters.
  • Cross-site issues. XSS, CSRF, CORS misconfiguration, mixed content. Browser-side trust failures.
  • Supply-chain compromise. A trusted dependency ships malicious or vulnerable code. xz-utils (2024), log4shell (2021), SolarWinds (2020).
  • Sensitive data exposure. Secrets in source control, PII in logs, unencrypted transport.
  • Insecure-by-default configuration. Open S3 buckets, default admin passwords, public-by-default API endpoints.
  • Memory safety bugs in unsafe languages. Buffer overflows, use-after-free, double-free. Catastrophic and entirely avoidable in a memory-safe language.
  • Algorithmic-complexity denial of service. A crafted input drives a routine into its worst case: regex catastrophic backtracking (ReDoS), a quadratic parser, a hash-collision flood. ReDoS is caught statically by a linter; the general worst case by complexity fuzzing under algorithmic complexity testing.

What success looks like

  • CVEs with public exploits do not surprise the team. SCA flagged them, dependencies have been updated or pinned with explicit risk acceptance.
  • Threat model exists and is current. Last reviewed within the release cycle; reflects what the system actually does.
  • Security headers and defaults are correct. A scan with securityheaders.com or Mozilla Observatory returns A or A+.
  • OWASP Top 10 categories are addressed explicitly. Each one named, each one with a control documented.
  • No secrets in source. Provable via a clean scan.
  • Recovery from compromise is rehearsed. Backup integrity verified, restore tested, blast radius understood.

Referenced by