Software Development Security
Software Development Security asks how security requirements, threat modelling, coding standards, verification, and supply-chain controls are embedded in delivery rather than bolted on. Items often describe a pipeline stage and ask which control belongs there, or present a feature and ask what the threat model would surface.
Requirements and modelling
Derive security requirements from data classification, regulatory obligations, and abuse cases. Threat model early, when design is still cheap to change: draw data-flow diagrams, mark trust boundaries, then apply STRIDE - spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Attack trees and PASTA are alternatives that add attacker goals or risk quantification.
Secure coding and pipeline controls
Validate input on the trusted side, encode output for its destination context, use parameterised queries, never hard-code secrets, and prefer memory-safe languages where feasible. In DevSecOps, secrets scanning, SAST, and dependency (SCA) checks run per commit; DAST and IAST run against deployed environments; infrastructure-as-code scanning and policy-as-code gates block non-compliant builds.
Supply chain
Maintain an SBOM, pin and verify dependencies, sign build artefacts, isolate build runners with least privilege, and restrict who can publish to production repositories. Maturity models such as OWASP SAMM and BSIMM structure improvement rather than prescribe tools.
Worked example
A new feature lets customers upload documents. Crossing the trust boundary from browser to server, STRIDE suggests tampering (malicious file), information disclosure (public bucket), and denial of service (oversized upload). Controls: type allowlist plus server-side scanning, size limits, storage outside the web root with unguessable object keys, delivery through short-lived signed URLs, per-object authorisation checks, encryption at rest, and access logging. The reasoning: each control traces to a STRIDE category and a boundary crossing, so the model justifies the design rather than decorating it.
Traps that cost marks
- Expecting SAST to find runtime or infrastructure misconfiguration - that is DAST and IaC scanning.
- Treating an SBOM as a vulnerability scan; it is an inventory.
- Leaving secrets in environment variables visible in shared CI logs.
- Scheduling the only security review at the end of delivery.
- Assuming TLS protects data once stored.