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. It lives 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 reach that working set 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 the 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 precisely the fraction of a mostly-governance regulation 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.