What Must Be Done Here? Using a Bounded Application-Security Ontology at the Point of Change

The security guidance that bears on code is real but scattered — across secure-development frameworks, verification standards, controls catalogues, threat taxonomies, and, increasingly, normative regimes such as the EU's NIS2 — and most of it is written for readers other than the engineer (or the AI assistant) at a point of change. Existing cybersecurity ontologies largely model attacks, indicators, and risk for detection and analysis, not the engineering-practice substance one must act on. This paper presents a use case for an existing bounded application-security ontology, AppSec Core, whose construction and validation are reported separately. We show how it is used: it makes the engineering-actionable fraction of those authorities addressable as a typed working set — the control objectives that apply, the practices that realize them, the mechanisms that implement them, and the evidence artifacts they expect — each traceable to the sources that justify it. We demonstrate the working set reached from two entry points that recur in practice. Forward, from a code change: a change to authentication middleware scopes to its governing domain slice and returns the obligations that change must satisfy. Inverse, from a normative obligation: "make this NIS2-compliant" resolves a generic legal duty into the concrete engineering obligations it implies across slices — surfacing, from a regulation that is overwhelmingly governance text, precisely the fraction that lands in code. The same working set is what a human engineer reads and what an LLM-grounded assistant is handed as grounding. The use turns "read every applicable authority" into "satisfy this typed working set" — for a code change or a compliance duty alike. The contribution is the demonstrated use; the artefact, its validation, and its governance are companion work.