OpenCyber Academy
Professional · Chapter 1 · English
Course code: OCA-037Chapter 01: OCA-037-C001

Chapter 1 — Security foundations for practitioners

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

Lesson map

Lesson 01 published. Map, example, EX001.

flowchart TD
  N0["Learning outcomes"]
  N1["1.1 The opening case"]
  N2["1.2 Security goals"]
  N3["1.3 Why the case matters"]
  N4["1.4 Frameworks used"]
  N5["1.5 The professional role"]
  N6["1.6 Course plan"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX001"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["1.1 The opening case"]
  N2["1.2 Security goals"]
  N3["1.3 Why the case matters"]
  N4["1.4 Frameworks used"]
  N5["1.5 The professional role"]
  N6["1.6 Course plan"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]
[Learning outcomes]
    |
    v
[1.1 The opening case]
    |
    v
[1.2 Security goals]
    |
    v
[1.3 Why the case matters]
    |
    v
[1.4 Frameworks used]
    |
    v
[1.5 The professional role]
    |
    v
[1.6 Course plan]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX001]

Learning outcomes

You will (1) state the core security goals for an internal business application; (2) connect them to the software supply chain; (3) frame the opening case; (4) set the course plan.

1.1 The opening case

Priya Nair, a quality engineer moving into application security, takes the six-month professional course at the fictional Westgate Professional Institute while working at the fictional freight company Harbourline Freight, mentored by security lead Marcus Bell. During a routine build review she noticed that one internal package, hl-auth, had been resolved from the public package registry rather than Harbourline's internal one. Nothing harmful was found in the published package, but the build had trusted a source nobody intended. Marcus asks her to treat the finding as a question about the whole build, not one package.

1.2 Security goals

Confidentiality, integrity and availability apply to TrackPort, Harbourline's shipment-tracking application: customer addresses must stay private, shipment records must not be altered and the service must stay up for depots. Supply chain security protects integrity before the software even runs: everything built into TrackPort must be what the team intended. For depot staff, availability matters most during shifts, when drivers and loaders update shipments in real time. Priya writes the three goals at the top of her project notes, so each later finding can be judged by which goal it threatens.

1.3 Why the case matters

If a build can take a package from an unintended source, someone else's code could run with TrackPort's access to customer and shipment data. Ladisa et al. (2023) catalogue this and other supply chain attack paths; the defensive response is to control and check where every dependency comes from. For TrackPort, that access includes customer addresses and phone numbers, shipment contents and delivery photos. The hl-auth package was harmless, but the same path could carry harmful code next time. Priya therefore treats the finding as a gap in source control, not a one-off incident.

1.4 Frameworks used

NIST SP 800-218 (SSDF) for secure development practices; OWASP ASVS 4.0.3 for application requirements; SLSA v1.0 for build integrity; OWASP SAMM v2 to judge maturity; OWASP Top 10:2021, whose A06 and A08 cover vulnerable components and software integrity failures. Each framework serves a different purpose in the project. SSDF names the development practices Harbourline should follow; ASVS gives requirements the TrackPort team can test; SLSA describes how trustworthy a build is; SAMM lets Priya judge where Harbourline's maturity stands; and the Top 10 categories give developers familiar labels for the findings. She cites each one only where it supports a specific decision.

1.5 The professional role

Priya's role is to find, explain and help fix risks with developers, not to work alone. Most fixes are made by the team that owns the code. Working with developers also matters because they know TrackPort better than she does: which functions are called, which packages were added for what reason and which changes would break the depot app. Priya's job is to make findings clear enough that the owning team can act quickly, and to check afterwards that the fix worked. Marcus reviews her work and helps when a decision needs security authority.

1.6 Course plan

Context, authorised practice, methods, tools, workflow, controls, a supervised case, reporting, quality, a lab and a portfolio. Each part builds on the previous one. Context and authorised practice come first, because Priya needs to know the service and her limits before she reviews anything. Methods and tools follow, then the workflow that turns findings into fixes and the controls that prevent the hl-auth problem returning. The supervised case, reporting and quality checks build professional judgement, and the lab and portfolio show assessors what she can do.

Worked example

Priya writes a one-paragraph summary of the hl-auth finding for Marcus: what was seen, why it matters, and what is not yet known (whether other internal names are affected). Marcus approves a review of all build dependencies as the first piece of work.

Synthetic case. Harbourline, TrackPort and all events are synthetic.

Errors and limits

A single finding is a starting point; avoid concluding more than the evidence shows.

Exercises

Synthesis

Security goals extend to everything that goes into the software.

Continue studying — chapter 01 of 12

← Course home · Course chapter index · Chapter 02 (draft) →

Worked answers

EX001. The internal package hl-auth was resolved from the public registry.

EX002. It ensures everything built into the application is what the team intended.

EX003. A06 vulnerable and outdated components and A08 software and data integrity failures.

EX004. To find, explain and help fix risks with the owning teams.

EX005. What was seen, why it matters, and what is not yet known.