◇ 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 Security in the lifecycle"]
  N2["14.2 Code review"]
  N3["14.3 Dependency management"]
  N4["14.4 Build integrity"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Security in the lifecycle"]
  N2["14.2 Code review"]
  N3["14.3 Dependency management"]
  N4["14.4 Build integrity"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Security in the lifecycle]
    |
    v
[14.2 Code review]
    |
    v
[14.3 Dependency management]
    |
    v
[14.4 Build integrity]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) integrate security into the development lifecycle; (2) use threat-aware code review; (3) manage vulnerabilities in dependencies.

14.1 Security in the lifecycle

Saltmarsh's developers build a driver app for delivery confirmations. Lindiwe learns that security added at the end is expensive, while security considered from requirements onwards is cheaper. She helps write security requirements: drivers authenticate with their own accounts, confirmations cannot be altered after submission and location data are kept only as long as disputes may arise. Prof. Hale notes that clear requirements give testers something concrete to check, rather than a vague instruction to make the app secure. The product owner accepts all three requirements.

14.2 Code review

Lindiwe joins code reviews for the driver app. She looks for the patterns she has learned: string-built queries, secrets in code, missing input validation and permissions checked only in the user interface. In one change, the app hides a delete button from drivers but the server accepts delete requests from anyone logged in. She explains that every check must happen on the server, because attackers do not use the official interface. The developer fixes the server check the same day and adds a test that sends a delete request from a driver account and expects a refusal.

14.3 Dependency management

The driver app uses dozens of open-source libraries. Lindiwe sets up a list of dependencies with versions and checks it against public vulnerability databases each week. One library has a known flaw allowing denial of service, and an update exists. The developers update it after running their tests. She learns that most application code is borrowed, so knowing what is included is essential, and that a dependency list is itself a security record. The weekly check takes a few minutes and runs automatically on the build server, sending results to the team channel.

14.4 Build integrity

Code is turned into installable packages by a build server. If an attacker changes the build, every user receives malicious software. Lindiwe recommends that builds run from version-controlled scripts, that build servers be isolated and that packages be signed with a protected key. Prof. Hale connects this to her earlier recommendation about the code-signing key. She learns that the path from source code to user device is part of the attack surface and must be protected. The development lead adds these steps to the roadmap.

Worked example

Lindiwe writes security requirements for a driver app, finds a server-side authorisation gap in review, tracks dependencies weekly and recommends a protected build pipeline.

Synthetic case. The app is synthetic.

Errors and limits

Hiding a button in the interface does not stop requests to the server.

Exercises

Continue studying — lesson 14 (chapter 14 of 50)

← Chapter 13 · Course chapter index · Chapter 15 →

Continue to the next authored lesson.