Fawzooz
عربي

Awakening Security

Request the PDF

Enter your email and we will send you a code; your request is then recorded at once, and once I have reviewed it a link to download your copy reaches your email.

By continuing, your email and progress are kept in your account. Privacy

* The file is for your own reading; sharing follows the terms of use, and commercial use is not permitted.

Reading progress
0 of 34 sections read
13 / 34

Chapter 11

11Security in the Software Development Life Cycle

2 min read13 of 34Read it in the book · page 67

“A flaw fixed in design costs an idea; a flaw fixed in production can cost the company.”

Every creative studio is now a small software company: a campaign website, a client app, internal tools and integrations with AI platforms. ISO 27001:2022 requires security to be part of the development life cycle (controls 8.25 to 8.34), not a final check before launch.

Security at every stage of the software development life cycleSecurity at every stage of the software development life cycle
Security at every stage of the software development life cycle
Text in this figure

Secure · by design · Requirements · Security and privacy needs · Design · Threat modelling · Coding · Secure coding · SAST · Testing · DAST · pen testing · Deployment · Secure config · secrets · Operation · Monitoring · patching · Figure 13

Security at Every Stage

  • Requirements: Security requirements are written alongside functional ones: who has access? What data is sensitive? Which laws apply?
  • Design: Threat modelling and secure design principles: least privilege, defence in depth and failing securely.
  • Coding: Secure coding standards, peer code review, and no secrets in the code.
  • Testing: Static analysis (SAST), dynamic testing (DAST) and software composition analysis (SCA), with penetration testing for critical systems.
  • Deployment: Secure configuration, separation of development, test and production environments, and secrets management.
  • Operation: Monitoring, logs and updates, with a response plan ready.

Threat Modelling with STRIDE

Threat modelling is a short session in which the team draws the system and asks: what could go wrong? The STRIDE model sorts the answers into six categories that help ensure nothing is forgotten.

The STRIDE threat classification modelThe STRIDE threat classification model
The STRIDE threat classification model
Text in this figure

S · Spoofing · Spoofing · Threatens: Authenticity · T · Tampering · Tampering · Threatens: Integrity · R · Repudiation · Repudiation · Threatens: Non-repudiation · I · Information disclosure · Information Disclosure · Threatens: Confidentiality · D · Denial of service · Denial of Service · Threatens: Availability · E · Elevation of privilege · Elevation of Privilege · Threatens: Authorisation · For every element in the system diagram ask: which of the six could hit it? · Figure 14

CategoryQuestionProperty threatened
SpoofingIs someone pretending to be someone else?Authentication
TamperingIs something modified without permission?Integrity
RepudiationDoes someone deny an action they took?Non-repudiation
Information disclosureIs data leaking?Confidentiality
Denial of serviceDoes the system go down?Availability
Elevation of privilegeDoes someone gain more permissions?Authorisation

Secure Coding

Control 8.28 is new in the 2022 edition and requires applying secure coding principles. The most common mistakes are well known and ranked in the OWASP Top 10 for web applications: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, outdated components, weak authentication and more.

  • Validate every input: Do not trust any data arriving from a user or another system.
  • No secrets in code: Keys and passwords belong in a secrets vault, not the repository.
  • Update components: Every outdated library is a known door for attackers.
  • Log wisely: Enough logging to investigate, without passwords or personal data.
The later a flaw is found, the more it costs to fixThe later a flaw is found, the more it costs to fix
The later a flaw is found, the more it costs to fix
Text in this figure

Requirements · Design · Coding · Testing · Production · Cheapest here · Illustrative of the trend, not specific figures: shift security to the start · Figure 15

2026 Update

A large share of code is now written with AI assistance. Generated code may look correct while carrying vulnerabilities, or suggest non-existent packages that attackers then register under those names. Treat it like code from a new colleague: reviewed, tested and scanned before merging, and never paste secrets or confidential code into an unapproved tool.

Shift security left: the earlier it starts, the cheaper and stronger it is.

Lessons Learned

  1. 1Security is a requirement written at the start, not a check run at the end.
  2. 2STRIDE gives the team six questions that are hard to forget.
  3. 3Secure coding is an explicit control in 2022.
  4. 4AI-generated code is reviewed like any other code.

Tip: use ← → to move between sections.