◇ OpenCyber Academy
Bachelor's · Chapter 27 · English

Chapter 27 — Application and software supply chain security: verification

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 27 — Application and software supply chain security: verification

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 ASVS"]
  N2["27.2 Planning tests"]
  N3["27.3 Evidence"]
  N4["27.4 Results"]
  N5["27.5 Prioritising"]
  N6["27.6 Retesting"]
  N7["Automating checks"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 ASVS"]
  N2["27.2 Planning tests"]
  N3["27.3 Evidence"]
  N4["27.4 Results"]
  N5["27.5 Prioritising"]
  N6["27.6 Retesting"]
  N7["Automating checks"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 ASVS]
    |
    v
[27.2 Planning tests]
    |
    v
[27.3 Evidence]
    |
    v
[27.4 Results]
    |
    v
[27.5 Prioritising]
    |
    v
[27.6 Retesting]
    |
    v
[Automating checks]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) verify an application against ASVS requirements; (2) plan authorised testing with the WSTG; (3) record evidence per requirement; (4) prioritise fixes.

27.1 ASVS

The OWASP Application Security Verification Standard lists testable requirements at three levels. CampusEats targets ASVS 4.0.3 Level 1 for most areas and Level 2 for authentication, session management and access control, because it handles payments and personal data. ASVS 5.0.0 reorganised chapters; Lena notes both identifiers for each requirement she checks.

Lena records the level chosen for each area in a decision record, so the reason for the higher target on authentication is clear to later members. The target levels are reviewed each year, since new features may handle more sensitive data.

27.2 Planning tests

Using the WSTG v4.2, Lena selects tests for configuration, authentication, authorisation, session management, input validation and error handling. Testing happens only in the test environment, under the society's written permission.

Each test is linked to the ASVS requirements it checks, so the results can be reported against the standard. Lena writes the plan before testing, including which tests are out of scope and why, such as load tests that could disrupt the shared hosting platform. The plan is reviewed by Grace and shared with the society.

27.3 Evidence

Each requirement gets pass, fail or not applicable, with evidence: a test log, a configuration screenshot or code reference.

Evidence is stored in the private tracker with the date and the version tested. A pass without evidence is treated as not tested. Not applicable needs a reason too, such as a requirement about file uploads when CampusEats has no upload feature. Lena checks a sample of results with a second member, who confirms the evidence supports the verdict before the report is shared.

27.4 Results

46 requirements checked: 41 pass, 4 fail, 1 not applicable. Failures: password reset links valid too long for staff accounts, missing rate limit on login for staff, verbose error page in one admin screen, and missing audit log for menu price changes.

Each failure is logged as an issue with an owner and a severity, and the not-applicable item is explained in the report. None of the failures had been exploited, as far as logs show. The four findings concentrate on staff and admin functions, which the first tests had covered less thoroughly than student ones, so Lena adds staff scenarios to the regular test suite.

27.5 Prioritising

Fixes are ordered by risk: rate limit and reset link first (account takeover risk), then audit log and error page.

Each fix has an owner and a target date, following the society's advisory deadlines: seven days for high risk and thirty for medium. Lena puts the rate limit first because a guessed staff password would allow price changes and refunds. The audit log fix also closes a gap noted in the threat model, where repudiation of price changes had no control.

27.6 Retesting

Each fix is retested by someone else.

The retester did not write the fix and works from the original finding, not the developer's description of what changed. This catches fixes that address the symptom but not the cause, such as a rate limit applied to one login form but not the staff one. Each retest is recorded with its own evidence, and an item is closed only after it passes. Lena repeats the full ASVS check before the next major release.

Automating checks

Many ASVS requirements can be checked automatically after the first manual review: cookie attributes, headers, rate limits and error pages. Lena turns eleven of the 46 checks into CI tests, so they run on every change and regressions are caught early. The remaining checks, which need judgement, stay in the yearly manual review.

Reporting

The verification report is shared with Grace and kept with the release records for a year.

Worked example

All four failures are fixed within three weeks and retested. Grace asks the society to repeat the verification yearly and after major changes.

Synthetic case. Results are synthetic.

Errors and limits

Passing ASVS requirements shows conformance at that time, not absence of all flaws.

Exercises

Synthesis

Verify against a standard, with evidence, and fix by risk.

Continue studying — chapter 27 of 40

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →