Six places an app decides to trust something, and why a tool list misses two of them

An explainer published by SC Media argues that application security controls are not built to stop attackers but to enforce decisions at trust boundaries, and that most programs are organized instead around tool categories or vulnerability lists, neither of which ensures complete coverage ^[1][4]. The consequence is budgetary as much as technical: a frame built from tools and CVE categories describes solutions and symptoms rather than the points where the application decides anything ^[17].

The definition doing the work here is narrow. A trust boundary is any point where an application decides whether to trust something: user input, an identity claim, a service response, or data from storage ^[2]. The boundary is the decision point, not the source of the input, and the decisions sit inside application logic rather than only at network edges ^[2][3].

The model names six types ^[5]. Input boundaries govern what user-supplied data is allowed to become inside the application, with the decision being whether to interpret it directly or constrain it through parameterization and encoding ^[6]. Identity boundaries verify authentication assertions and session claims before the application acts on them ^[7]. State boundaries decide whether workflow and session transitions are authorized given current context and permissions ^[8]. Service call boundaries decide whether to trust responses from internal and external systems or verify them against expected schemas and business rules ^[9]. Data access boundaries enforce authorization per object before returning records, not merely per data category ^[10]. Runtime behavior boundaries decide whether current usage matches expected application behavior ^[11].

The interesting part is what happens when you lay a conventional stack over that list. SAST finds code patterns, DAST tests running applications, and a WAF filters network traffic; each covers specific boundary types and none covers all six ^[12]. The OWASP Top 10 gives guidance on what kinds of controls to put in place and is useful for describing problems, but does not map to complete control coverage ^[13]. The explainer identifies two boundaries as routinely uncontrolled: service call boundaries, because neither SAST nor DAST typically validates service response handling ^[14], and runtime behavior boundaries, which need specialized monitoring that traditional application security tools do not provide ^[15]. That is a third of the decision points structurally outside the default toolchain ^[1].

Re-mapped, the output is a coverage map: existing controls evaluated against each boundary type, with gaps marked where no enforcement exists at all ^[16]. Two of the six then read as engineering work rather than procurement. Per-object authorization before a record is returned lives in the data access path ^[10], and schema and business-rule validation of service responses lives in the calling code ^[9]. Neither arrives with a license key.

Worth noting that this is a model, not a measurement; the explainer presents a conceptual framework and control mapping without incident data ^[18].

What to watch: whether runtime behavior monitoring gets bought as a seventh tool category, which would reproduce exactly the tool-shaped program the model criticizes ^[15][17]; and whether teams that build the coverage map can name an owner for service response validation, since it falls between the application team and whoever runs the service being called ^[14].