Why a list from OWASP

The Open Worldwide Application Security Project (OWASP) is a non-profit whose Top 10 is the most widely used list of web application security risks. The 2025 edition is built from data on real applications and a community survey, and IT departments and auditors recognise it ^[1]. Mapping your tests to it gives you and IT a shared language: "A01 is covered by these 25 tests, and they pass."

Each category on a plant platform

Category names as published in the OWASP Top 10:2025 ^[1]. For a fuller checklist when IT asks for one, OWASP's Application Security Verification Standard (ASVS) lists hundreds of verifiable requirements in levels ^[5].

A01 first: every role against every route

Broken access control has been first on the list since 2021 ^[1]. It is also the easiest to test thoroughly, because your Role and Exposure Matrix already says exactly what each role may reach. Generate one test per cell: sign in as the role, request the route, expect allowed or refused. Then add a row for another site's supervisor, which should be refused everywhere, and a check that fails when a route exists that the matrix does not mention, so default deny stays true ^[6].

// test/acceptance/access-grid.test.mjs: one test per role and route, from docs/matrix.json.
import { test } from "node:test";
import assert from "node:assert/strict";
import matrix from "../../docs/matrix.json" with { type: "json" };
import { signIn, BASE } from "../helpers.mjs"; // signs in a seeded test user and returns its cookie

for (const role of [...matrix.roles, "anonymous", "other-site-supervisor"]) {
  for (const route of matrix.routes) {
    const allowed = (matrix.allow[role] || []).includes(route);
    test(`${role} ${allowed ? "may" : "may not"} open ${route}`, async () => {
      const cookie = role === "anonymous" ? "" : await signIn(role);
      const res = await fetch(BASE + route, { headers: { cookie }, redirect: "manual" });
      if (allowed) assert.equal(res.status, 200);
      else assert.ok([302, 401, 403, 404].includes(res.status), `got ${res.status}`);
    });
  }
}

Free scanners, then paid if you need them

From intent to evidence

Your intent (Session 2) says what the platform is for. The matrix (Session 7) says who may do what. Conformance means each of those promises has a test, and each test has a result. Lay it out as a table in your repository, one row per promise: the line of intent, its acceptance criterion, the test file and the latest result. This is called a traceability matrix, and it is exactly what an auditor or IT reviewer wants to see.

Criteria people and agents can both read

Write each criterion as given (the starting situation), when (what someone does) and then (what must happen). This form, from behaviour-driven development, is plain enough for a supervisor to confirm and precise enough for an agent to turn into a test ^[1].

Numbers worked by hand

A dashboard that shows the wrong number with confidence is dangerous. For every measure, keep one case worked by hand from the seeded data, as Session 14 did for OEE (75.1% for the seeded Press 02 shift), and assert the platform shows the same value. If the formula changes, the hand-worked case must be re-worked by a person, not updated by the agent to match the new output.

The access matrix, again

The access grid from chapter 1 is also a conformance test: it proves the matrix you wrote is the matrix that runs. Keep one source of truth (docs/matrix.json), generate both the row-level security and the tests from it, and the two can never drift apart.

Watch every test fail once

A test that has never failed may not be testing anything. Before you trust a new acceptance test, break the rule it checks on a scratch branch (remove the role check, change the formula) and run it. It must go red. Then throw the scratch branch away. Mutation-testing tools automate the same idea at scale by making small changes to your code and checking the tests notice ^[2].

# Prove the reject-reason test checks the rule. Run in your repository folder.
git switch -c scratch/break-reject-rule
# Edit app/review/actions.ts: comment out the line that refuses a reject with no reason, then:
npm test -- --test-name-pattern="reject"     # must FAIL
git switch main && git branch -D scratch/break-reject-rule
npm test -- --test-name-pattern="reject"     # passes again

Secure development frameworks ask for the same discipline: NIST's Secure Software Development Framework expects that software is checked against its security requirements and that the evidence is kept ^[3]. Your conformance table and its CI results are that evidence.

The shape of the suite

Fast, focused tests catch most mistakes cheaply; slow browser tests prove the journeys work end to end. Keep many of the first and few of the second. This shape is usually drawn as a pyramid ^[1]. Google's testing team gives the reason: end-to-end tests are slow and their failures are hard to trace, so they should cover the main journeys while smaller tests carry the detail ^[2].

Required checks: no merge past a red gate

In GitHub's branch protection for main, mark each CI job as a required status check. Then a pull request cannot merge until every one is green, whoever opened it, agent or person ^[4]. Run the checks from a fresh clone, so files that exist only on someone's laptop cannot make a test pass.

name: weekly-security
on:
  schedule:
    - cron: "17 9 * * 1"   # Mondays 09:17 UTC (05:17 Eastern in summer, 04:17 in winter)
  workflow_dispatch: {}
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm audit --audit-level=high
      - uses: gitleaks/gitleaks-action@v2
        env: { GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}" }

GitHub runs scheduled workflows from the default branch; in public repositories it pauses a schedule after 60 days without activity ^[5]. Scheduled minutes count against the Actions allowance like any other job.

Every bug gets a test

When something breaks in use, the fix is not finished until a test exists that would have caught it. Write the test first, watch it fail against the broken code, then fix. Over time the suite becomes a record of every mistake the platform will never make again. The CivOps platforms run on this rule: when a change fails, the test that would have caught it is added along with the fix.

Flaky tests

A flaky test passes and fails on the same code. Google found that a meaningful share of its tests showed some flakiness, and that flaky tests teach people to ignore red ^[6]. Never fix flakiness by deleting the test or marking it optional. Find the cause (usually timing, shared data or test order), fix it within the week, and give each test its own data so order does not matter.

The clamp audit

Session 9 set out the quality clamps: the ten checks every change must pass. The Clamp Audit is the report of them: one page listing each clamp, the evidence that it passes today (a test name, a scan result, a count), and an action and date for anything not green. Generate it from the CI results rather than writing it by hand, so it is always current. The same page goes into the IT approval package in Session 19.