◇ OpenCyber Academy
Engineering · Chapter 14 · English

Chapter 14 — Software engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 14 — Software engineering

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Development as a control"]
  N2["14.2 Change management"]
  N3["14.3 Third-party code"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Development as a control"]
  N2["14.2 Change management"]
  N3["14.3 Third-party code"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Development as a control]
    |
    v
[14.2 Change management]
    |
    v
[14.3 Third-party code]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) apply secure development practices as governance controls; (2) manage change with approval and traceability; (3) include third-party code in risk.

14.1 Development as a control

Ardwell builds and maintains its customer payment portal. Nadia learns that secure development practices, such as code review, security testing and dependency management, are governance controls as well as engineering habits. ISO/IEC 27002:2022 includes controls for secure development life cycles and secure coding, and PCI DSS v4.0 requires that bespoke software for payment systems is developed securely. She maps each practice in the portal team's workflow to these requirements and notes where evidence already exists in the team's tools. Existing evidence such as code review records in the team's repository can then be reused for audits instead of being recreated.

14.2 Change management

Every change to the portal passes through a ticket, a code review and an approval before deployment. Nadia checks a synthetic month of changes and finds that most are traceable from ticket to deployment, but some emergency fixes skipped review. She recommends a documented emergency path with review after the fact within two working days. Traceable change management lets auditors confirm that what runs in production was approved, and lets engineers find which change introduced a problem when something breaks. Review within two working days keeps the emergency path fast while restoring traceability for every fix.

14.3 Third-party code

The portal depends on dozens of open-source libraries. Nadia learns that each is a supplier whose vulnerabilities become Ardwell's risk. She proposes a software bill of materials listing each component and its version, with automatic alerts when a known vulnerability is published. She also notes licensing obligations, which are a compliance issue in their own right. Prof. Brenner remarks that modern applications are mostly other people's code, so governance must extend to the components a team never wrote. The bill of materials also tells Ardwell within hours which portal versions are affected when a library vulnerability is announced.

Worked example

Nadia maps development practices to standards, finds untraceable emergency fixes and proposes a software bill of materials.

Synthetic case. Change records are synthetic; standards cited are real.

Errors and limits

Reviews vary in depth. Component lists miss transitive dependencies.

Exercises

Synthesis

Secure development, traceable change and component inventories are governance controls in software.

Continue studying — chapter 14 of 50

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →